← Chương trước: Phần 3: UUIDv7 vs Snowflake vs BIGINT | Mục lục Series | Chương tiếp theo: Phần 5: Sharded MySQL vs. TiDB →

MariaDB vs. MySQL: Phân Kỳ Kiến Trúc, Storage Engines & Thread Pool

Answer-first: MariaDB không còn là bản thay thế trực tiếp của MySQL. MySQL 8.4/9.0 thống trị Cloud-Native (AWS Aurora) nhờ InnoDB tối ưu, Binary JSONB O(1) và native Vector AI. Ngược lại, MariaDB 11.x vượt trội trên Bare-metal/Kubernetes nhờ Open-source ThreadPool (50k+ conns), Galera Multi-Master zero-lag và MyRocks LSM nén 70% đĩa.

🇬🇧 Read the English version of this article on tanhdev.com

Để xây dựng kiến trúc backend đồng bộ và tối ưu hóa hệ thống microservices chịu tải cao, bạn có thể tham khảo thêm các bài phân tích chuyên sâu tại tanhdev.com.

1. Bối Cảnh & Sự Chấm Dứt Của Kỷ Nguyên “Drop-in Replacement”

Trong suốt một thập kỷ (2010 – 2020), cộng đồng kỹ thuật backend xem MariaDB như một bản sao hoàn hảo (drop-in replacement) của MySQL. Lập trình viên có thể thay thế mysqld bằng mariadbd mà không cần sửa đổi bất kỳ dòng lệnh SQL, ORM mapping hay driver kết nối nào.

Tuy nhiên, bước sang giai đoạn 2024 – 2026, với sự ra đời của MySQL 8.0 / 8.4 LTS / 9.0 từ Oracle và MariaDB 10.11 LTS / 11.4 LTS từ MariaDB Foundation, hai hệ thống đã chính thức phân kỳ kiến trúc (Architectural Divergence):

flowchart TD
    subgraph Ancestry ["Gốc Chung (Pre-2010)"]
        Original["MySQL 5.1 / 5.5 Codebase (Monty Widenius / Sun / Oracle)"]
    end

    subgraph OracleTrack ["Nhánh Oracle: MySQL 8.0 -> 8.4 LTS -> 9.0"]
        MySQL_InnoDB["Deep InnoDB Focus (Redo Log Lock-free Rings, Doublewrite)"]
        MySQL_JSON["Native Binary JSON (JSONB) with O(1) Partial Updates"]
        MySQL_Cloud["Tier-1 Cloud Native (AWS Aurora Distributed Log Storage)"]
        MySQL_AI["MySQL 9.0 Native VECTOR Type & Embedding Distance"]
        MySQL_Repl["MySQL GTID (UUID:Seq) & Group Replication (Paxos MGR)"]
    end

    subgraph MariaDBTrack ["Nhánh MariaDB Foundation: 10.11 LTS -> 11.4 LTS"]
        Maria_ThreadPool["Built-in Async ThreadPool (Free Open-Source 100k conns)"]
        Maria_Engines["Pluggable Multi-Engines: MyRocks (LSM), ColumnStore, S3, Aria"]
        Maria_Temporal["SQL:2011 System-Versioned Tables (Automated Audit Trail)"]
        Maria_Galera["Galera Cluster 4 (Synchronous Multi-Master Active-Active)"]
        Maria_Repl["MariaDB GTID (Domain-Server-Seq)"]
    end

    Original -->|"Fork 2009"| MariaDBTrack
    Original -->|"Acquisition"| OracleTrack

Hệ quả của sự phân kỳ này là:

