Phân đoạn lập chỉ mục Elasticsearch theo cụm và các phương pháp hay nhất sao chép

Được xuất bản lần đầu vào ngày 27 tháng 11 năm 2020, tại ObjectRocket.com/blog.

Elasticsearch® rất tuyệt vời khi truyền dữ liệu trên toàn bộ cụm của bạn với cài đặt mặc định, nhưng sau khi cụm của bạn bắt đầu phát triển, bạn nên điều chỉnh cài đặt mặc định của mình để nâng cao hiệu quả. Hãy cùng tìm hiểu một số khái niệm cơ bản về sharding và cung cấp một số phương pháp hay nhất về lập chỉ mục và phân đoạn.

Giới thiệu về Elasticsearch sharding

Có rất nhiều tài liệu trên mạng về cách hoạt động của các phân đoạn Elasticsearch, nhưng khái niệm cơ bản của sharding là chia dữ liệu của bạn thành nhiều phần nhỏ hơn để các tìm kiếm có thể hoạt động trên nhiều phần song song. Để tạo điều kiện phân cụm và song song các hàm chỉ mục, hãy chia nhỏ từng chỉ mục trong cá thể Elasticsearch của bạn thành các lát được đánh số. Những lát cắt này được gọi là mảnh vỡ. Hãy xem xét một số hành vi chính của họ:

• Mỗi phân đoạn sao chép tùy thuộc vào số lượng bản sao cài đặt cho chỉ mục. Vì vậy, đối với một số bản sao cài đặt của một, có hai bản sao của mỗi phân đoạn:một chính mảnh và một bản sao mảnh vỡ. Phân đoạn chính là phân đoạn chính và được sử dụng để indexing/write và search/read hoạt động, trong khi các phân đoạn bản sao chỉ được sử dụng cho search/read và để khôi phục nếu lỗi chính.
• Các phân đoạn bản sao phải nằm trên một máy chủ lưu trữ khác với cha mẹ của chúng phân đoạn chính.
• Các phân đoạn tự động trải rộng trên số lượng máy chủ trong cụm theo mặc định, nhưng cùng một máy chủ vật lý có thể chứa nhiều phân đoạn chính. Bạn có thể sử dụng cài đặt Elasticsearch để sửa đổi hành vi này (cân bằng lại, phân bổ phân đoạn, v.v.), nhưng quy trình đó nằm ngoài phạm vi của bài đăng này.
• Mỗi phân đoạn chỉ được nằm trong một máy chủ lưu trữ vì các phân đoạn này không thể phân chia được.
• Bạn có thể đặt số lượng phân đoạn mà một chỉ mục tạo ra trong quá trình tạo chỉ mục hoặc bạn có thể sử dụng mặc định chung. Sau khi tạo chỉ mục, bạn không thể thay đổi số lượng phân đoạn mà không lập chỉ mục lại.
• Bạn có thể đặt số lượng bản sao mà một chỉ mục có trong quá trình tạo chỉ mục hoặc bạn có thể sử dụng mặc định chung. Bạn có thể thay đổi số này sau khi tạo chỉ mục.

Hãy xem một ví dụ nhỏ. Tôi đã tạo một chỉ mục với số phân đoạn là ba và cài đặt bản sao của một. Như bạn có thể thấy trong sơ đồ trước, Elasticsearch tạo sáu phân đoạn cho bạn:Ba phân đoạn chính (Ap, Bp và Cp) và phân đoạn threereplica (Ar, Br và Cr).

Elasticsearch đảm bảo rằng các bản sao và bản chính trên các máy chủ khác nhau, nhưng bạn có thể phân bổ nhiều phân đoạn chính trên cùng một máy chủ. Về chủ đề máy chủ, hãy đi sâu vào cách bạn phân bổ các phân đoạn cho máy chủ của mình.

Phân bổ phân đoạn và Elasticsearch theo nhóm

Elasticsearch cố gắng phân bổ các phân đoạn trên tất cả các máy chủ có sẵn theo mặc định. Tại Rackspace ObjectRocket, mỗi clusterconsist các nút chính, nút khách và nút dữ liệu. Các nút dữ liệu trong kiến ​​trúc của chúng tôi tạo thành nhóm mà bạn có thể chỉ định các phân đoạn.

