Làm thế nào để có hiệu quả nạp ESP nhanh chóng với gigabyte dữ liệu với .NET

Question

Đây sẽ là một câu hỏi khó nhưng tôi sẽ cố gắng: nhiệm vụ của chúng tôi là cho ăn ESP nhanh ESP với gigabyte dữ liệu. Số lượng cuối cùng của dữ liệu được lập chỉ mục là một nơi nào đó trong vùng lân cận của 50-60GB.

FAST có API .NET nhưng các thành phần cốt lõi được viết bằng Python (đường dẫn xử lý tới tài liệu chỉ mục). Thách thức là giao tiếp đáng tin cậy với hệ thống trong khi cho nó gigabyte dữ liệu để lập chỉ mục.

Những vấn đề nảy sinh với NHANH đây là:

1. hệ thống là kỳ quặc khi nó được cho ăn quá nhiều dữ liệu cùng một lúc vì nó muốn reindex dữ liệu của nó trong thời gian đó những gì còn lại hệ thống không thể truy cập trong nhiều giờ. Không thể chấp nhận.

2. không phải là tùy chọn để xếp hàng tất cả dữ liệu và cấp dữ liệu một cách liên tục một mục tại một thời điểm vì việc này sẽ mất quá nhiều thời gian (vài ngày).

3. khi một mục không thể được lập chỉ mục bởi NHANH khách hàng có để lại nuôi mục. Để làm việc này, hệ thống được yêu cầu gọi phương thức gọi lại để thông báo cho khách hàng về lỗi. Tuy nhiên, bất cứ khi nào hệ thống hết thời gian cho ăn, khách hàng không thể phản ứng với thời gian chờ vì cuộc gọi lại đó không bao giờ được gọi. Do đó khách hàng đang chết đói. Dữ liệu nằm trong hàng đợi nhưng không thể được chuyển vào hệ thống. Hàng đợi bị thu hẹp. Dữ liệu bị mất. Bạn có được ý tưởng.

Ghi chú:

1. ăn một mặt hàng có thể mất vài giây cho một mục nhỏ và lên đến 5-8 giờ cho một mục lớn duy nhất.
2. các mục được lập chỉ mục là cả nhị phân và văn bản.
3. mục tiêu là để lập chỉ mục đầy đủ để thực hiện "chỉ" 48-72h, tức là phải xảy ra vào cuối tuần.
4. Đường ống xử lý tài liệu FAST (mã Python) ở đây có khoảng 30 giai đoạn mỗi. Có tổng cộng 27 đường ống trong số này viết là .

Nói tóm lại:

Thách thức chính là để nuôi hệ thống với mục lớn nhỏ, tại chỉ là tốc độ phải (không quá nhanh vì nó có thể thu gọn hoặc chạy vào vấn đề bộ nhớ; không quá chậm vì quá trình này sẽ mất quá nhiều thời gian), đồng thời, theo cách song song như chuỗi chạy không đồng bộ. Trong ý kiến ​​của tôi phải có một thuật toán quyết định khi nào cần ăn mục nào và số lượng cùng một lúc. Lập trình song song đến với tâm trí.

Cũng có thể có nhiều "hàng đợi" trong đó mỗi hàng đợi (quá trình) được dành riêng cho các mục có kích thước nhất định được tải trong hàng đợi và sau đó được cấp một (trong chuỗi công việc).

Tôi tò mò nếu có ai từng làm bất cứ điều gì như thế này hoặc bạn sẽ gặp phải vấn đề như thế nào.

EDIT: Một lần nữa, tôi không tìm cách "sửa" ESP nhanh hoặc cải thiện hoạt động bên trong . Thách thức là sử dụng hiệu quả nó!

Answer 1

Có vẻ như bạn đang làm việc với một tập hợp các vấn đề nhiều hơn một vấn đề về tốc độ nạp C# cụ thể.

Một vài câu hỏi ở phía trước - dữ liệu 60 GB này có được tiêu thụ vào mỗi cuối tuần hay đó là chèn lấp ban đầu của hệ thống? Liệu các dữ liệu tồn tại như các mục trên hệ thống tập tin địa phương để cài đặt ESP hoặc phần mềm khác? Đây có phải là một triển khai ESP nội bộ duy nhất hay một giải pháp mà bạn đang tìm cách sao chép ở nhiều nơi? Cài đặt nút đơn hoặc nhiều (hay đúng hơn ... bao nhiêu - một nút nút duy nhất là 20 tài liệu)?

Hiệu suất ESP thường bị giới hạn bởi số lượng tài liệu cần xử lý nhiều hơn số lượng tệp. Giả sử phạm vi dữ liệu của bạn giữa dữ liệu kích thước email 35k và dữ liệu kích thước 350k dữ liệu tệp, bạn 60gb tương đương với giữa tài liệu 180k và tài liệu 1,8 triệu, do đó, để cấp dữ liệu trên 48 giờ, bạn cần cấp dữ liệu giữa 3750 và 37500 tài liệu mỗi giờ. Không phải là một mục tiêu rất cao trên phần cứng hiện đại (nếu bạn cài đặt nó trên một máy ảo ... tốt ...tất cả các cược đã tắt, nó sẽ tốt hơn trên một máy tính xách tay).