1. Không thể chuyển đổi nhị phân (Binary Incompatibility): Data directory (/var/lib/mysql) của MySQL 8.4 không thể đọc được bởi MariaDB 11.x và ngược lại.
2. Replication GTID bất tương thích: Giao thức GTID của MySQL (UUID:Sequence) và MariaDB (Domain_ID-Server_ID-Sequence) hoàn toàn tách biệt, ngăn chặn việc dựng replication dị thể giữa 2 master-slave khác dòng.
3. Mô hình Tối ưu hóa Trái ngược: MySQL tập trung vào kiến trúc đơn công cụ (Single-Engine InnoDB) kết hợp hạ tầng đám mây phân tán, trong khi MariaDB theo đuổi triết lý đa công cụ cắm ghép (Pluggable Engines) và tối ưu hóa tài nguyên phần cứng tại chỗ.

2. So Sánh Kiến Trúc Bộ Nhớ & Storage Engines: InnoDB vs. MyRocks / ColumnStore

Sự khác biệt nền tảng lớn nhất giữa MySQL và MariaDB nằm ở cách tiếp cận động cơ lưu trữ (Storage Engine Architecture).

flowchart LR
    subgraph MySQL_Arch ["Kiến Trúc MySQL 8.4+ (Single Engine InnoDB)"]
        direction TB
        M_SQL["SQL Layer / Parser / Cost-Based Optimizer"] --> M_Buffer["InnoDB Buffer Pool (128MB-1TB)"]
        M_Buffer --> M_Double["Doublewrite Buffer"]
        M_Buffer --> M_Redo["Lock-free Redo Log Ring"]
        M_Buffer --> M_BTree["B+ Tree Clustered Index (.ibd)"]
    end

    subgraph Maria_Arch ["Kiến Trúc MariaDB 11.x (Pluggable Engines)"]
        direction TB
        V_SQL["SQL Layer / Optimizer v2"] --> V_Router{"Engine Dispatcher"}
        V_Router --> V_InnoDB["InnoDB Engine (OLTP Standard)"]
        V_Router --> V_Rocks["MyRocks Engine (LSM-Tree: RocksDB)"]
        V_Router --> V_Col["ColumnStore Engine (OLAP Columnar)"]
        V_Router --> V_Aria["Aria Engine (Crash-safe Temp Tables)"]
        V_Router --> V_S3["S3 Storage Engine (Cold Storage)"]
    end

2.1. Độc Quyền InnoDB (MySQL) vs. Sức Mạnh Đa Động Cơ (MariaDB)

• 1. MySQL: Tối Ưu Cực Hạn Cho B+ Tree InnoDB MySQL 8.4 LTS dành toàn bộ tài nguyên R&D để gia cố InnoDB:

• Lock-Free Redo Log Buffering: Giảm thiểu tranh chấp mutex khi hàng nghìn goroutines cùng ghi dữ liệu đồng thời.

• Parallel Index Build: Xây dựng secondary index song song bằng nhiều luồng CPU, tăng tốc câu lệnh ALTER TABLE ADD INDEX gấp 4–6 lần.

• Dedicated TempTable Engine: Thay thế hoàn toàn MyISAM cho bảng tạm bằng engine in-memory chuyên dụng, tự động chuyển đổi sang file đĩa InnoDB nén khi vượt ngưỡng bộ nhớ.

• 2. MariaDB: Hệ Sinh Thái Pluggable Engines Cho Mọi Tải Dữ Liệu MariaDB cho phép kỹ sư chọn lựa engine phù hợp cho từng bảng dữ liệu trong cùng một database:

• MyRocks Engine (LSM-Tree via RocksDB):

  • Thay thế cấu trúc B+ Tree bằng Log-Structured Merge-tree (LSM).
  • Tối ưu hóa ghi (Write Amplification Reduction): Mọi thao tác ghi được nạp tuần tự vào MemTable (RAM) rồi flush thành các tệp SSTables trên đĩa.
  • Tiết kiệm 70% Dung Lượng Đĩa: Áp dụng thuật toán nén Zstandard (zstd) cho các tầng SSTable sâu, giảm chi phí lưu trữ từ 1TB xuống còn 300GB.
  • Khi nào chọn MyRocks: Bảng ghi nhật ký giao dịch, Event Stream, Time-series, IOT Telemetry nơi tần suất INSERT/UPDATE vượt quá 20,000 ops/sec.

