Hẳn các bạn ai cũng đã từng nghe tới Elasticsearch. Bài viết này sẽ giúp các bạn hiểu về các khái niệm cơ bản trong Elasticsearch.

1. Cluster

Cluster là một tập hợp các node - nơi lưu trữ toàn bộ dữ liệu, thực hiện đánh index và search giữa các node. 1 cluster được xác định bằng 1 ***'unique name'***. Nếu như các cluster có tên trùng nhau sẽ dẫn tới hiện tượng các node join nhầm cluster. Do vậy nên tên của cluster phải là ***'unique'***. Chẳng hạn: các cluster trên các môi trường dev, staging và production có thể được đặt tên là ***'logging-dev'***, ***'logging-stage'***, và 'logging-prod' thay vì để tên giống nhau ***'logging'***. Việc đặt tên như vậy sẽ giúp bạn tránh được việc NODE thuộc môi trường product join "nhầm" CLUSTER trên môi trường dev (join nhầm thì củ chuối vãi luôn @@).

2. Node

Mỗi node là 1 server bên trong Cluster, là nơi lưu trữ dữ liệu, tham gia thực hiện việc đánh index của cluster, và thực hiện search. Cũng như cluster, mỗi node được xác định bởi 1 unique name của cluster đó. Unique Name này mặc định là 1 chuỗi random UUID và được gán giá trị ngay khi node được start up. Do ES-docs của Elasticsearch đã viết khá chi tiết nên mình sẽ không trình bày ở đây nữa. Bạn có thể đọc thêm về Node trong Elasticsearch.

3. Index

An index is a collection of documents that have somewhat similar characteristics.

Đó chính là khái niệm của index theo trên Elasticsearch docs. Nghe khá mơ hồ & khó hiểu nhỉ? Mình thấy có 1 số bài viết so sánh INDEX của Elasticsearch với Database của Sql. Well, về 1 khía cạnh nào đó thì phép so sánh này cũng 'somewhat' đúng. Và nó cũng giúp bạn mường tượng được 1 phần nào đó về INDEX. Tuy rằng phép so sánh này phần nào đúng, nhưng theo mình các bạn không nên quá lạm dụng việc đưa tư duy từ Mysql sang Elasticsearch. Lí do vì sao mình sẽ giải thích ở phần sau.

Thêm 1 chút nữa về INDEX : Như phép so sánh trên, INDEX là 1 nơi chứa các DOCUMENT (hiểu nôm na nó giống như Recode trong Sql, mình sẽ giải thích kỹ hơn ở mục sau) liên quan tới nhau. Ví dụ như trong INDEX twitter sẽ có các DOCUMENT user và tweet, trong trường hợp này user và tweet khá liên quan tới nhau. Trong INDEX không chỉ lưu trữ các DOCUMENT mà còn là nơi lưu cách đánh index cho DOCUMENT đó. Bên trong INDEX chúng ta có thể thiết lập các DOCUMENT sẽ được index, analyze như thế nào (thông qua MAPPING & ANALYSIS, sẽ được giới thiệu ở phần 2 của Series này), và cách nó được inverted index khi search ra sao. Tóm lại, hiểu nôm na INDEX là nơi sẽ giúp bạn lưu trữ và thao tác với dữ liệu khi cần (Searching).

4. Type

Giờ chúng ta sẽ đề cập tới 1 khái niệm rất dễ nhầm lẫn đối với các beginner : Type. Mình thấy có khá nhiều bài viết, thậm chí cả ES-doc của Elasticsearch, so sáng INDEX của Elasticsearch với DATABASE trong SQL Database, TYPE trong ES tương đương với Sql - TABLE, và PROPERTIES tương đương với TABLE COLUMN .

Well... , phép so sánh như vậy không thực sự chính xác cho lắm. Mình sẽ đưa ra một ví dụ cụ thể để các bạn có thể dễ hình dung:

Giả sử trong SQL DB mình có 2 table users và contacts. Trong cả 2 table này mình có 1 column cùng tên cùng kiểu là: *user_name: varchar(100)* Như các bạn đã biết, trong Sql, 2 column này thuộc 2 bảng khác nhau nên chúng nó chả có liên quan gì tới nhau hết. Tuy nhiên, trong Elasticsearch lại không như vậy. Trong Index của mình có 2 type: users và contacts. Và cũng như trường hợp trên, trong cả 2 type của mình cùng có properties cùng kiểu cùng tên : "user_name" : "text" Và điểm khác biệt nằm ở đây. Không như Sql, 2 properties này thực chất liên quan chặt chẽ tới nhau (thực chất 2 đứa nó là 1 ^^). Theo như Elasticsearch document:

In an Elasticsearch index, fields that have the same name in different mapping types are backed by the same Lucene field internally. In other words, using the example above, the user_name field in the user type is stored in exactly the same field as the user_name field in the tweet type, and both user_name fields must have the same mapping (definition) in both types.

Như vậy bản chất cả 2 properties này được lưu trong cùng 1 field bên trong Lucene. Cũng cần lưu ý thêm 1 điều: properties user_name trong cả 2 type user và contact bắt buộc phải có mapping giống nhau.

Note:

• Trước ES 6.x: 1 INDEX có thể có nhiều TYPE, từ đó dẫn tới việc các TYPE cùng tên cùng kiểu thuộc cùng INDEX và nằm trong các TYPE khác nhau gây ra nhầm lẫn.
• ES 6.x : 1 INDEX chỉ được phép có 1 TYPE, do đó sẽ không xảy ra việc các TYPE thuộc cùng 1 INDEX có thể chia sẻ chung 1 PROPERTIES. Vậy trong phiên bản này ta có thể coi TYPE trong ES tương đương TABLE trong Sql, mặc dù như thế mỗi DATABASE chỉ được phép có 1 và chỉ 1 TABLE duy nhất (hơi củ chuối @@).
• Từ ES 7.x -> : TYPE trong ES sẽ dần bị loại bỏ.
• Về chi tiết các bạn có thể xem tại ES-doc

Tips:

• Theo mình, việc so sánh Elasticsearch với Sql thực sự không nên, dù bạn cảm thấy như vậy sẽ dễ hiểu hơn. Bởi cách hoạt động của cả 2 không giống nhau nên việc áp dụng tư duy từ Sql sang Elasticsearch sẽ làm bạn hiểu sai vấn đề. Cũng như khi bạn học tiếng Anh (hay tiếng Nhật), bạn không thể áp dụng tư duy từ tiếng Việt sang để học, nó khiến bạn cảm thấy dễ dàng khi mới bắt đầu, nhưng sẽ khiến cho bạn khó có khả năng tiến xa hơn về sau. Muốn thành thạo Elasticsearch, hãy tư duy theo Elasticsearch! https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html

5. Type's Properties

Trong Elasticsearch, TYPE có thể chứa các sub-field hay còn được gọi là PROPERTIES. Nếu như trong phép so sánh trên TYPE tương đương với TABLE trong Sql thì PROPERTIES có thể được coi như COLUMN trong Sql. Bạn có thể thấy khái niệm về Properties khá đơn giản. Và dễ hiểu. Các properties có thể có kiểu thuộc bất kì kiểu nào trong DataType.

6. Document

Document đơn giản là 1 đơn vị cơ bản nhất để có thể đánh index. Và bạn cũng có thể coi nó tương tự Rows (hay Record) trong Sql. Trong Elasticsearch Document được lưu dưới dạng JSON. Lưu ý: DOCUMENT cần được gán cho 1 TYPE bên trong INDEX.

Tổng kết

Trên đây là 1 số khái niệm cơ bản nhất của Elasticsearch. Phần sau mình sẽ giới thiệu về MAPPING, ANALYSIS, TOKENIZER ... Hy vọng các bạn cảm thấy bài viết này hữu ích!

Source: Elascticsearch-doc

Và bài viết này được thực hiện trước thềm Chung Kết U23 Châu Á (27/01/2018), thế nên là

Việt Nam Vô Địch ^^