Để cho ăn, bạn có thể lựa chọn giữa mã hóa nhanh hơn & kiểm soát nhiều hơn bằng cách quản lý các lô tự nạp hoặc sử dụng khung DocumentFeeder trong api, tóm tắt rất nhiều lô lôgic. Nếu bạn đang đi cho 37,5k docs/giờ tôi muốn tiết kiệm chi phí và chỉ cần sử dụng DocumentFeeder - mặc dù chăm sóc trong params cấu hình của nó. Bộ nạp tài liệu sẽ cho phép bạn xử lý nội dung của mình trên cơ sở mỗi tài liệu thay vì tự tạo các lô, nó cũng sẽ cho phép một số biện pháp tự động thử lại dựa trên cấu hình. Mục tiêu chung phải dành cho nội dung tối đa 50mb cho mỗi đợt hoặc 100 tài liệu, tùy theo điều kiện nào đến trước. Tài liệu lớn hơn sẽ được gửi theo lô nhỏ hơn ... vì vậy nếu bạn có tệp 50MB, lý tưởng nhất nên được gửi bởi chính nó, v.v. Bạn thực sự mất quyền kiểm soát các lô được tạo bởi trình nạp tài liệu ... do đó, logic ở đó là một nỗ lực tốt nhất trên một phần mã của bạn.

Sử dụng các cuộc gọi lại để theo dõi mức độ hiệu quả của nội dung trong hệ thống. Đặt giới hạn về số lượng tài liệu đã được cấp mà bạn chưa nhận được cuộc gọi lại cuối cùng. Mục tiêu nên cho các lô X được gửi tại bất kỳ thời điểm nào - YM, tạm dừng tại một trong hai điểm ngắt. X nên có khoảng 20 + # bộ xử lý tài liệu, Y phải nằm trong vùng 500-1000Mb. Với bộ nạp tài liệu nó chỉ là một pass/fail per doc, với hệ thống truyền thống thì nó chi tiết hơn. Chỉ chờ cho gọi lại 'bảo đảm' ... cho bạn biết nó đã được xử lý & sẽ được lập chỉ mục ... chờ cho nó có thể tìm kiếm được là vô nghĩa.

Đặt một số giới hạn về nội dung của bạn ... nói chung ESP sẽ chia nhỏ với các tệp rất lớn, có giới hạn cứng ở 2gb vì nó vẫn là 32 bit procs, nhưng trên thực tế, bất kỳ thứ gì trên 50mb chỉ nên có siêu dữ liệu được nạp vào. Ngoài ra ... tránh cho ăn dữ liệu nhật ký, nó sẽ đè bẹp các cấu trúc bên trong, giết chết sự hoàn hảo nếu không bị lỗi. Những điều có thể được thực hiện trong đường ống để sửa đổi những gì có thể tìm kiếm để giảm bớt nỗi đau của một số dữ liệu nhật ký.

Cũng cần đảm bảo chỉ mục của bạn được định cấu hình tốt, ít nhất 6 phân vùng có trọng tâm là giữ cho các phân đoạn đặt hàng thấp hơn hoàn toàn trống. Khó có thể đi vào chi tiết của cái đó mà không biết nhiều hơn về việc triển khai. Các cấu hình đường ống có thể có một tác động lớn là tốt ... không có tài liệu nên bao giờ mất 5-8 giờ. Đảm bảo thay thế bất kỳ giai đoạn tìm kiếm hoặc htmlexport nào đang được sử dụng với các phiên bản tùy chỉnh với thời gian hết giờ (30-60 giây) - mặc định không có thời gian chờ.

Điểm cuối ... tỷ lệ cược là không có vấn đề làm thế nào cho ăn của bạn được cấu hình, đường ống sẽ lỗi ra trên một số tài liệu. Bạn sẽ cần phải chuẩn bị hoặc chấp nhận điều đó hoặc chỉ refeed siêu dữ liệu (có các tùy chọn khác, nhưng kinda bên ngoài phạm vi ở đây).

chúc may mắn.

Answer 2

Trước hết, bạn nên sử dụng các tác vụ cho vấn đề như vậy.
Chúng có thể được bắt đầu đồng bộ, không đồng bộ, trong nhóm chủ đề vv và rẻ hơn nhiều so với bộ nhớ so với các mô hình có khóa chỉ.

Tôi nghĩ rằng, Task.ContinueWith phù hợp hoàn hảo cho vấn đề của bạn.

Algorithm vẻ như sẽ:

1. Thu thập một hàng đợi với dữ liệu bạn cần để xuất bản.
2. Bắt đầu một nhiệm vụ (hoặc nhiệm vụ, nếu bạn là nguy hiểm :) sẽ mất đối tượng nặng hơn từ hàng đợi (và đối tượng nhỏ nhất từ ​​phía bên kia), và bắt đầu tải nó lên.
3. Tạo phương thức để kết thúc tải lên, thao tác này sẽ bắt đầu nhiệm vụ mới cho mục hàng đợi mới.
4. Bạn có thể sử dụng mã thông báo hủy để hết thời gian chờ.
5. Mỗi khi bạn có thể xác định mục hệ thống gặp lỗi nào.

Answer 3

Bạn có thể chỉ cần sử dụng BULK INSERT trực tiếp trên cơ sở dữ liệu không? Nếu không, tôi đề nghị bạn làm việc với nhà cung cấp sản phẩm của bên thứ ba để cùng nhau bạn có thể xây dựng một giải pháp khả thi.

Answer 4

Cơ sở dữ liệu khi bạn ghi rõ nó không sử dụng được. Bạn có thể tìm thấy một số công việc arround nhưng bạn sẽ gặp phải vấn đề lớn tương tự trong tương lai. ~ 10gb dùng một ngày để chuyển và âm thanh reindexing ngẫu nhiên âm thanh vô lý.

Lời khuyên của tôi là yêu cầu nhà cung cấp của bạn lấy cơ sở dữ liệu trong trạng thái có thể sử dụng (sửa lỗi) hoặc cung cấp cho bạn trích xuất dữ liệu và bạn tạo dữ liệu của riêng mình.