• ColumnStore Engine (Massive Parallel Processing OLAP):

  • Lưu trữ dữ liệu theo từng cột thay vì từng hàng.
  • Cho phép thực thi các câu lệnh tổng hợp phức tạp (SUM, AVG, COUNT DISTINCT trên hàng trăm triệu bản ghi) với tốc độ nhanh gấp 10–50 lần InnoDB mà không cần đồng bộ dữ liệu sang ClickHouse hay BigQuery.

• Aria Engine (Crash-Safe System Tables):

  • Thay thế MyISAM cho bảng nội bộ của hệ thống và bảng tạm phức tạp. Aria ghi journal log đảm bảo phục hồi dữ liệu tức thì sau khi sập nguồn (Crash-Safe) mà không bị khóa bảng (Table-level locking) như MyISAM cũ.

Bảng So Sánh Chỉ Số Kỹ Thuật Storage Engines

3. Concurrency Model: Thảm Họa Thread-Per-Connection vs. Native ThreadPool

Một trong những lý do lớn nhất khiến các hệ thống Microservices tải cao trên Kubernetes bị nghẽn hiệu năng bắt nguồn từ Mô hình Quản lý Luồng Kết nối (Connection Concurrency Model).

[MySQL Community: One-Thread-Per-Connection]
Pod 1 (100 conns)  ──┐
Pod 2 (100 conns)  ──┼──> 5,000 Connections ──> 5,000 OS Threads ──> CPU Thrashing & Context Switch Loss
Pod N (100 conns)  ──┘                          (Stack Memory = 5000 x 2MB = 10GB RAM)

[MariaDB Community: Asynchronous ThreadPool]
Pod 1 (100 conns)  ──┐
Pod 2 (100 conns)  ──┼──> 50,000 Connections ──> Linux Epoll ──> Worker Pool (32 Threads) ──> CPU Cores
Pod N (100 conns)  ──┘                          (Stack Memory < 150MB, Zero Thrashing)

3.1. Phân Tích Điểm Gãy Của MySQL Community (One-Thread-Per-Connection)

Trong phiên bản MySQL Community Edition miễn phí:

• Mỗi khi client mở một kết nối socket, MySQL khởi tạo một OS Thread độc lập.
• Mặc định mỗi thread tiêu tốn từ 1MB đến 2MB bộ nhớ Thread Stack (thread_stack).
• Khi cụm Kubernetes scale lên 50 pods microservices, mỗi pod duy trì connection pool gồm 100 kết nối $\longrightarrow$ Tổng cộng 5,000 kết nối đồng thời.
• Hệ quả sụp đổ thông lượng:
  1. Lãng phí bộ nhớ: $5,000 \times 2\text{MB} = 10\text{GB}\text{ RAM}$ bị giam giữ chỉ để nuôi các thread stack nhàn rỗi (idle threads).
  2. Tranh chấp Context Switching: Khi 5,000 threads cùng tranh giành 16 hoặc 32 nhân CPU vật lý, Linux Scheduler tiêu tốn tới 40% – 60% năng lực CPU chỉ để chuyển đổi ngữ cảnh (Context Switching Overhead) thay vì thực thi lệnh SQL.
• Để giải quyết trên MySQL: Doanh nghiệp bắt buộc phải trả tiền mua bản quyền MySQL Enterprise Edition để có module Enterprise Thread Pool, hoặc tự vận hành thêm cụm proxy trung gian như ProxySQL hay Vitess.

3.2. Sức Mạnh ThreadPool Bất Đồng Bộ Mã Nguồn Mở Của MariaDB

MariaDB tích hợp sẵn plugin ThreadPool hoàn toàn miễn phí ngay trong bản Community:

