Elk Stack

5 sai lầm hàng đầu với Elasticsearch và cách tránh

Posted on by ComdyVN

5 sai lầm hàng đầu với Elasticsearch và cách tránh

Elasticsearch là phần mềm mã nguồn mở lập chỉ mục và lưu trữ thông tin trong cơ sở dữ liệu NoSQL dựa trên công cụ tìm kiếm Lucene – và nó cũng là một trong những công cụ lập chỉ mục phổ biến nhất hiện nay. Elasticsearch cũng là một phần của ELK Stack.

Phần mềm được sử dụng bởi các công ty khởi nghiệp đang phát triển như DataDog cũng như các doanh nghiệp như The Guardian, StackOverflow và GitHub để làm cho cơ sở hạ tầng, sản phẩm và dịch vụ của họ có thể mở rộng hơn.

Mặc dù sự phổ biến ngày càng tăng của Elasticsearch, có một số lỗi phổ biến và nghiêm trọng mà người dùng có xu hướng mắc phải khi sử dụng phần mềm. Chúng ta hãy xem xét kỹ hơn 5 trong số những sai lầm phổ biến và cách bạn có thể tránh mắc phải chúng.

1. Không xác định ánh xạ Elasticsearch

Giả sử rằng bạn khởi động Elasticsearch, tạo chỉ mục và cấp dữ liệu đó bằng các tài liệu JSON mà không cần kết hợp các lược đồ. Sau đó, Elasticsearch sẽ duyệt qua từng trường được lập chỉ mục của tài liệu JSON, ước tính trường của nó và tạo ánh xạ tương ứng. Mặc dù điều này có vẻ lý tưởng, nhưng ánh xạ Elasticsearch không phải lúc nào cũng chính xác. Ví dụ, nếu loại trường được chọn sai, thì lỗi lập chỉ mục sẽ bật lên.

Để khắc phục sự cố này, bạn nên xác định ánh xạ, đặc biệt là trong môi trường production. Cách tốt nhất là lập chỉ mục một vài tài liệu, để Elasticsearch đoán trường, sau đó lấy ánh xạ mà nó tạo bằng GET /index_name/doc_type/_mapping. Sau đó, bạn có thể tự mình giải quyết các vấn đề và thực hiện bất kỳ thay đổi thích hợp nào mà bạn thấy phù hợp mà không để lại bất kỳ điều gì may rủi.

Ví dụ: nếu bạn lập chỉ mục tài liệu đầu tiên của mình như thế này:

{
    “action”: “Some action”,
    “payload”: “2016-01-20”
}

Elasticsearch sẽ đánh dấu trường payload là “date”.

Bây giờ, giả sử rằng tài liệu tiếp theo của bạn trông giống như sau:

{
    “action”: “Some action 1”,
    “payload”: “USER_LOCKED”
}

Ở đây, “payload” thực sự không phải là ngày tháng và một thông báo lỗi có thể bật lên và index mới sẽ không được lưu vì Elasticsearch đã đánh dấu nó là “date”.

2. Bùng nổ tổ hợp

Bùng nổ tổ hợp là các vấn đề về máy tính có thể gây ra sự tăng lên theo cấp số nhân trong việc tạo nhóm đối với một số tổng hợp nhất định và có thể dẫn đến việc sử dụng bộ nhớ không kiểm soát. Trong một số tổ hợp, không có đủ bộ nhớ trên thế giới để hỗ trợ sự bùng nổ tổ hợp của chúng.

Trường terms của Elasticsearch xây dựng các nhóm theo dữ liệu của bạn, nhưng nó không thể dự đoán trước có bao nhiêu nhóm sẽ được tạo. Điều này có thể là vấn đề đối với các tập hợp mẹ được tạo thành từ nhiều hơn một tập hợp con. Việc kết hợp các giá trị duy nhất trong mỗi tập hợp con có thể làm tăng đáng kể số lượng nhóm được tạo.

Hãy xem một ví dụ.

Giả sử bạn có tập dữ liệu đại diện cho một đội thể thao. Nếu bạn muốn xem cụ thể 10 người chơi hàng đầu và những người chơi hỗ trợ trong đội đó, tập hợp sẽ giống như sau:

{
  "aggs": {
    "players": {
      "terms": {
        "field": "players",
        "size": 10
      }
    }
  },
  "aggs": {
    "other": {
      "terms": {
        "field": "players",
        "size": 5
      }
    }
  }
}

