Elasticsearch

Elasticsearch là gì và mô hình cốt lõi

Elasticsearch (ES) là một search engine phân tán xây trên thư viện Lucene (Grokking ch.21 dùng ES và Lucene làm ví dụ cho tài liệu được đánh chỉ mục).¹ Bạn gửi vào các document JSON, ES phân tích nội dung text, xây chỉ mục, và cho phép tìm kiếm full-text, lọc, sắp xếp theo độ liên quan, và tính aggregation (đếm theo nhóm, histogram). Độ trễ vài chục mili giây trên hàng trăm triệu document là ước tính của khoá học, cần đo.²

Thành phần trung tâm là inverted index. Thay vì lưu "document 1 chứa những từ gì", ES lưu ngược lại: "từ pho xuất hiện trong document 1, 7, 42". Grokking ch.21 mô tả nó như một cấu trúc giống HashMap từ term tới danh sách document kèm tần suất và vị trí của term trong từng document; ưu điểm là hỗ trợ full-text search và khỏi đếm lại từ khi truy vấn, nhược điểm là tốn thêm dung lượng và công cập nhật khi thêm, sửa, xoá document.³ Redis in Action §7.1.1 cũng giải thích inverted index và dùng SET/ZSET của Redis để dựng nó.⁴ Khi tìm "phở bò", ES lấy hai danh sách của pho và bo, giao hoặc hợp chúng, rồi chấm điểm. Trong Grokking, kết quả được sắp theo tần suất term trong document;⁵ BM25 (term xuất hiện nhiều trong document nhưng hiếm trong toàn bộ tập thì điểm cao) là kiến thức thêm của khoá học.²

Đặc điểm cần nhớ: ES là kho phụ để tìm kiếm, không nên là nguồn sự thật. Nó không có transaction nhiều document, ghi chỉ hiện ra sau một khoảng refresh, và việc đổi mapping thường đòi reindex toàn bộ (khuyến nghị thực hành của khoá học).²

Kiến trúc cluster

Một cluster ES gồm nhiều node với vai trò khác nhau (vai trò cụ thể của ES là kiến thức sản phẩm;² ý tưởng cluster manager theo dõi sức khoẻ node bằng heartbeat và chia partition có trong Grokking ch.21):⁶

• Master node (nên có 3 node master-eligible): quản lý metadata, quyết định shard nằm ở đâu. Không phục vụ query nặng.
• Data node: giữ shard, chạy indexing và search.
• Coordinating node: nhận request, gửi tới các shard liên quan, gộp kết quả. Mọi node đều có thể làm vai trò này.

Một query đi theo hai pha. Pha query: coordinating node gửi tới một bản (primary hoặc replica) của mỗi shard, mỗi shard trả về top N id và điểm. Pha fetch: coordinating node gộp, chọn top N toàn cục, rồi lấy nội dung các document đó. Ý tưởng chạy tìm kiếm song song trên từng index nhỏ rồi một merger gộp và sắp xếp kết quả giống mô tả "Searching" trong Grokking ch.21.⁵

Shard và replica. Số primary shard chọn khi tạo index và không đổi được nếu không split hoặc reindex. Document được đưa vào shard theo hash(_routing) mod số_shard, mặc định _routing là id (Grokking: có thể dùng hàm băm để gán document vào partition).⁶ Replica tăng khả năng đọc và chịu lỗi: Grokking nói replication factor 3 là đủ, một bản là primary và hai bản là replica, đặt rải ở các availability zone.⁷

Near-real-time. Document mới ghi nằm trong buffer bộ nhớ và translog. Mỗi refresh_interval (mặc định cỡ 1 giây), ES tạo một segment mới và lúc đó document mới tìm được, nên độ trễ hiển thị cỡ giây. Khi import hàng loạt, tăng refresh_interval hoặc tắt hẳn để indexing nhanh hơn. Segment nhỏ được merge dần ở nền, việc này tốn CPU và I/O. Đây là cơ chế nội bộ của ES, chưa có trong sách của thư viện.² Grokking cũng tách việc dựng index khỏi việc phục vụ query để indexing không ảnh hưởng search, và ghi nhận việc cập nhật document làm tốn công cập nhật index.⁸

Mapping, analyzer và tiếng Việt

Analyzer quyết định text được cắt thành term như thế nào. Nó gồm character filter, tokenizer và token filter. Khái niệm tương ứng trong sách: Redis in Action §7.1.1 mô tả parsing, tokenization và danh sách stop word trước khi đánh chỉ mục;⁹ chi tiết analyzer của ES thì chưa có sách.² Ví dụ analyzer standard biến "Phở Bò Tái" thành phở, bò, tái.

Với tiếng Việt có hai vấn đề (phần tiếng Việt là kiến thức của khoá học, thư viện không có sách về xử lý tiếng Việt):¹⁰