• Sử dụng cơ chế I/O đa ghép kênh (I/O Multiplexing via Linux epoll).
• Hàng chục nghìn kết nối kết nối vào server được giám sát bởi các epoll descriptors.
• Các yêu cầu SQL phát sinh được phân bổ vào một nhóm Worker Threads cố định (bằng số core CPU vật lý).
• Kết quả: Hệ thống có thể duy trì 50,000 đến 100,000 kết nối nhàn rỗi mà bộ nhớ RAM tiêu thụ chỉ dưới 200MB, giữ CPU hoạt động ở mức 100% hữu ích cho việc tính toán dữ liệu.

Cấu Hình MariaDB ThreadPool Chuẩn Production (my.cnf):

[mariadbd]
# Kích hoạt ThreadPool chuyên dụng
thread_handling = pool-of-threads

# Số lượng thread group (thường cấu hình bằng số CPU cores vật lý)
thread_pool_size = 32

# Thời gian tối đa giữ kết nối nhàn rỗi trước khi trả lại worker (ms)
thread_pool_idle_timeout = 60

# Giới hạn số worker threads tối đa trong toàn bộ pool
thread_pool_max_threads = 2048

# Thời gian chờ trước khi tạo thêm thread mới nếu queue bị nghẽn (ms)
thread_pool_stall_limit = 500

4. Benchmark Thực Nghiệm: Concurrency, Ghi Dữ Liệu & Bộ Nhớ

Chúng tôi thực hiện bài đo lường hiệu năng thực tế (Reproducible Benchmark) trên máy chủ phần cứng tiêu chuẩn: 32 vCPUs, 64GB RAM, NVMe SSD Storage, tải phát sinh từ 100 client workers mô phỏng 10,000 kết nối đồng thời qua sysbench-tpcc:

Bảng Kết Quả Benchmark Đối Đầu

5. JSON, Tính Năng SQL Tiên Tiến & Vector AI: Điểm Thắng Tuyệt Đối Của MySQL

Mặc dù MariaDB chiếm ưu thế lớn về Concurrency và Đa Storage Engine, MySQL 8.4 và 9.0 lại áp đảo hoàn toàn khi bước vào lãnh địa JSON Documents và Vector Search.

[MySQL 8.x Binary JSON Layout (JSONB)]
┌────────────┬──────────────┬───────────────┬───────────────────────────────┐
│ Header     │ Key Offset 1 │ Key Offset 2  │ Value Pointer (Direct Seek)   │
└────────────┴──────────────┴───────────────┴───────────────────────────────┘
-> Cập nhật trường con (JSON_SET) thực hiện in-place O(1) không ghi lại toàn bộ tài liệu.

[MariaDB LONGTEXT JSON Layout]
┌───────────────────────────────────────────────────────────────────────────┐
│ '{"user": {"id": 123, "profile": {"name": "Alice", "role": "admin"}}}'    │
└───────────────────────────────────────────────────────────────────────────┘
-> Cập nhật trường con buộc phải parse lại chuỗi text và ghi đè lại toàn bộ Text Blob.

5.1. Xử Lý JSON Nhị Phân (Binary JSONB) vs. Text Alias

1. MySQL (Binary JSON Format):
   • Lưu trữ JSON theo cấu trúc nhị phân nội bộ có đánh chỉ mục key offset.
   • Cho phép truy xuất trường con bằng phép toán nhảy offset $O(1)$ mà không cần parse toàn bộ cây JSON.
   • Partial In-Place Update: Khi cập nhật một trường giá trị trong JSON doc dung lượng lớn (ví dụ 100KB), MySQL chỉ ghi đè đúng byte thay đổi vào trang bộ nhớ và Redo Log, giúp giảm 90% áp lực ghi I/O.
