ElasticSearch - thông lượng chỉ mục cao

Question

Tôi đang đánh giá điểm chuẩn cho Tìm kiếm có mục tiêu thông lượng rất cao.

Mục tiêu hiện tại của tôi là có thể lập chỉ mục 3 tỷ (3.000.000.000) tài liệu chỉ trong vài giờ. Vì mục đích đó, tôi hiện có 3 máy chủ cửa sổ, với bộ nhớ RAM 16 GB và 8 bộ xử lý mỗi máy. Các tài liệu được chèn vào có một ánh xạ rất đơn giản, chỉ chứa một số ít trường số không phân tích (_all bị tắt).

Tôi có thể đạt được khoảng 120.000 yêu cầu chỉ mục mỗi giây (giám sát sử dụng bàn lớn), sử dụng giàn khoan tương đối khiêm tốn này và tôi tin rằng thông lượng có thể được tăng thêm. Tôi đang sử dụng một số máy khách NEST .net để gửi các yêu cầu hàng loạt chỉ mục, với số lượng lớn chỉ mục 1500 hoạt động.

Thật không may, thông lượng của yêu cầu 120k mỗi giây không kéo dài quá lâu và tốc độ giảm dần, giảm xuống ~ 15k sau một vài giờ.

Giám sát các máy cho thấy rằng cpu không phải là nút cổ chai. Tuy nhiên, thời gian không hoạt động của ổ đĩa vật lý (không phải SSD) dường như đang giảm trên tất cả các máy, đạt mức độ không đáng tin cậy ít hơn 15%.

Đặt refresh_interval đến 60s, so với 300 giây và cuối cùng 15m, dường như không giúp được gì nhiều. Theo dõi một lần chuyển đổi đơn lẻ trong một phân đoạn duy nhất, cho thấy translog bị xóa mỗi 30 phút, trước khi đạt 200MB.

Tôi đã cố gắng sử dụng hai chiến lược sharding:

1. 1 chỉ số, với 60 mảnh (không bản sao).
2. 3 chỉ mục, với 20 phân đoạn mỗi (không có bản sao).

Cả hai lần thử đều mang lại trải nghiệm tương tự, điều tôi đoán là có cùng số lượng phân đoạn.

Nhìn vào các phân đoạn, tôi có thể thấy rằng hầu hết các phân đoạn đều có ~ 30 đoạn được cam kết và số lượng phân đoạn có thể tìm kiếm tương tự. Kích thước phân đoạn khác nhau. Tại một thời điểm, một nỗ lực để tối ưu hóa chỉ mục với max_num_segments = 1, dường như đã giúp một chút sau khi nó được hoàn thành (mất một thời gian dài).

Bất kỳ lúc nào, bắt đầu toàn bộ quy trình nhập ngay từ đầu, sau khi xóa chỉ mục đã sử dụng và tạo chỉ mục mới - dẫn đến hành vi tương tự. Ban đầu chỉ số thông lượng cao, nhưng dần dần giảm dần, lâu trước khi đạt mục tiêu 3 tỷ tài liệu. Kích thước chỉ mục trong khoảng thời gian đó là khoảng 120GB.

Tôi đang sử dụng phiên bản ElasticSearch 1.4. Xms và Xmx được cấu hình cho 8192MB, 50% bộ nhớ có sẵn. Bộ đệm lập chỉ mục được đặt thành 30%.

Câu hỏi của tôi là như sau:

1. Giả sử rằng các đĩa hiện là nút cổ chai của giàn khoan này, là hiện tượng này sử dụng đĩa tăng dần là một bình thường không? Nếu không, những gì có thể được thực hiện để phủ nhận những hiệu ứng này?
2. Có điều chỉnh tinh vi nào mà tôi có thể thực hiện để tăng thông lượng lập chỉ mục không? Tôi có nên không? hoặc tôi chỉ nên mở rộng quy mô.

Answer 1

Câu chuyện dài ngắn, tôi đã kết thúc với 5 máy ảo ảo, 8 cpu, 16 GB, sử dụng con rối để triển khai elasticsearch. Tài liệu của tôi có kích thước lớn hơn một chút, nhưng tỷ lệ này cũng hơi cao. Tôi đã có thể đạt được yêu cầu chỉ mục 150K/giây trung bình, lập chỉ mục 1 tỷ tài liệu trong 2 giờ. Thông lượng không phải là hằng số và tôi quan sát thấy hành vi thông lượng giảm tương tự như trước đây, nhưng ở mức độ thấp hơn. Vì tôi sẽ sử dụng các chỉ số hàng ngày cho cùng một lượng dữ liệu, tôi sẽ mong đợi các chỉ số hiệu suất này gần giống nhau mỗi ngày.

Việc chuyển đổi từ cửa sổ máy để linux là chủ yếu là do sự tiện lợi và phù hợp với công ước CNTT. Mặc dù tôi không biết chắc chắn, tôi nghi ngờ kết quả tương tự có thể đạt được trên các cửa sổ là tốt.

Trong một số thử nghiệm của tôi, tôi đã cố gắng lập chỉ mục mà không chỉ định id tài liệu như Christian Dahlqvist gợi ý. Kết quả thật đáng kinh ngạc. Tôi quan sát thấy một thông lượng tăng đáng kể, đạt 300k và cao hơn trong một số trường hợp. Kết luận của điều này là hiển nhiên: Không chỉ định id tài liệu, trừ khi bạn hoàn toàn phải làm như vậy.

Ngoài ra, tôi đang sử dụng ít mảnh cho mỗi máy, mà còn góp phần làm thông gia tăng.