1. Dấu. Người dùng hay gõ không dấu: "pho bo". Thêm filter asciifolding để phở thành pho. Nên giữ cả hai phiên bản (một sub-field có dấu, một không dấu) để kết quả có dấu đúng được điểm cao hơn.
2. Từ ghép. Tiếng Việt viết cách theo âm tiết. "Hà Nội" là một từ nhưng bị cắt thành hà và nội. Hai cách xử lý: dùng plugin tách từ tiếng Việt (có các plugin cộng đồng dựa trên bộ tách từ như coccoc-tokenizer), hoặc đơn giản hơn là dùng match_phrase và shingle (ghép 2 âm tiết liền nhau thành một term) để cụm từ liền nhau được điểm cao.

PUT /posts
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "analysis": {
      "analyzer": {
        "vi_folded": {
          "tokenizer": "standard",
          "filter": ["lowercase", "asciifolding"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title":   { "type": "text", "fields": { "folded": { "type": "text", "analyzer": "vi_folded" } } },
      "city":    { "type": "keyword" },
      "created": { "type": "date" },
      "likes":   { "type": "integer" }
    }
  }
}

Query tìm cả có dấu và không dấu, lọc theo thành phố:

GET /posts/_search
{
  "query": {
    "bool": {
      "must":   { "multi_match": { "query": "pho bo", "fields": ["title^2", "title.folded"] } },
      "filter": [ { "term": { "city": "hanoi" } } ]
    }
  },
  "size": 20
}

Phần filter không tính điểm và được cache (đặc tính của ES),² nên đặt điều kiện chính xác (thành phố, trạng thái, khoảng ngày) vào đây. Field keyword dùng cho lọc, sort và aggregation; field text dùng cho tìm full-text.

Đồng bộ từ database chính

Dữ liệu gốc nằm ở PostgreSQL hoặc MySQL. ES chỉ là bản sao để tìm. Có ba cách đẩy dữ liệu sang. Microservices Patterns ch.7 nói CQRS view có thể dùng Elasticsearch cho text query, được cập nhật bằng cách nghe event từ phía ghi;¹² ch.3 §3.3.7 mô tả hai cách phát event tin cậy: transactional outbox (bảng OUTBOX trong cùng transaction + message relay) và transaction log tailing (có nhắc Debezium đẩy thay đổi của Postgres/MySQL/MongoDB vào Kafka).¹³

Consumer nên index theo kiểu idempotent: sách nói broker thường chỉ đảm bảo giao ít nhất một lần nên message có thể trùng, cần handler idempotent hoặc ghi lại id đã xử lý,¹⁴ và view cần xử lý cập nhật đồng thời, sự kiện lặp.¹⁵ Cụ thể với ES: dùng id của DB làm _id, và dùng version với version_type: external (ví dụ lấy updated_at hoặc LSN) để sự kiện cũ đến muộn không ghi đè bản mới (tính năng ES, chưa có sách).² Cần thêm một job đối soát định kỳ hoặc khả năng reindex toàn bộ từ DB, vì sớm muộn cũng có lúc lệch; sách cũng nói view CQRS cần cơ chế dựng lại từ đầu, và broker không giữ event vô hạn nên phải đọc cả event đã lưu trữ.¹⁶ Chi tiết hơn ở Change Data Capture.

Capacity và sizing

Các con số là giả định của khoá học (ước lượng ban đầu, cần đo trên dữ liệu thật); sách của thư viện không có số liệu sizing của ES.² Bài toán chia tập dữ liệu lớn thành nhiều partition vì index quá lớn so với RAM một máy có trong Grokking ch.21.¹⁷

Ví dụ tìm kiếm bài viết: 500 triệu bài, mỗi bài trung bình 1 KB sau khi index.

500.000.000 × 1 KB ≈ 500 GB primary
Shard 40 GB → ~13 shard, làm tròn 15 primary
1 replica → 1 TB tổng
Mỗi node giữ ~300 GB đĩa an toàn → 4 node data, thêm 1 cho dư → 5 node
Query peak 3.000 QPS, mỗi node ~800 QPS → 4–5 node là vừa

Cộng thêm 3 master node nhỏ (2 vCPU · 4 GB). Để đĩa luôn dưới ~75% vì ES ngừng cấp shard khi vượt ngưỡng watermark (giả định/khuyến nghị của khoá học).²

Khi nào dùng và khi nào không

Postgres full-text là đủ khi: dữ liệu dưới khoảng vài chục triệu dòng (ngưỡng ước lượng của khoá học), chỉ cần ranking cơ bản, không cần facet phức tạp, và bạn muốn tránh thêm một hệ thống phải đồng bộ. Lợi ích lớn nhất của cách này là kết quả tìm kiếm luôn nhất quán với dữ liệu, không có độ trễ đồng bộ (vì không có bản sao thứ hai, so với độ trễ view CQRS trong Microservices Patterns §7.2.4).²⁰¹⁸

Vận hành ở quy mô nhỏ và lớn

Nhỏ. Dùng managed: Elastic Cloud hoặc Amazon OpenSearch Service (giá tuỳ nhà cung cấp). Ở giai đoạn này, cân nhắc nghiêm túc việc ở lại với Postgres.

Vừa. Tách master riêng, theo dõi heap usage, GC pause, search latency, indexing rate, số segment, rejected thread pool. Đặt snapshot định kỳ lên S3.

Lớn. Dùng kiến trúc hot-warm-cold cho dữ liệu theo thời gian (log): index mới trên node SSD mạnh, index cũ chuyển sang node rẻ hơn, quá hạn thì xóa bằng ILM (index lifecycle management). Index theo ngày hoặc dùng rollover theo kích thước để giữ shard 10–50 GB. Chi phí chủ yếu nằm ở RAM và đĩa của replica, nên với log có thể giảm replica của index cũ xuống 0 nếu đã có snapshot.

Phần vận hành bên trên là kinh nghiệm của khoá học.² Sự cố phổ biến: mapping explosion (mỗi key JSON động thành một field mới), shard quá nhiều làm master quá tải, query wildcard đầu chuỗi *abc quét toàn bộ term, và split brain ở cluster cũ cấu hình sai số master.

Điểm nói trong phỏng vấn

• ES là kho phụ cho tìm kiếm, nguồn sự thật vẫn là DB. Nói rõ cách đồng bộ: outbox hoặc CDC qua Kafka, index idempotent theo _id và version.
• Nói về độ trễ hiển thị ~1 giây do refresh, và chấp nhận được với tìm bài viết, Yelp, news feed search.
• Sizing: shard 10–50 GB, node 8 vCPU · 32 GB, heap ≤ 31 GB, replica 1.
• Với tiếng Việt: asciifolding cho không dấu, sub-field, và tách từ ghép bằng plugin hoặc shingle.
• Biết khi nào không cần ES: Postgres full-text cho tập nhỏ, kết quả luôn nhất quán.
• Nếu đề bài hỏi tự xây search như Grokking ch.21: crawler, indexer, searcher; chia index theo document (mỗi shard giữ tập document riêng, query fan-out tới tất cả) thay vì theo term.⁶ Sách còn nêu bước cải tiến: tách indexer khỏi searcher, tính index một lần ở primary rồi copy file index sang replica thay vì mỗi replica tự tính lại.⁸

Nguồn trích dẫn

1. Grokking Modern System Design · ch.21 Distributed Search · bài "Indexing" · mục "Build a searchable index". ↩

2. Chưa có nguồn trong thư viện: thư viện không có sách về Elasticsearch/Lucene; các chi tiết vận hành, API và sizing của ES chỉ nêu khái niệm cơ bản, mọi con số là ước lượng của khoá học cần đo lại. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. Grokking Modern System Design · ch.21 Distributed Search · bài "Indexing" · mục "Inverted index", "Advantages of using an inverted index", "Disadvantages of using an inverted index". ↩

4. Redis in Action · ch.7 Search-based applications · §7.1.1 Basic search theory (tr. 155–161). ↩

5. Grokking Modern System Design · ch.21 Distributed Search · bài "Design of a Distributed Search" · mục "Distributed indexing and searching" (Searching). ↩ ↩²

6. Grokking Modern System Design · ch.21 Distributed Search · bài "Design of a Distributed Search" · mục "Distributed indexing and searching" (Document partitioning, Term partitioning, Indexing). ↩ ↩² ↩³ ↩⁴

7. Grokking Modern System Design · ch.21 Distributed Search · bài "Design of a Distributed Search" · mục "Replication" và "Replication factor and replica distribution". ↩ ↩²

8. Grokking Modern System Design · ch.21 Distributed Search · bài "Problems with the proposed design" · mục "Solution" và "Separate the indexing and search". ↩ ↩²

9. Redis in Action · ch.7 · §7.1.1 Basic search theory (parsing, tokenization, stop words; Listing 7.1). ↩

10. Chưa có nguồn trong thư viện: asciifolding, tách từ tiếng Việt và shingle là kỹ thuật thực hành của khoá học; thư viện không có sách về xử lý ngôn ngữ tiếng Việt. ↩

11. MongoDB: The Definitive Guide 2e (file .zip, tải về giải nén) · ch.4 Querying · mục "Avoiding Large Skips" (tr. 70). ↩

12. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.3.1 Choosing a view datastore, bảng 7.1 "Query-side view stores" (text search bằng Elasticsearch, tr. 238). ↩

13. Microservices Patterns (file .zip, tải về giải nén) · ch.3 · §3.3.7 Transactional messaging (Transactional outbox, Transaction log tailing, Debezium). ↩

14. Microservices Patterns (file .zip, tải về giải nén) · ch.3 · §3.3.6 Handling duplicate messages. ↩

15. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.3.2 Data access module design (Handling concurrency, Idempotent event handlers). ↩

16. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.3.3 Adding and updating CQRS views (tr. 241–242). ↩

17. Grokking Modern System Design · ch.21 Distributed Search · bài "Design of a Distributed Search" · mục "Indexing on a centralized system" (index quá lớn cho một máy). ↩

18. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · §2.4 Day 3: Full-Text and Multidimensions (Fuzzy Searching, Try a Trigram, Full-Text Fun, TSVector and TSQuery). ↩ ↩²

19. Redis in Action · ch.6 Application components in Redis · §6.1 Autocomplete (tr. 111–116). ↩

20. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.2.4 The drawbacks of CQRS (Dealing with the replication lag, tr. 236). ↩