Tập hợp sẽ trả về danh sách 10 người chơi hàng đầu và danh sách 5 người chơi hỗ trợ hàng đầu cho mỗi người chơi hàng đầu – do đó, tổng cộng 50 giá trị sẽ được trả về. Truy vấn được tạo sẽ có thể tiêu tốn một lượng lớn bộ nhớ với nỗ lực tối thiểu.

Tập hợp terms có thể hình dung như một cây sử dụng các nhóm cho mọi cấp độ. Do đó, một nhóm cho mỗi người chơi hàng đầu trong tập hợp player sẽ tạo nên cấp độ đầu tiên và một nhóm cho mọi người chơi hỗ trợ trong tập hợp orther sẽ tạo nên cấp độ thứ hai. Do đó, một đội sẽ có tổ hợp n². Hãy tưởng tượng điều gì sẽ xảy ra nếu bạn có một tập dữ liệu gồm 500 triệu document.

Chế độ tập hợp (collect_mode) được sử dụng để giúp kiểm soát cách các tập hợp con hoạt động. Chế độ thu thập mặc định của một tập hợp được gọi là theo chiều sâu (depth-first) đòi hỏi việc xây dựng toàn bộ cây và sau đó cắt tỉa các cạnh. Mặc dù độ sâu đầu tiên là một chế độ thu thập thích hợp cho hầu hết các tập hợp, nhưng nó sẽ không hoạt động trong ví dụ tập hợp của người chơi ở trên. Do đó, Elasticsearch cho phép bạn thay đổi chế độ thu thập trong các tập hợp cụ thể thành một thứ gì đó phù hợp hơn.

Những trường hợp đặc biệt, chẳng hạn như ví dụ trên, nên sử dụng chế độ thu thập theo chiều rộng (breadth-first), chế độ này xây dựng và cắt tỉa cây từng cấp một để kiểm soát bùng nổ tổ hợp. Chế độ thu thập này giúp giảm đáng kể lượng bộ nhớ được sử dụng và giữ cho các nút ổn định:

{
  "aggs": {
    "players": {
      "terms": {
        "field": "players",
        "size": 10,
        "collect_mode": "breadth_first"
      }
    }
  },
  "aggs": {
    "other": {
      "terms": {
        "field": "players",
        "size": 5
      }
    }
  }
}

3. Cấu hình cho môi trường production

Theo mặc định, cụm đầu tiên mà Elasticsearch khởi động được gọi là elasticsearch. Nếu bạn không chắc chắn về cách thay đổi cấu hình, tốt nhất bạn nên giữ nguyên cấu hình mặc định. Tuy nhiên, bạn nên đổi tên cụm production của mình để ngăn các nút không mong muốn tham gia cụm của bạn.

Dưới đây là ví dụ về cách bạn có thể muốn đổi tên cụm và nút của mình:

cluster.name: elasticsearch_production

node.name: elasticsearch_node_001

Cài đặt khôi phục ảnh hưởng đến cách các nút khôi phục khi các cụm khởi động lại. Elasticsearch cho phép các nút thuộc cùng một cụm tham gia vào cụm đó tự động bất cứ khi nào khôi phục xảy ra. Tuy nhiên, trong khi một số nút trong một cụm khởi động nhanh sau khi khôi phục, những nút khác đôi khi có thể lâu hơn một chút (ví dụ: do các nút nhận được lệnh khởi động lại vào các thời điểm khác nhau).

Sự khác biệt về thời gian khởi động này có thể gây ra sự mâu thuẫn trong dữ liệu có nghĩa là được phân phối đồng đều giữa các nút trong cụm. Đặc biệt, khi liên quan đến lượng lớn dữ liệu, việc cân bằng lại các nút sau khi khởi động lại có thể mất khá nhiều thời gian – từ vài giờ đến vài ngày – và vượt quá ngân sách của bạn rất nhiều:

gateway.recover_after_nodes: 10

Ngoài ra, điều quan trọng là phải cấu hình số lượng nút sẽ có trong mỗi cụm cũng như khoảng thời gian cần thiết để chúng khởi động trong Elasticsearch:

gateway.expected_nodes: 10
gateway.recover_after_time: 5m