Sử dụng ví dụ trước, hãy lấy sáu phân đoạn đó và gán chúng vào một ObjectRocket cho cụm Elasticsearch với hai nút dữ liệu (mức tối thiểu). Trong sơ đồ sau, bạn có thể thấy rằng đối với mỗi phân đoạn, các phân đoạn chính nằm trên một nút dữ liệu, trong khi bản sao được đảm bảo nằm trên nút kia. Hãy nhớ rằng các ví dụ ở đây chỉ hiển thị một khả năng phân bổ. Không quan trọng việc phân bổ, điều chắc chắn duy nhất là một bản sao luôn được đặt trên một nút dữ liệu khác với nút chính của nó.

Bây giờ, hãy mở rộng ví dụ này và thêm một nút dữ liệu thứ ba. Lưu ý rằng hai phân đoạn được chuyển đến nút dữ liệu mới, vì vậy bạn có hai phân đoạn trên mỗi nút.

Cuối cùng, hãy thêm một chỉ mục mới vào cụm này với số phân đoạn là hai và số lượng bản sao được đặt thành hai. Điều này cung cấp cho yout hai bầu cử chính mới (Xp và Yp) và bốn bản sao (Xr0, Xr1, Yr0, Yr1) mà bạn có thể trải rộng trên cụm như được thấy trong hình ảnh sau:

Thế là xong.

Cạm bẫy

Elasticsearch thực hiện tất cả công việc khó khăn cho bạn, nhưng có một số cạm bẫy cần tránh.

Cạm bẫy số 1 — chỉ mục lớn và phân đoạn lớn

Khắc phục sự cố một chỉ mục lớn với các phân đoạn lớn là một trong những vấn đề dễ dàng khắc phục nhất trong Elasticsearch. Người dùng bắt đầu với một chỉ mục đơn rất dễ quản lý. Tuy nhiên, khi ứng dụng của họ phát triển, chỉ số của họ cũng vậy. Điều này dẫn đến các phân đoạn lớn vì kích thước lớn liên quan trực tiếp đến lượng dữ liệu cụm.

Vấn đề đầu tiên mà nguyên nhân này là hiệu quả kém trong việc sử dụng cụm. Khi các phân đoạn lớn lên, việc đặt chúng trên nút dữ liệu sẽ khó hơn. Cần một khối lớn không gian trống của nút dữ liệu để lưu trữ một phân đoạn ở đó. Điều kiện này dẫn đến các nút có rất nhiều không gian sử dụng, lãng phí. Ví dụ:nếu tôi có các nút dữ liệu 8 GB, nhưng mỗi phân đoạn là 6 GB, thì tôi sẽ thiếu 2 GB trên mỗi nút dữ liệu của mình. Vấn đề thứ hai là điểm nóng . Nếu bạn hợp nhất dữ liệu của mình thành một vài phân đoạn, thì các truy vấn phức tạp không thể được chia nhỏ trên một số lượng lớn hơn các nút và thực hiện song song.

Đừng keo kiệt với các chỉ mục

Sử dụng nhiều chỉ mục để giải quyết các vấn đề về không gian bị đình trệ. Trải rộng dữ liệu của bạn trên nhiều chỉ mục để tăng số lượng phân đoạn trong cụm và trải đều dữ liệu. Ngoài ra, giống như trò chơi Tetris, khi Elasticsearch đặt các mảnh, nhiều indexesare dễ dàng hơn để sắp xếp. Khả năng bí danh trong Elasticsearch vẫn có thể làm cho nhiều trường hợp xuất hiện dưới dạng một chỉ mục duy nhất cho ứng dụng của bạn. Hầu hết Elastic Stack tạo chỉ mục hàng ngày theo mặc định, đây là một phương pháp hay. Sau đó, bạn có thể sử dụng bí danh để giới hạn phạm vi tìm kiếm trong phạm vi ngày cụ thể, sử dụng người quản lý để xóa các chỉ mục cũ khi chúng già đi và sửa đổi cài đặt chỉ mục khi dữ liệu của bạn phát triển mà không cần phải lập chỉ mục lại dữ liệu cũ.

Tăng số lượng phân đoạn khi kích thước chỉ mục của bạn tăng

Thêm chỉ mục thường xuyên hơn và tăng số lượng phân đoạn khi chỉ mục của bạn tăng lên. Sau khi bạn thấy kích thước phân đoạn bắt đầu vượt quá không gian mong muốn của mình, bạn có thể cập nhật mẫu chỉ mục của mình (hoặc bất cứ thứ gì bạn sử dụng để tạo chỉ mục mới) để sử dụng nhiều phân đoạn hơn cho mỗi chỉ mục. Tuy nhiên, điều này chỉ hữu ích nếu bạn thường xuyên tạo chỉ mục mới, vì vậy đề xuất này được liệt kê thứ hai. Nếu không, bạn phải reindext để sửa đổi số phân đoạn, số này thể hiện nhiều công việc hơn là quản lý nhiều chỉ mục.