2. MariaDB (Text-based JSON):
   • Kiểu JSON trong MariaDB thực chất chỉ là alias của kiểu LONGTEXT kèm ràng buộc ẩn CHECK (JSON_VALID(col)).
   • Mỗi thao tác đọc hay sửa đổi đều buộc engine phải parse lại chuỗi UTF-8 từ đầu đến cuối và ghi đè lại toàn bộ 100KB vào Redo Log, gây lãng phí băng thông I/O đĩa nghiêm trọng.

5.2. SQL:2011 System-Versioned Tables: Vũ Khí Độc Quyền Của MariaDB

Ngược lại, nếu ứng dụng của bạn thuộc lĩnh vực FinTech, Ngân hàng, Y tế hoặc Thương Mại Điện Tử đòi hỏi kiểm toán lịch sử thay đổi từng mili-giây, MariaDB sở hữu tính năng System-Versioned Tables mạnh mẽ mà MySQL hoàn toàn không có:

-- Khởi tạo bảng tự động theo dõi lịch sử thay đổi chuẩn SQL:2011 trên MariaDB
CREATE TABLE user_wallets (
    user_id INT PRIMARY KEY,
    balance DECIMAL(15, 2),
    currency VARCHAR(3)
) WITH SYSTEM VERSIONING;

-- Cập nhật số dư người dùng
UPDATE user_wallets SET balance = 5000.00 WHERE user_id = 101;

-- Truy vấn số dư chính xác tại thời điểm 08:00 sáng ngày 01/01/2026 (Time-Travel Query)
SELECT * FROM user_wallets 
FOR SYSTEM_TIME AS OF '2026-01-01 08:00:00' 
WHERE user_id = 101;

MariaDB tự động phân tách dữ liệu hiện tại và dữ liệu lịch sử vào các trang lưu trữ riêng biệt, cho phép truy vấn kiểm toán tức thì mà không làm chậm các câu lệnh SELECT thông thường và hoàn toàn không cần viết một dòng mã trigger hay bảng log thủ công nào.

5.3. MySQL 9.0 Native Vector Embeddings Cho AI Agents

MySQL 9.0 giới thiệu kiểu dữ liệu bản địa VECTOR(dimension) hỗ trợ trực tiếp lưu trữ các vector nhúng (vector embeddings) từ các mô hình OpenAI, Claude, Cohere:

-- Lưu trữ vector embedding 1536 chiều trong MySQL 9.0
CREATE TABLE knowledge_base (
    doc_id BIGINT PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536) NOT NULL
);

-- Tìm kiếm 5 tài liệu tương đồng nhất bằng khoảng cách Cosine Distance
SELECT doc_id, content 
FROM knowledge_base 
ORDER BY VECTOR_DISTANCE(embedding, string_to_vector('[0.012, -0.043, ...]'), 'COSINE') ASC 
LIMIT 5;

6. High Availability & Consensus: Galera Cluster 4 vs. MySQL Group Replication (MGR)

flowchart LR
    subgraph MySQL_HA ["MySQL: Asynchronous / Group Replication (MGR)"]
        direction TB
        M_Primary["Primary Master (R/W)"] -->|"Paxos Consensus"| M_MGR["Group Replication Pool"]
        M_Primary -->|"Binlog Stream (Async/Semi-sync)"| M_Replica["Read Replica (Lag Risk)"]
    end

    subgraph Maria_HA ["MariaDB: Galera Cluster 4 (Multi-Master)"]
        direction TB
        G_Node1["Galera Node 1 (R/W)"] <== "Certification Replication (wsrep)" ==> G_Node2["Galera Node 2 (R/W)"]
        G_Node2 <== "Zero Replication Lag" ==> G_Node3["Galera Node 3 (R/W)"]
    end

6.1. Galera Cluster 4 (MariaDB)

