Sharding & Replication

1. Sharding (Phân mảnh) - Horizontal Scaling

Hãy tưởng tượng bạn có một Index nặng 500GB, nhưng ổ cứng server chỉ có 200GB. Bạn không thể lưu nó trên một máy. Sharding giải quyết việc này bằng cách chia nhỏ Index ra.1

Bản chất kỹ thuật

  • Shard = Lucene Instance:2 Mỗi Shard thực chất là một "Search Engine" độc lập và đầy đủ chức năng (là một instance của Apache Lucene).3

  • Phân tán: Các Shard này có thể nằm rải rác trên nhiều Node khác nhau trong Cluster.

  • Parallel Processing: Khi bạn query, ES gửi lệnh đến tất cả các Shard song song, sau đó tổng hợp kết quả.

Routing: Tại sao không thể thay đổi số lượng Primary Shard?

Đây là câu hỏi phỏng vấn kinh điển. Khi bạn tạo Index với 5 Shards, bạn không thể sửa thành 10 Shards sau đó (trừ khi Reindex). Tại sao?

Elasticsearch quyết định một Document nằm ở Shard nào dựa trên công thức Hashing:

$$shard = hash(routing) \pmod{number\_of\_primary\_shards}$$

  • routing: Mặc định là _id của document.

  • Nếu bạn thay đổi number_of_primary_shards (ví dụ từ 5 lên 10), công thức trên sẽ ra kết quả khác -> ES sẽ tìm sai địa chỉ và không thấy dữ liệu đâu cả.

2. Replication (Sao lưu) - High Availability & Read Throughput

Sharding giúp chia tải, nhưng nếu một Node chứa Shard bị cháy ổ cứng thì sao? Dữ liệu mất vĩnh viễn. Replication sinh ra để giải quyết việc này.

Cơ chế

  • Primary Shard (Bản chính): Nhận các thao tác Ghi (Index/Delete/Update).

  • Replica Shard (Bản sao): Là bản copy chính xác của Primary.

    • Dùng để Failover: Nếu Primary chết, một Replica sẽ được thăng cấp lên làm Primary ngay lập tức.4

    • Dùng để Scale Read: ES thông minh sẽ điều hướng các request Đọc (Search) vào các Replica để giảm tải cho Primary.5

Nguyên tắc an toàn (Anti-affinity)

Elasticsearch không bao giờ đặt Primary Shard và Replica của nó trên cùng một Node vật lý.

  • Ví dụ: Node 1 chứa Shard A (Primary). Node 2 sẽ chứa Shard A (Replica).

  • Nếu Node 1 chết, Node 2 vẫn còn dữ liệu để phục vụ.

3. Quy trình ghi dữ liệu (Write Path) - Data Consistency

Là Backend Engineer, bạn cần biết dữ liệu được đảm bảo nhất quán thế nào (Consistency Model):

  1. Request ghi đến Coordinator Node.

  2. Coordinator tính hash để tìm Primary Shard và chuyển request đến đó.

  3. Primary Shard validate và thực hiện ghi cục bộ.

  4. Nếu thành công, Primary gửi request song song đến tất cả các Replica Shards đang active (In-sync copies).

  5. Khi tất cả (hoặc đủ số lượng wait_for_active_shards) Replicas báo thành công, Primary mới trả về kết quả OK cho Client.

-> Hệ quả: Tốc độ Write sẽ chậm hơn tốc độ Read (vì phải chờ sync), nhưng đảm bảo dữ liệu an toàn.

4. Chiến lược Sharding & Sai lầm thường gặp (Oversharding)

Đây là lỗi phổ biến nhất khiến Cluster bị sập ("Red state").

Sai lầm: "Càng nhiều Shard càng tốt?"

KHÔNG.

Mỗi Shard là một Lucene Index, nó tiêu tốn tài nguyên cố định (File Descriptors, RAM cho Memory Mapping, CPU cho thread maintenance) kể cả khi không có dữ liệu.6

  • Nếu bạn có 1000 Shards nhỏ (vài MB) trên một Node -> Node sẽ bị OOM (Out Of Memory) do Overhead quản lý quá lớn. Đây gọi là Oversharding.

Quy tắc vàng (Rule of Thumb) cho Senior:

  1. Kích thước Shard: Giữ kích thước mỗi Shard trong khoảng 10GB - 50GB.7

    • Dưới 10GB: Lãng phí tài nguyên quản lý.

    • Trên 50GB: Việc Rebalance (di chuyển shard khi thêm node mới) hoặc Recover (khôi phục khi node chết) sẽ rất lâu, gây nghẽn mạng.

  2. Số lượng Shard trên mỗi GB Heap: Cố gắng giữ dưới 20 Shards / 1GB Heap Memory. (Ví dụ Node có 30GB Heap -> tối đa 600 Shards).

5. Cluster Health (Màu sắc của sức khỏe)

Khi vận hành, bạn sẽ thấy trạng thái Cluster:

  • 🟢 GREEN: Tất cả Primary và Replica đều đã được gán (assigned) vào các node. Hệ thống khỏe mạnh 100%.

  • 🟡 YELLOW: Tất cả Primary đều ổn (vẫn Ghi/Đọc được), nhưng một số (hoặc tất cả) Replica chưa được gán (thường do mất 1 node hoặc không đủ ổ cứng). Dữ liệu vẫn an toàn nhưng không có tính dự phòng cao.

  • 🔴 RED: Ít nhất một Primary bị mất. Mất dữ liệu hoặc dữ liệu không thể truy cập được một phần. Cần can thiệp khẩn cấp.

Tóm tắt kiến trúc

Khái niệm

Vai trò

Lưu ý cho Senior

Shard

Đơn vị lưu trữ vật lý (Lucene Index).

Immutable routing (không đổi số lượng sau khi tạo).

Primary

Xử lý Write + Read.

Bottleneck của việc ghi.

Replica

Failover + Read scaling.

Tăng Read throughput nhưng tốn dung lượng đĩa gấp đôi.

Node

Máy chủ vật lý/ảo chứa Shards.

Tránh Oversharding (quá nhiều shard nhỏ trên 1 node).

PreviousAggregationsNextMongoDB

Last updated