Quy tắc chung của chúng tôi:Nếu một phân đoạn lớn hơn 40% kích thước của một nút dữ liệu, phân đoạn đó có thể quá lớn. Trong trường hợp này, khuyến khích lập chỉ mục lại một chỉ mục có nhiều phân đoạn hơn hoặc chuyển lên kích thước gói lớn hơn (nhiều dung lượng hơn cho mỗi nút dữ liệu).

Cạm bẫy số 2 — quá nhiều chỉ mục hoặc phân đoạn

Điều nghịch đảo là quá nhiều chỉ mục hoặc phân đoạn. Sau khi đọc phần trước, bạn có thể chỉ nói, “Tốt thôi. Tôi sẽ chỉ putevery tài liệu trong chỉ mục của nó và tạo một triệu phân đoạn ”. Vấn đề ở đó là các chỉ mục và phân đoạn có chi phí. Chi phí đó tự đảm bảo khả năng lưu trữ, tài nguyên bộ nhớ và hiệu suất xử lý.

Bởi vì cụm phải duy trì trạng thái của tất cả các phân đoạn và vị trí của chúng, một số lượng lớn các phân đoạn sẽ trở thành một hoạt động lưu trữ sổ sách lớn hơn, điều này ảnh hưởng đến việc sử dụng bộ nhớ. Ngoài ra, bởi vì bạn cần phân chia các truy vấn theo nhiều cách hơn, bạn dành nhiều thời gian hơn để phân tán hoặc tập hợp cho các truy vấn. Cạm bẫy này phụ thuộc nhiều vào kích thước của cụm, trường hợp sử dụng và các yếu tố khác, nhưng rất may, chúng ta có thể giảm thiểu điều này bằng một số khuyến nghị.

Các phân đoạn không được lớn hơn 50 GB

Nói chung, 25 GB là kích thước lý tưởng cho các phân đoạn lớn và 50 GB yêu cầu lập chỉ mục lại. Việc xem xét này liên quan đến hiệu suất của phân đoạn và quá trình di chuyển phân đoạn đó khi cần thiết. Khi cân bằng lại, hãy di chuyển các phân đoạn đến một nút khác trong cụm. Quá trình truyền dữ liệu 50 GB có thể mất quá nhiều thời gian và buộc hai nút trong toàn bộ quá trình.

Giữ kích thước phân đoạn nhỏ hơn 40% kích thước nút dữ liệu

Như đã đề cập trước đây, chỉ số kích thước phân đoạn thứ hai mà chúng tôi quan tâm là tỷ lệ phần trăm dung lượng nút dữ liệu mà một phân đoạn chiếm. Trên dịch vụ Rackspace ObjectRocket, chúng tôi cung cấp các kích thước gói khác nhau liên quan đến dung lượng lưu trữ trên các nút dữ liệu. Làm ướt để định kích thước cụm và các phân đoạn để đảm bảo rằng các phân đoạn lớn nhất không chiếm hơn 40% dung lượng của một nút dữ liệu. Trong một cụm có một số chỉ mục có kích thước khác nhau, điều này khá hiệu quả. Tuy nhiên, trong một cụm có rất ít chỉ mục lớn, hãy sử dụng thậm chí tích cực hơn và cố gắng giữ dung lượng của nút dữ liệu dưới 30%.

Tốt nhất, hãy đảm bảo rằng bạn không bị hạn chế về dung lượng trên một nút dữ liệu. Nếu các phân đoạn của bạn có kích thước bằng 45% kích thước của nút dữ liệu, bạn cần một nút dữ liệu ở mức sử dụng gần một nửa để đặt phân đoạn đó. Đó là rất nhiều dung lượng dự phòng chưa sử dụng!

Kết luận

Việc chọn cài đặt phân đoạn và lập chỉ mục phù hợp có thể khó khăn, nhưng bằng cách lập kế hoạch, đưa ra một số quyết định tốt từ trước và chỉnh sửa khi thực hiện, bạn có thể giữ cho cụm của mình hoạt động tốt và hoạt động tối ưu. Chúng tôi luôn giúp các doanh nghiệp tinh chỉnh các đặc tính đàn hồi của họ.

Tìm hiểu thêm về Dịch vụ Rackspace DBA.

Sử dụng tab Phản hồi để đưa ra bất kỳ nhận xét hoặc đặt câu hỏi nào. Bạn cũng có thể nhấp vào Trò chuyện bán hàng để trò chuyện ngay bây giờ và bắt đầu cuộc trò chuyện.