• Cơ chế: Đồng bộ hoàn toàn (Synchronous Replication) thông qua giao thức chứng thực giao dịch (Certification-based replication via wsrep API).
• Ưu điểm:
  • Multi-Master Thực Thụ: Bạn có thể kết nối và gửi lệnh INSERT/UPDATE tới bất kỳ node nào trong cụm 3 nodes.
  • Zero Replication Lag: Dữ liệu cam kết đồng bộ trên toàn bộ cluster trước khi trả về COMMIT SUCCESS cho client.
  • Tự động gia nhập cụm (SST/IST): Khi một node mới khởi động, nó tự động clone dữ liệu từ cụm mà không cần can thiệp thủ công.
• Nhược điểm & Bẫy Lỗi (Failure Modes):
  • Độ trễ cam kết (Commit Latency) phụ thuộc vào Node chậm nhất: Nếu 1 node gặp sự cố mạng hoặc disk lag, toàn bộ cluster bị nghẽn commit.
  • Xung đột Optimistic Lock (Lock Aborts): Nếu 2 node cùng sửa đổi 1 bản ghi tại cùng một thời điểm, node thứ 2 commit sẽ bị hủy (Certification Failure) và ném lỗi Deadlock / WSREP aborted.

6.2. MySQL Group Replication (MGR / InnoDB Cluster)

• Cơ chế: Đồng thuận Paxos (Paxos Consensus Engine), thường cấu hình ở chế độ Single-Primary để đảm bảo an toàn tuyệt đối.
• Ưu điểm:
  • Loại bỏ hoàn toàn xung đột ghi (Write Conflict) nhờ luồng ghi tập trung vào một Master duy nhất.
  • Hỗ trợ cơ chế tự động bầu Master mới (Automated Failover) trong vòng dưới 3 giây khi Master cũ gặp sự cố.
• Nhược điểm:
  • Vẫn tồn tại độ trễ replication trên các Secondary nodes khi Master chịu tải ghi quá nặng (Applier Queue Lag).

7. Đám Mây & FinOps: AWS Aurora vs. Tự Vận Hành Bare-Metal

Chi phí vận hành và tính tương thích trên các nền tảng điện toán đám mây là yếu tố quyết định chiến lược cho doanh nghiệp:

8. Ma Trận Quyết Định Kiến Trúc & Khung Hướng Dẫn Lựa Chọn

flowchart TD
    Start{"Lựa Chọn Cơ Sở Dữ Liệu Nào?"}
    
    Start -->|"Triển khai trên AWS / GCP Cloud"| CloudQ{"Cần Auto-scaling & Managed Storage?"}
    CloudQ -->|"Có"| R_MySQL_Aurora["<b>Chọn MySQL 8.4 (AWS Aurora)</b><br/>Storage phân tán 128TB, Failover <1s, Ecosystem mạnh nhất"]
    CloudQ -->|"Không"| WorkloadQ{"Đặc thù dữ liệu là gì?"}

    Start -->|"Triển khai On-Premise / Bare-metal / K8s"| BareMetalQ{"Yêu cầu hạ tầng chính?"}
    
    BareMetalQ -->|"10,000+ Kết Nối Microservices không dùng Proxy"| R_Maria_Pool["<b>Chọn MariaDB 11.4 + ThreadPool</b><br/>Tiết kiệm RAM, không nghẽn CPU context switch"]
    BareMetalQ -->|"Active-Active Multi-Master Zero-Lag"| R_Maria_Galera["<b>Chọn MariaDB Galera Cluster 4</b><br/>Write anywhere, tự động đồng bộ cụm"]
    BareMetalQ -->|"Tải Ghi Cực Lớn / IoT / Log Giảm Chi Phí SSD"| R_Maria_Rocks["<b>Chọn MariaDB + MyRocks Engine</b><br/>LSM-Tree nén 70% đĩa, hấp thụ bão ghi"]

    WorkloadQ -->|"Nhiều JSON Documents & AI Vector Search"| R_MySQL_JSON["<b>Chọn MySQL 8.4 / 9.0</b><br/>Binary JSONB cập nhật O(1) và native VECTOR"]
    WorkloadQ -->|"Kiểm Toán Bất Biến & Du Hành Thời Gian (FinTech)"| R_Maria_Temp["<b>Chọn MariaDB System-Versioned</b><br/>SQL:2011 Temporal Tables chuẩn hóa"]