Với các cấu hình phù hợp, quá trình khôi phục mất hàng giờ hoặc hàng ngày để hoàn thành có thể hoàn tất trong vài giây. Ngoài ra, minimum_master_nodes rất quan trọng đối với sự ổn định của cụm. Chúng giúp ngăn chặn tình trạng phân chia nãobộ, đó là sự tồn tại của hai nút chính (master node) trong một cụm duy nhất và có thể dẫn đến mất dữ liệu.

Giá trị được đề xuất cho cài đặt này là (N / 2) + 1 – trong đó N là số nút đủ điều kiện làm nút chính. Cùng với đó, nếu bạn có 10 nút thông thường có thể chứa dữ liệu và trở thành nút chính, giá trị sẽ là 6. Nếu bạn có ba nút chính chuyên dụng và 1.000 nút dữ liệu, giá trị sẽ là 2 (chỉ tính các nút chính tiềm năng):

discovery.zen.minimum_master_nodes: 2

4. Cung cấp năng lực

Việc cung cấp năng lực có thể giúp trang bị và tối ưu hóa Elasticsearch cho hiệu suất hoạt động. Nó yêu cầu Elasticsearch phải được thiết kế theo cách giữ cho các nút hoạt động, ngăn bộ nhớ phát triển ngoài tầm kiểm soát và ngăn chặn các hành động bất ngờ làm tắt các nút.

“Tôi cần bao nhiêu dung lượng?” là câu hỏi mà người dùng thường tự hỏi mình. Thật không may, không có công thức định sẵn, nhưng có thể thực hiện một số bước nhất định để hỗ trợ việc lập kế hoạch nguồn lực.

Đầu tiên, hãy mô phỏng trường hợp sử dụng thực tế của bạn. Khởi động các nút của bạn, truyền vào chúng các tài liệu thực và đẩy chúng cho đến khi phân đoạn bị sập. Việc khởi động và kiểm tra các nút có thể khá dễ dàng với việc cung cấp Elasticsearch của Amazon Web Services.

Tuy nhiên, hãy nhớ rằng khái niệm “start big and scale down” có thể giúp bạn tiết kiệm thời gian và tiền bạc khi so sánh với phương pháp thay thế là thêm và cấu hình các nút mới khi số tiền hiện tại của bạn không đủ.

Khi bạn xác định dung lượng của phân đoạn (shard), bạn có thể dễ dàng áp dụng nó trong toàn bộ index của mình. Điều rất quan trọng là phải hiểu việc sử dụng tài nguyên trong quá trình thử nghiệm vì nó cho phép bạn dự trữ dung lượng RAM thích hợp cho các nút, cấu hình bộ nhớ heap JVM và tối ưu hóa quy trình thử nghiệm tổng thể của bạn.

5. Large template

Large template có liên quan trực tiếp đến các ánh xạ lớn. Nói cách khác, nếu bạn tạo một ánh xạ lớn cho Elasticsearch, bạn sẽ gặp vấn đề với việc đồng bộ hóa nó trên các nút của mình, ngay cả khi bạn áp dụng chúng làm index template.

Các vấn đề với các large index template chủ yếu là bạn có thể cần phải thực hiện nhiều thao tác thủ công với nhà phát triển như một điểm thất bại duy nhất – nhưng chúng cũng có thể liên quan đến chính Elasticsearch. Hãy nhớ rằng: Bạn sẽ luôn cần cập nhật template của mình khi thực hiện các thay đổi đối với mô hình dữ liệu của mình.

Có giải pháp nào tốt hơn không? Có, đó làdynamic template.

Dynamic template tự động thêm ánh xạ trường dựa trên ánh xạ được xác định trước của bạn cho các loại và tên cụ thể. Tuy nhiên, bạn nên luôn cố gắng giữ cho các mẫu của mình có kích thước nhỏ.

Phần kết luận

Elasticsearch là một công cụ phân tích và tìm kiếm toàn văn bản được phân phối cho phép nhiều người thuê tìm kiếm thông qua toàn bộ tập dữ liệu của họ, bất kể kích thước, với tốc độ chưa từng có.

Ngoài khả năng tìm kiếm toàn văn bản, Elasticsearch còn đóng vai trò là một hệ thống phân tích và cơ sở dữ liệu phân tán. Mặc dù ba khả năng này rất ấn tượng, nhưng Elasticsearch kết hợp tất cả chúng để tạo thành một ứng dụng phân tích và tìm kiếm thời gian thực có thể theo kịp nhu cầu của khách hàng.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *