ELASTICSEARCH 2. ƯU – NHƯỢC VÀ KHI NÀO NÊN SỬ DỤNG

ƯU ĐIỂM

• Elasticsearch được phát triển bằng Java, điều này giúp nó có khả năng tương thích với rất nhiều nền tảng.
• Elasticsearch hoạt động theo cơ chế thời gian thực, những thay đổi cũng ngay lập tức có thể được tìm thấy.
• Elasticsearch là hệ thống phân tán, dễ dàng mở rộng và tích hợp với bất cứ tổ chức lớn nào.
• Elasticsearch đưa ra kết quả dưới dạng JSON, hỗ trợ truy cập từ các phần mềm được xây dựng bằng rất nhiều những ngôn ngữ lập trình khác.
• Elasticsearch hỗ trợ hầu hết mọi loại dữ liệu, trừ những kiểu dữ liệu không hỗ trợ hiển thị dưới dạng văn bản (text).

NHƯỢC ĐIỂM

• Elasticsearch không hỗ trợ nhận request và gửi trả response bằng nhiều định dạng (chỉ dùng JSON) so với một search engine khác cũng xây dựng dựa trên Lucene đó là Apache Solr hỗ trợ JSON, CSV, XML.
• Elasticsearch không hỗ trợ phân quyền truy cập và thay đổi dữ liệu.
• Elasticsearch không hỗ trợ transaction.

SO SÁNH VỚI CÁC DOCUMENT-ORIENTED DATABASE

Elasticsearch được phát triển với mục đích chính là trở thành một search engine, có khả năng đánh index, phân tích và tìm kiếm rất nhanh với khối lượng dữ liệu lớn. Nhằm mục đích đó, so với các document-oriented database (ví dụ: MongoDB, ...) thì Elasticsearch đã được lược bỏ một số tính năng cần thiết đối với một primary data store:

• Không hỗ trợ transaction (Xem thêm về khái niệm Transaction:
  https://techmaster.vn/posts/26316/transaction-la-gi
  ).
• Tối giản lược đồ (schema, xem thêm tại:
  https://en.wikipedia.org/wiki/Database_schema
  ). Tức là ta không cần xây dựng một schema chi tiết cho việc tổ chức dữ liệu bên trong Elasticsearch. Đưa vào một bản ghi JSON, Elasticsearch sẽ tự suy đoán để luận ra kiểu dữ liệu, là numerics, booleans, timestamps, strings hay kể cả mảng.
• Hoàn toàn bỏ qua khái niệm về quan hệ (relations) và ràng buộc (constraints). Việc này giúp cải thiện khả năng tìm kiếm (không phải join), tiết kiệm bộ nhớ lưu trữ, nhưng lại khiến dữ liệu không có tổ chức và rất khó cập nhật. Cũng vì thế mà Elasticsearch được gọi là write-once-read-many. Thực ra Elasticsearch đưa ra một giải pháp đó là nested-datatype: thuộc tính cha là một mảng chứa các JSON document con, tuy nhiên giải pháp này không tuân theo các dạng chuẩn của một CSDL, ví dụ với đối tượng user có nhiều address:
• { "name": "Alice", "age": 30, "gender": "female", "address": [ { "number": 12, "street": "Atlas street" }, { "number": 99, "street": "Dino street" } ] }
  Không phân quyền truy cập, tất cả người dùng truy cập vào Elasticsearch đều có vai trò như một “super user”.

KẾT LUẬN

Với những ưu – nhược điểm như trên, Elasticsearch chỉ thực sự phù hợp cho việc trở thành data store cho những dữ liệu ít phải cập nhật, và với vai trò chính là một search engine (ví dụ như lưu log, lịch sử truy cập, ...), không nên sử dụng làm một primary data store.

(còn tiếp)