9. Hỏi & Đáp Kỹ Thuật (Frequently Asked Questions)

Q1: Tôi có thể chuyển đổi trực tiếp từ MySQL 8.0 sang MariaDB 11.x bằng replication không?

Không. Kể từ MySQL 8.0, định dạng tệp dữ liệu bảng (.ibd), cấu trúc data dictionary nội bộ và cơ chế Global Transaction Identifier (GTID) đã phân kỳ hoàn toàn. Để chuyển đổi giữa hai hệ thống, bạn bắt buộc phải xuất dữ liệu logic (mysqldump hoặc mydumper/myloader) và nạp lại từ đầu.

Q2: Khi nào nên sử dụng MyRocks Engine thay vì InnoDB trên MariaDB?

Hãy chọn MyRocks khi bạn có bảng dữ liệu kích thước khổng lồ (vượt quá 500GB – vài Terabytes) với đặc thù ghi liên tục (Write-Heavy) như bảng Audit Logs, Clickstream, User Activities, hoặc IoT Sensors. MyRocks sử dụng LSM-Tree và nén Zstandard giúp tiết kiệm tới 70% chi phí ổ cứng SSD và bảo vệ độ bền ghi của chip nhớ flash (TBW).

Q3: Tại sao MariaDB ThreadPool lại vượt trội hơn MySQL Community ở quy mô 10,000 kết nối?

MySQL Community tạo 1 thread hệ điều hành cho mỗi kết nối ($10,000 \text{ threads} \approx 20\text{GB RAM}$), khiến CPU bị nghẽn do tranh chấp Context Switching. MariaDB ThreadPool sử dụng cơ chế gom kết nối qua epoll và chỉ duy trì một lượng worker threads tương ứng với số nhân CPU vật lý ($<200\text{MB RAM}$), loại bỏ hoàn toàn hiện tượng sụt giảm thông lượng.

Q4: Khi nào bắt buộc phải chọn MySQL 8.4/9.0 thay vì MariaDB?

Bắt buộc chọn MySQL khi bạn xây dựng hệ thống trên nền tảng AWS (để tận dụng sức mạnh vượt trội của AWS Aurora MySQL), khi ứng dụng thao tác liên tục với các tài liệu JSON phức tạp cần cập nhật cục bộ (In-Place Partial JSON Update), hoặc khi cần lưu trữ và truy vấn trực tiếp vector embeddings của AI Agents.

❓ Câu Hỏi Thường Gặp (FAQ)

Q1: MariaDB vs. MySQL: Phân Kỳ Kiến Trúc, Storage Engines & Thread Pool giải quyết vấn đề cốt lõi nào trong kiến trúc hệ thống?

Phân tích đối đầu MariaDB 11.x vs MySQL 8.4/9.0: Đánh đổi giữa InnoDB và MyRocks/ColumnStore, Native ThreadPool, Binary JSONB, Galera Multi-Master và FinOps.

Q2: Những lưu ý quan trọng nhất khi triển khai thực tế là gì?

Cần chú trọng phân tầng ranh giới trách nhiệm (bounded context), thiết lập cơ chế fallback dự phòng, và giám sát chặt chẽ qua metrics OpenTelemetry để phát hiện sớm các điểm nghẽn.

Q3: Làm sao để kiểm thử và đánh giá hiệu quả sau khi áp dụng?

Áp dụng kiểm thử tải (load test), benchmark độ trễ P95/P99 trước và sau triển khai, kết hợp tracing phân tán để xác minh tính ổn định dưới tải cao.