Elasticsearch 1 — Tổng quan & định vị

Hình dung ô tìm kiếm trên Internet Banking của ngân hàng. Khách gõ "chuyen tien viettel thang 3", không dấu, sai chính tả nhẹ, và mong hệ thống trả về ngay những giao dịch nạp tiền Viettel trong tháng 3, xếp giao dịch liên quan nhất lên đầu. Nếu bạn ném yêu cầu đó vào một câu LIKE '%chuyen tien%' trên PostgreSQL với hàng trăm triệu dòng giao dịch, bạn sẽ nhận về một lần quét bảng toàn phần chậm chạp, không xử lý được dấu tiếng Việt, không hiểu "chuyen" gần với "chuyển", và không có khái niệm "liên quan nhất". Đây chính là lớp bài toán mà Elasticsearch sinh ra để giải.

Bài này là nền móng của cả series. Mục tiêu không phải dạy bạn viết truy vấn ngay, mà dựng một mô hình tinh thần đúng: Elasticsearch là loại công cụ nào, khác database truyền thống ở đâu, đứng ở vị trí nào trong bức tranh hạ tầng dữ liệu, và — quan trọng không kém — nó không giải bài toán gì. Có nền đó rồi, các bài sau — tài liệu & index, Query DSL, aggregations, indexing & ingest, cluster & scaling, hiệu năng & vận hành, use case ngân hàng — sẽ ăn khớp thay vì rời rạc.

Lưu ý về sandbox: SQL sandbox của Knowledge Base chạy trên PostgreSQL. Elasticsearch không dùng SQL mà dùng Query DSL — các truy vấn ở dạng JSON gửi qua REST API. Mọi khối JSON trong series này không chạy được trong sandbox; chúng chỉ mang tính minh hoạ.

Elasticsearch là gì

Elasticsearch là một search & analytics engine phân tán, mã nguồn mở, xây trên nền Apache Lucene. Ghép các tính từ đó lại sẽ ra bản chất:

• Search engine: cốt lõi của Elasticsearch là tìm kiếm văn bản (full-text search) — trả lời câu hỏi "những tài liệu nào liên quan tới từ khoá này, và liên quan tới mức nào". Nó không chỉ trả về đúng/sai như một câu WHERE, mà còn chấm điểm mỗi kết quả rồi xếp hạng.
• Analytics engine: ngoài tìm kiếm, Elasticsearch tổng hợp dữ liệu rất mạnh qua aggregations — đếm, gom nhóm, dựng histogram theo thời gian, tính phân vị... Đây là thứ khiến nó trở thành xương sống của các dashboard giám sát log.
• Phân tán (distributed): dữ liệu được chia thành các shard và nhân bản thành replica, trải trên nhiều node. Một cluster có thể mở rộng từ một máy tới hàng trăm máy, lưu hàng tỷ tài liệu, mà mô hình dữ liệu với người dùng gần như không đổi.
• Xây trên Lucene: Apache Lucene là thư viện tìm kiếm Java kỳ cựu, cung cấp cấu trúc dữ liệu cốt lõi là inverted index. Elasticsearch bọc Lucene lại, thêm phân tán, REST API, và quản trị cluster để biến một thư viện thành một hệ thống chạy được ở quy mô lớn.

Elasticsearch là document-oriented: đơn vị dữ liệu là document — một bản ghi JSON — được nhóm vào index (tương tự khái niệm "bảng"). Không có schema cứng như SQL; bạn ném JSON vào, Elasticsearch tự suy kiểu (dynamic mapping), dù trong thực tế nên định nghĩa mapping rõ ràng. Chi tiết mô hình này để dành cho bài 2.

Search engine khác database ở chỗ nào

Đây là điểm mấu chốt cần khắc cốt. Một RDBMS như PostgreSQL và một search engine như Elasticsearch trả lời hai loại câu hỏi khác nhau về bản chất.

Database truyền thống tối ưu cho truy vấn chính xác. Bạn hỏi "tài khoản nào có balance > 1000000 và currency = 'VND'", database dùng B-tree index để nhảy thẳng tới đúng các dòng thoả điều kiện. Kết quả là một tập hợp rời rạc: có hoặc không, không có khái niệm "dòng này khớp hơn dòng kia".

Search engine tối ưu cho tìm kiếm liên quan (relevance). Bạn hỏi "tài liệu nào nói về chuyển tiền quốc tế", và mỗi tài liệu nhận một điểm relevance — con số phản ánh mức độ khớp. Kết quả được xếp hạng theo điểm, khớp nhất lên đầu. Hai công nghệ nền giúp việc này:

1. Inverted index. Thay vì lưu "dòng → nội dung" như database, inverted index lưu ngược lại: "từ → danh sách tài liệu chứa từ đó". Khi index một câu, Elasticsearch chạy analyzer: tách câu thành token (từ), hạ chữ thường, có thể bỏ dấu, cắt về gốc từ (stemming)... rồi ghi mỗi token vào từ điển. Kết quả:

Token	Xuất hiện trong document
chuyen	doc1, doc7, doc12
tien	doc1, doc3, doc7
quoc	doc7, doc20

Khi bạn tìm "chuyen tien", engine chỉ cần tra hai từ trong từ điển và giao/hợp các danh sách — cực nhanh, không phải quét toàn bảng. Chính analyzer là thứ giúp "chuyen tien" (không dấu) khớp được với "chuyển tiền" (có dấu), điều mà LIKE không bao giờ làm nổi.

2. Chấm điểm relevance. Elasticsearch (qua Lucene) mặc định dùng thuật toán BM25 để tính điểm. Trực giác của BM25: một từ hiếm (như "SWIFT") xuất hiện trong một tài liệu thì đáng giá hơn một từ phổ biến (như "tiền"); từ khoá xuất hiện nhiều lần trong tài liệu ngắn thì khớp mạnh hơn trong tài liệu dài. Điểm số này cho phép xếp hạng — thứ mà database chính xác không có.

Bảng đối chiếu để cầm về:

Khía cạnh	RDBMS (PostgreSQL)	Elasticsearch
Câu hỏi cốt lõi	Khớp chính xác điều kiện	Liên quan tới mức nào
Cấu trúc index	B-tree (dòng → giá trị)	Inverted index (từ → dòng)
Kết quả	Tập rời rạc, có/không	Tập xếp hạng theo điểm
Xử lý ngôn ngữ	Hạn chế (LIKE, tsvector)	Analyzer mạnh: token, stemming, bỏ dấu
Giao dịch ACID	Có, mạnh	Không (near-real-time, không transaction)
Nguồn sự thật (source of truth)	Có, thường là chính	Thường là bản sao để tìm/phân tích

Ý cuối cùng rất quan trọng thực chiến: Elasticsearch hiếm khi là nguồn sự thật. Nó không có transaction đa-document, không phù hợp làm nơi lưu chính khoản tiền của khách. Mô hình phổ biến là dữ liệu gốc nằm ở database giao dịch (Oracle, PostgreSQL), rồi được đồng bộ sang Elasticsearch để phục vụ tìm kiếm và phân tích.

Elastic Stack / ELK

Elasticsearch hiếm khi đi một mình. Nó là trung tâm của một bộ công cụ gọi là Elastic Stack, mà tên cũ quen thuộc là ELK (Elasticsearch + Logstash + Kibana). Sau này Elastic thêm Beats, đổi tên bộ thành "Elastic Stack", nhưng dân vận hành vẫn hay gọi ELK.

Vai trò từng thành phần:

• Beats — bộ agent thu thập nhẹ, cài ngay tại máy nguồn. Filebeat đọc file log, Metricbeat thu số liệu hệ thống (CPU, RAM), Packetbeat bắt gói mạng, Winlogbeat đọc Windows Event Log. Beats chỉ làm nhiệm vụ hứng và chuyển tiếp, tốn rất ít tài nguyên nên cài được lên hàng nghìn máy.
• Logstash — công cụ xử lý dữ liệu (ETL cho log). Nó nhận dữ liệu thô, dùng các filter (nổi tiếng là grok) để parse dòng log không cấu trúc thành các trường JSON, làm giàu (thêm geo-IP, tra cứu bảng phụ), chuẩn hoá rồi đẩy vào Elasticsearch. Logstash mạnh nhưng nặng; với nhu cầu đơn giản có thể thay bằng Ingest Pipeline chạy ngay trong Elasticsearch.
• Elasticsearch — trái tim: lưu trữ, đánh index, tìm kiếm và tổng hợp.
• Kibana — lớp giao diện web: khám phá dữ liệu (Discover), dựng biểu đồ và dashboard, tạo cảnh báo (alerting), và là bảng điều khiển cho các tính năng APM, SIEM. Không có Kibana thì Elasticsearch chỉ nói chuyện qua API.

Một cách nhìn gọn: Beats/Logstash lo đưa dữ liệu vào, Elasticsearch lo lưu và tìm, Kibana lo trình bày.

Các nhóm use case chính

Bốn nhóm bài toán mà Elasticsearch được dùng nhiều nhất:

1. Full-text search. Đây là gốc rễ. Tìm kiếm sản phẩm trên sàn thương mại điện tử, tìm kiếm nội dung trong hệ thống tài liệu, autocomplete gợi ý khi gõ, tìm khách hàng theo tên/số điện thoại/mã. Trong ngân hàng: ô tìm kiếm giao dịch, tìm hồ sơ khách hàng trong CRM, tra cứu văn bản nội bộ. Điểm mạnh là xử lý ngôn ngữ tự nhiên, chịu được sai chính tả, xếp hạng theo relevance.

2. Log & observability. Đây là use case khiến Elasticsearch phổ biến bùng nổ. Hàng trăm ứng dụng, microservice, server sinh log rải rác — Elastic Stack gom log về một chỗ (log centralization), cho phép tìm một trace_id xuyên nhiều service trong tích tắc, dựng dashboard đếm lỗi theo thời gian, và cảnh báo khi tỷ lệ lỗi vượt ngưỡng. Thay vì SSH vào từng máy grep file log, đội vận hành có một cửa sổ duy nhất.

3. APM (Application Performance Monitoring). Elastic APM cắm agent vào ứng dụng để đo thời gian phản hồi, thông lượng, tỷ lệ lỗi, và distributed tracing — theo dấu một request đi qua các service, chỉ ra service nào là điểm nghẽn. Dữ liệu APM cũng lưu trong Elasticsearch và xem qua Kibana.

4. Security / SIEM. Log bảo mật (đăng nhập, firewall, endpoint) được gom vào Elasticsearch, chạy các quy tắc phát hiện (detection rules) để cảnh báo hành vi bất thường: đăng nhập từ vị trí lạ, dò mật khẩu, truy cập dữ liệu ngoài giờ. Trong ngân hàng, đây là mảnh ghép quan trọng cho giám sát an ninh và hỗ trợ điều tra sự cố.

Điểm chung của cả bốn: dữ liệu lớn, cần tìm kiếm/lọc/tổng hợp nhanh, và thường là theo thời gian. Đó cũng là lúc phải nói về "near-real-time".

Near-real-time nghĩa là gì

Elasticsearch được mô tả là near-real-time (NRT): một document sau khi được index không truy vấn thấy ngay lập tức, mà sau một khoảng gọi là refresh interval (mặc định 1 giây). Lúc refresh, các document mới được đưa vào một segment Lucene mới và trở nên tìm được. Vì vậy có độ trễ ~1 giây giữa "ghi" và "đọc thấy". Với log và tìm kiếm, độ trễ này không đáng kể. Nhưng nó nhắc lại: Elasticsearch không phải database giao dịch — bạn không nên trông đợi read-your-own-write tức thì như trên PostgreSQL.

Định vị: chọn công cụ nào

Elasticsearch mạnh, nhưng đặt sai chỗ sẽ trả giá đắt về chi phí và vận hành. So sánh nó với hai láng giềng hay bị lẫn lộn.

Elasticsearch vs ClickHouse. Cả hai đều "phân tích nhanh trên dữ liệu lớn theo thời gian", nên hay bị coi là thay thế được nhau. Thực ra chúng tối ưu cho hai việc khác nhau. ClickHouse là cơ sở dữ liệu cột (OLAP): vô địch ở các truy vấn tổng hợp quét hàng tỷ dòng — SUM, COUNT, GROUP BY, phân vị — với chi phí lưu trữ thấp nhờ nén cột. Elasticsearch vô địch ở tìm kiếm full-text và lọc theo văn bản nhờ inverted index, và ở việc khám phá log tương tác (search-as-you-type trên log). Quy tắc ngón tay cái:

Nhu cầu	Nên chọn
Tìm kiếm văn bản, xếp hạng relevance	Elasticsearch
Khám phá / tìm log theo từ khoá, alerting	Elasticsearch
Aggregation quét hàng tỷ dòng, dashboard OLAP, chi phí lưu tối ưu	ClickHouse
Đếm/tổng hợp metric quy mô cực lớn, lưu lâu dài	ClickHouse

Nhiều tổ chức dùng cả hai: Elasticsearch cho tìm kiếm và log nóng (7–30 ngày gần đây, cần tra cứu tương tác), ClickHouse cho phân tích metric dài hạn và dashboard tổng hợp khối lượng khổng lồ.

Elasticsearch vs full-text của RDBMS. PostgreSQL có sẵn full-text search qua tsvector/tsquery (xem full-text search trên PostgreSQL). Với nhu cầu tìm kiếm vừa và nhỏ — vài triệu dòng, một ngôn ngữ, không cần relevance tinh vi — full-text của Postgres là lựa chọn tuyệt vời: không phải nuôi thêm hệ thống, dữ liệu và tìm kiếm ở cùng một nơi, đồng bộ tức thì. Bạn chỉ nên nhấc sang Elasticsearch khi thực sự cần: relevance/ranking tinh vi, analyzer đa ngôn ngữ, autocomplete/fuzzy nâng cao, quy mô hàng trăm triệu tài liệu, hoặc gom log tập trung. Nguyên tắc: đừng dựng cả một cluster Elasticsearch chỉ để tránh viết một câu tsquery.

OpenSearch. Năm 2021 Elastic đổi giấy phép Elasticsearch (khỏi Apache 2.0 thuần), AWS liền fork từ phiên bản mở cuối cùng thành OpenSearch — mã nguồn mở dưới Apache 2.0, có OpenSearch Dashboards tương đương Kibana. Về cơ bản OpenSearch và Elasticsearch rất giống nhau ở tầng khái niệm và API cũ, nhưng đã phân nhánh và ngày càng khác về tính năng, hiệu năng, giấy phép. Series này bám theo Elasticsearch; phần lớn kiến thức nền (inverted index, mapping, aggregation) áp dụng được cho cả hai, nhưng cú pháp và tính năng mới thì cần tra đúng tài liệu của bản bạn dùng.

Use case thực tế

Bối cảnh. Ngân hàng NCB triển khai tìm kiếm giao dịch cho ứng dụng chăm sóc khách hàng và gom log hệ thống lõi về một chỗ. Quy mô minh hoạ: ~120 triệu giao dịch/năm, log ứng dụng ~40 GB/ngày từ 60 microservice.

Bài toán 1 — Tìm kiếm giao dịch. Nguồn sự thật là core banking (Oracle). Không đặt gánh nặng tìm kiếm lên Oracle, đội dữ liệu dựng pipeline CDC (change data capture) đẩy giao dịch mới sang một index Elasticsearch, mỗi giao dịch là một document gồm: mô tả, kênh, số tiền, ngày, mã khách. Analyzer bỏ dấu tiếng Việt để "chuyen tien" khớp "chuyển tiền". Kết quả: nhân viên gõ "nap the viettel thang 3" nhận về đúng nhóm giao dịch nạp thẻ Viettel, xếp hạng theo relevance, phản hồi dưới 50 ms thay vì hàng chục giây khi quét Oracle bằng LIKE. Oracle vẫn là nơi giữ số dư và đối soát; Elasticsearch chỉ là lớp tìm kiếm.

Bài toán 2 — Phân tích log hệ thống. Filebeat cài trên 60 service đẩy log qua Logstash (parse bằng grok thành các trường: service, level, latency_ms, trace_id), vào Elasticsearch. Trên Kibana, đội vận hành có:

• Dashboard đếm lỗi (level: ERROR) theo phút, chia theo service — dùng aggregation date_histogram.
• Truy trace_id để xem một giao dịch chuyển khoản đi qua những service nào và tắc ở đâu.
• Cảnh báo tự động khi tỷ lệ lỗi của service thanh toán vượt 1% trong 5 phút.

Trước đây, điều tra một sự cố nghĩa là SSH vào nhiều máy và grep file log rời rạc, mất hàng giờ. Với Elastic Stack, thời gian phát hiện và khoanh vùng sự cố rút xuống còn vài phút, và log được giữ tập trung 30 ngày để truy vết. Song song, các metric tổng hợp dài hạn (throughput theo ngày cả năm) được đẩy sang ClickHouse để tối ưu chi phí lưu trữ — mỗi công cụ đúng việc của nó.

Ghi nhớ

• Elasticsearch = search & analytics engine phân tán, xây trên Apache Lucene. Đơn vị dữ liệu là document JSON, gom vào index; truy vấn bằng Query DSL (JSON), không phải SQL.
• Khác biệt cốt lõi với database: search engine dùng inverted index (từ → tài liệu) và chấm điểm relevance (BM25), trả về kết quả xếp hạng; database dùng B-tree và trả về khớp chính xác, rời rạc.
• Analyzer (tách token, hạ chữ, bỏ dấu, stemming) là thứ giúp tìm kiếm chịu được sai chính tả và khác dấu — điều LIKE không làm được.
• Elastic Stack (ELK): Beats & Logstash đưa dữ liệu vào, Elasticsearch lưu + tìm + tổng hợp, Kibana trình bày. Beats nhẹ tại nguồn; Logstash parse/làm giàu; có thể thay Logstash bằng Ingest Pipeline cho nhu cầu đơn giản.
• Bốn nhóm use case: full-text search, log & observability, APM, security/SIEM.
• Near-real-time: document tìm thấy sau refresh interval (~1 giây), không tức thì; Elasticsearch không có transaction, không nên làm nguồn sự thật — thường là bản sao của database gốc.
• Định vị: Elasticsearch cho tìm kiếm & log tương tác; ClickHouse cho aggregation OLAP quy mô lớn, chi phí lưu thấp. Nhu cầu tìm kiếm nhỏ → dùng luôn full-text của PostgreSQL thay vì nuôi một cluster.
• OpenSearch là bản fork của AWS (Apache 2.0) sau khi Elastic đổi giấy phép — giống nhiều ở nền tảng nhưng đã phân nhánh; tra đúng tài liệu bản đang dùng.