TiDB: cơ sở dữ liệu SQL phân tán cho tòa soạn báo điện tử gặp trần MySQL
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
TiDB cho người đang đứng trước giới hạn của MySQL đơn nút
TiDB là cơ sở dữ liệu SQL phân tán viết bằng Go, được README giới thiệu là mã nguồn mở, hướng đám mây, nhắm tới tính sẵn sàng cao, khả năng mở rộng ngang lẫn dọc, nhất quán mạnh và hiệu năng cao. Điểm thu hút thực tế nhất với doanh nghiệp là khả năng tương thích MySQL 8.0, cho phép dùng giao thức và công cụ quen thuộc. [1] Bài này chỉ đọc mã nguồn và tài liệu tại một commit cố định; không có kết luận nào dựa trên việc chạy cụm.
Câu hỏi nên đặt trước khi quan tâm TiDB là: hệ thống hiện tại đã thật sự chạm trần chưa? Một cơ sở dữ liệu phân tán đem lại khả năng mở rộng và chịu lỗi, nhưng đổi lại là nhiều thành phần hơn, nhiều điểm hỏng hơn và đòi hỏi kỹ năng vận hành cao hơn. Nếu một máy MySQL kèm bản sao đọc vẫn đáp ứng được, TiDB khó có lý do để thay.
Về giấy phép, README và tệp LICENSE đều xác nhận Apache 2.0, kèm tuyên bố rằng cả các tính năng cấp doanh nghiệp cũng nằm trong mã nguồn mở. [1][2] Dịch vụ TiDB Cloud là sản phẩm thương mại riêng của công ty, được README gọi là lựa chọn khuyến nghị để bắt đầu. [1]
Khuyến nghị: xem TiDB như ứng viên khi cần ghi và đọc lớn trên cùng dữ liệu giao dịch, cần mở rộng không gián đoạn và có đội vận hành. Không chọn khi quy mô nhỏ hoặc khi nhóm không sẵn sàng học một hệ thống mới.
Khi sharding thủ công trở thành công việc chính của đội kỹ thuật
Một tòa soạn báo điện tử lớn có thể lưu bài viết, bình luận, lượt đọc, tài khoản độc giả và gói đăng ký trong cụm MySQL. Khi lưu lượng tăng đột biến vào giờ có tin nóng, đội kỹ thuật thường xử lý bằng bộ nhớ đệm, bản sao đọc rồi tách bảng thủ công. Mỗi lần tách thêm lại tăng độ phức tạp của truy vấn chéo và của giao dịch.
TiDB nhắm vào đúng điểm đau này: giữ giao diện SQL và giao thức MySQL cho ứng dụng, trong khi dữ liệu được chia và sao chép phía dưới. README nói giao dịch có thể trải qua nhiều nút, dùng giao thức hai pha để bảo đảm ACID, còn Raft giữ nhiều bản sao và chỉ xác nhận khi đa số bản sao đã ghi. [1]
Đồng thời, tòa soạn thường có nhu cầu phân tích gần thời gian thực trên dữ liệu giao dịch, chẳng hạn bài nào đang được đọc nhiều để biên tập viên quyết định đẩy lên trang chủ. README giới thiệu TiFlash như engine cột dành cho kiểu tải HTAP (xử lý giao dịch và phân tích trên cùng hệ thống). [1] Đây là tuyên bố của dự án, bài chưa kiểm chứng.
Hai tầng nhìn từ README và từ chính cây mã nguồn
README tách TiDB thành lớp tính toán và lớp lưu trữ: có thể mở rộng độc lập hai phần, và có hai engine lưu trữ là TiKV (theo hàng) và TiFlash (theo cột), TiFlash nhận dữ liệu từ TiKV bằng giao thức Multi-Raft Learner. [1] Từ cách mô tả này, kho pingcap/tidb chủ yếu là phần máy chủ SQL; mã nguồn của TiKV và thành phần điều phối nằm ngoài các tệp đã đọc nên bài không mô tả chi tiết chúng.
Chỉ mục kiến trúc dành cho các tác tử lập trình trong kho giúp thấy bên trong máy chủ SQL. Có planner và tối ưu hóa, executor cùng biểu thức, session và biến hệ thống cùng giao thức, DDL và siêu dữ liệu, tầng kv và store cùng distsql và mã hóa bảng, domain và thống kê, cuối cùng là parser. [3] Chuỗi phụ thuộc điển hình đi từ planner sang executor rồi biểu thức. [3]
Một chi tiết kiến trúc đáng nhớ là việc đổi lược đồ không được thực hiện ngay trên phiên của người dùng. Phần mô tả luồng DDL cho biết câu lệnh được dịch thành công việc bền vững rồi chạy bởi một nút chủ duy nhất được bầu qua cơ chế dựa trên etcd. [7] Chi tiết này lý giải vì sao thao tác lược đồ trên cụm lớn có hành vi khác với MySQL một máy, và ta sẽ quay lại ở các mục sau.
Cũng có một khung thực thi phân tán nội bộ (DXF) dùng cho lệnh IMPORT INTO và cho việc điền chỉ mục khi thêm index. [10]
Một câu lệnh DDL đi từ phiên SQL tới khi mọi nút cùng thấy lược đồ mới
Luồng DDL được tài liệu cho người phát triển mô tả khá chi tiết, nên là ví dụ tốt về cách hệ thống hoạt động. Ở lớp executor SQL, câu lệnh được chuyển sang module DDL; module này kiểm tra, dựng một công việc (job) bền vững rồi gửi vào hàng đợi có giới hạn, trong khi phiên SQL chờ cho đến khi xong. [7]
Công việc được ghi theo lô vào bảng hệ thống mysql.tidb_ddl_job, rồi báo cho nút chủ. Khi bật tidb_enable_fast_create_table, nhiều công việc tạo bảng có thể được gộp lại thành một. [7] Nút chủ chọn công việc chạy được, phân loại và đẩy vào các nhóm worker, mỗi worker chạy từng bước nhỏ có lưu trạng thái. [7]
Để tránh một nút nhìn lược đồ cũ khi các nút khác đã thấy lược đồ mới, sau mỗi thay đổi trạng thái nút chủ cập nhật phiên bản lược đồ toàn cục và chờ tất cả nút liên quan tải lại đến phiên bản đó. [7][8] Với nhiều lệnh, trạng thái lược đồ đi qua chuỗi đơn giản hóa: none, delete only, write only, reorg rồi public, để mỗi bước nhỏ vẫn an toàn với truy vấn đang chạy. [8]
Về thất bại, công việc phải có thể thử lại và tiếp tục sau khi nút chủ đổi; trạng thái được đọc lại từ bảng hệ thống. Tài liệu cũng nêu rủi ro khi tiến độ reorg không được lưu: việc điền lại sẽ chạy lại từ đầu. [8] Hệ quả vận hành là các DDL lớn nên tách khỏi giờ cao điểm đọc ghi.
Những gì tài liệu xác nhận và những gì chỉ là tuyên bố hướng khách hàng
README liệt kê sáu nhóm tính năng: giao dịch phân tán, mở rộng ngang và dọc, sẵn sàng cao nhờ Raft, HTAP với TiKV và TiFlash, hướng đám mây (triển khai trên đám mây công cộng, tại chỗ hoặc trên Kubernetes với TiDB Operator), và tương thích MySQL 8.0 cùng bộ công cụ di chuyển dữ liệu. [1] Đây là phần giới thiệu của nhà phát triển, nên cần xem nó là điểm xuất phát để kiểm chứng, không phải kết quả kiểm thử.
Phần quick start còn nhắc vector search, changefeed và di chuyển dữ liệu như các khả năng cần khám phá, kèm liên kết sang tài liệu ngoài kho. [1] Bài không có nguồn trong kho để mô tả mức độ trưởng thành của vector search, nên không đề xuất dựa vào nó.
Ở mức mã nguồn, tài liệu DDL cho biết dự án phân biệt phiên bản định dạng đối số công việc: JobVersion1 trước v8.4.0 và JobVersion2 với cấu trúc có kiểu từ v8.4.0. [8] Đây là bằng chứng chính xác về một thay đổi nội bộ giữa các phiên bản, hữu ích khi lập kế hoạch nâng cấp.
Về kế hoạch phát triển, tệp roadmap.md trong kho chỉ gồm một dòng dẫn tới trang lộ trình trên tài liệu của nhà phát triển. [6] Vì vậy bài không đưa tính năng tương lai nào vào danh sách và khuyến nghị người đọc kiểm tra trang đó khi cần.
Ai thật sự cần TiDB và ai chưa cần
Nhóm phù hợp nhất là đội có ứng dụng MySQL gặp giới hạn mở rộng ghi, dung lượng hoặc nhu cầu sẵn sàng cao, và có kỹ sư cơ sở dữ liệu. Khả năng tương thích giúp ứng dụng ít phải đổi mã, theo README. [1] Tuy vậy, từ "tương thích" không đồng nghĩa với "giống hệt"; bài kiểm thử tương thích với đúng ứng dụng của bạn là bắt buộc.
Nhóm khác là đội nền tảng muốn một kho giao dịch chung cho nhiều dịch vụ, hoặc đội cần phân tích nhanh trên dữ liệu tươi và muốn thử HTAP trước khi dựng đường ống ETL riêng.
Ngược lại, không nên dùng nếu ứng dụng nhỏ, nếu độ trễ của từng truy vấn đơn lẻ quan trọng hơn khả năng mở rộng, hoặc nếu đội chưa có người chịu trách nhiệm giám sát cụm.
Tình huống đề xuất: tòa soạn báo điện tử chuẩn bị cho mùa bầu cử và tin nóng
Tình huống này là đề xuất giả định, không phải một dự án đã diễn ra. Một tòa soạn báo điện tử cấp quốc gia, trụ sở Hà Nội, có hệ thống quản trị nội dung dùng MySQL. Giả định rằng bình luận độc giả và bộ đếm lượt đọc là hai bảng ghi nhiều nhất, và mỗi lần có sự kiện lớn đội kỹ thuật phải giảm tính năng để tránh nghẽn.
Đề xuất không thay cả hệ thống ngay. Giai đoạn đầu chọn một miền dữ liệu có ranh giới rõ, ví dụ bình luận và phản ứng của độc giả, cùng nhật ký tương tác phục vụ bảng điều khiển biên tập. Dữ liệu được sao chép từ MySQL sang một cụm TiDB thử nghiệm, ứng dụng bình luận đọc từ cụm mới trong chế độ bóng (shadow) để so sánh kết quả. README nhắc tới bộ công cụ di chuyển dữ liệu nhưng không mô tả quy trình, nên cần đọc tài liệu chính thức bên ngoài kho. [1]
Với bảng điều khiển biên tập, TiFlash là ứng viên nếu muốn chạy truy vấn tổng hợp mà không làm chậm giao dịch bình luận. [1] Đây là giả thuyết cần chứng minh bằng thử nghiệm, nhất là trong cảnh một bài viral kéo theo hàng loạt ghi vào cùng một khóa.
Ranh giới cần giữ: dữ liệu tài khoản độc giả là dữ liệu cá nhân; mọi bản sao sang cụm thử phải ẩn danh. Hệ thống quản trị nội dung cốt lõi chưa nên đổi cho đến khi các tiêu chí đạt. Nếu tòa soạn còn muốn xây kho tri thức nội bộ kiểu second brain, nên xem đó là bài toán khác và chưa cần TiDB.
Triển khai và vận hành: bài toán của đội, không chỉ của công cụ
README liệt kê ba đường khởi đầu: cụm thử cục bộ, Kubernetes với TiDB Operator, và TiDB Cloud do công ty cung cấp. [1] Với vận hành tự quản, tài liệu chi tiết nằm ngoài các tệp đã đọc, nên bài không đưa ra sơ đồ triển khai cụ thể.
Nút chủ DDL chỉ có một tại một thời điểm, và bộ lập lịch của khung thực thi phân tán chỉ chạy khi nút đó là chủ, trong khi bộ quản lý executor chạy trên mọi nút. [7][10] Một số tác vụ nền hết việc khoảng 10 giây thì thoát và được khởi động lại, điều tài liệu gọi là hành vi bình thường để tái sử dụng tài nguyên. [10]
Về nâng cấp, thay đổi định dạng công việc DDL ở v8.4.0 cho thấy chuyển đổi giữa các dòng phiên bản có thể chạm tới cấu trúc nội bộ. [8] Bản phát hành mới nhất được ghi lại lúc thu thập là v7.5.8 ngày 2026-09-17, trong khi nhánh chính đã đề cập đến những thay đổi mới hơn. Bài chưa xác định chính xác dòng LTS nào đang được hỗ trợ, nên phải kiểm tra trang phát hành chính thức.
Kế hoạch vận hành tối thiểu nên có: sao lưu và phục hồi định kỳ có diễn tập, giám sát theo từng thành phần, và quy trình thực hiện DDL ngoài giờ cao điểm.
Bảo mật: quy trình báo lỗ hổng rõ, còn cấu hình cụm là việc của bạn
Tệp SECURITY.md ở thư mục gốc mô tả quy trình tiếp nhận lỗ hổng: gửi báo cáo tới địa chỉ email của nhóm bảo mật, theo mẫu có tiêu đề, tổng quan, thành phần và phiên bản bị ảnh hưởng; nhóm cam kết liên hệ lại trong hai ngày làm việc và yêu cầu người báo giữ kín đến khi có bản vá. [4] Cần để ý rằng thư mục br và parser dùng một địa chỉ khác với tệp gốc, vì vậy người báo lỗi phải đọc đúng tệp theo thành phần. [4][5]
Đây là bằng chứng về quy trình tiếp nhận, không phải bằng chứng về số lượng lỗ hổng hay mức độ an toàn.
Ngoài quy trình, khuyến nghị chung của bài (không trích từ kho) gồm: tài khoản cơ sở dữ liệu riêng cho từng dịch vụ, mã hóa kết nối, sao lưu mã hóa ở nơi riêng và tách môi trường thử khỏi dữ liệu thật.
Với dữ liệu độc giả, cần tuân thủ quy định pháp luật Việt Nam về bảo vệ dữ liệu cá nhân. Mã nguồn mở không tự bảo đảm điều đó; trách nhiệm nằm ở cấu hình, nhật ký truy cập và vòng đời dữ liệu.
Apache 2.0 cho kho này, nhưng đọc kỹ các thư mục con và phần ngoài kho
Tệp LICENSE ở gốc là văn bản Apache License 2.0, và README tuyên bố toàn bộ mã nguồn dưới Apache 2.0 bao gồm cả các tính năng cấp doanh nghiệp. [1][2] Thư mục br cũng có LICENSE.md với văn bản Apache 2.0. [9] Khác với nhiều dự án open core, nguồn đã đọc không cho thấy một thư mục trả phí riêng.
Tuy vậy, danh sách tệp của kho còn có thư mục LICENSES chứa ba tệp giấy phép khác (QL-LICENSE, STRUTIL-LICENSE, Unicode-DFS-2016-LICENSE), tệp ThirdPartyNotices.txt và giấy phép riêng trong thư mục parser. Bài chưa đọc nội dung chúng, nên không khẳng định điều kiện cụ thể. Điều chắc chắn là kho có thành phần bên thứ ba cần tuân thủ riêng.
Apache 2.0 cho phép dùng, sửa và phân phối thương mại với điều kiện giữ thông báo bản quyền và giấy phép, đồng thời có điều khoản bằng sáng chế. Giấy phép chỉ áp dụng cho mã tại commit này. Nó không bao phủ dịch vụ TiDB Cloud, các thành phần như TiKV nếu nằm ở kho khác, nhãn hiệu, tên thương mại, hay dữ liệu của bạn. Đây là phân tích kỹ thuật, không phải tư vấn pháp lý.
Chi phí: chủ yếu là kỹ sư, máy chủ và thời gian di chuyển
Chi phí bản quyền cho mã nguồn tại kho này bằng không theo Apache 2.0, nhưng bài không đưa con số tiền nào vì các tệp đã đọc không nêu giá và dịch vụ TiDB Cloud là sản phẩm thương mại có biểu giá thay đổi. Phần dưới liệt kê loại nguồn lực để dựng dự toán.
Nhân sự là khoản lớn nhất: kỹ sư cơ sở dữ liệu hoặc SRE hiểu hệ phân tán, thời gian của đội ứng dụng để kiểm thử tương thích, và thời gian đào tạo. Một cụm phân tán đòi hỏi thêm kỹ năng đọc chỉ số, xử lý điểm nóng dữ liệu và lập kế hoạch nâng cấp. [7][8]
Hạ tầng gồm nhiều nút tính toán và lưu trữ, mạng nội bộ ổn định giữa các nút, đĩa nhanh cho lưu trữ, thêm nút cột nếu dùng TiFlash cho phân tích. [1] Số lượng bản sao ảnh hưởng trực tiếp dung lượng lưu trữ vì README nói dữ liệu được lưu nhiều bản. [1]
Chi phí khác gồm sao lưu ngoài cụm, giám sát, môi trường thử tương đương sản xuất và thời gian chạy song song hai hệ thống trong giai đoạn di chuyển.
So sánh phương án: MySQL mở rộng dần, sharding, cơ sở dữ liệu phân tán khác và dịch vụ đám mây
Phương án đầu tiên là tiếp tục dùng MySQL đơn nút với bản sao đọc và bộ nhớ đệm. Đây là con đường ít rủi ro nhất cho đến khi chạm trần, vì đội đã biết cách vận hành. Phương án thứ hai là sharding ở tầng ứng dụng hoặc qua proxy, đổi độ phức tạp sang truy vấn chéo shard.
TiDB nằm ở nhóm cơ sở dữ liệu SQL phân tán, nơi độ phức tạp được đẩy xuống hệ thống. Nhóm này còn có những lựa chọn khác như CockroachDB, YugabyteDB hay dịch vụ do nhà cung cấp đám mây vận hành. Mỗi lựa chọn có mức tương thích MySQL hoặc PostgreSQL, giấy phép và mô hình thương mại riêng; bài không đánh giá chúng và không khẳng định hơn kém.
Ba câu hỏi giúp chọn: ứng dụng đang dùng giao thức nào, có chấp nhận phụ thuộc nhà cung cấp dịch vụ quản lý không, và đội có người trực sự cố hệ phân tán không. Nếu câu cuối chưa có lời đáp, dịch vụ quản lý có thể hợp lý hơn tự vận hành, đổi lại là phụ thuộc nhà cung cấp. [1]
Hạn chế: phức tạp của hệ phân tán và mức độ chưa kiểm chứng
Hạn chế đầu tiên là độ phức tạp vận hành. Từ chỉ mục kiến trúc đến tài liệu DDL, ta thấy nhiều lớp phối hợp: nút chủ, phiên bản lược đồ toàn cục, worker và khung tác vụ phân tán. [3][7][8][10]
Hạn chế thứ hai là DDL. Cơ chế an toàn bằng nhiều bước và chờ đồng bộ phiên bản có nghĩa là một thay đổi lược đồ lớn có thể kéo dài và cần lên lịch có chủ đích. [7][8]
Hạn chế thứ ba là phạm vi bằng chứng. Phần lớn nội dung đọc được là tài liệu dành cho người phát triển và các tác tử lập trình, nên phản ánh cấu trúc mã chứ không phải trải nghiệm người dùng. Tài liệu hướng dẫn vận hành, hiệu năng và tương thích chi tiết nằm ngoài kho đã đọc. Tuyên bố tương thích MySQL 8.0 cần được kiểm tra bằng bộ kiểm thử của riêng bạn. [1]
Không nên dùng TiDB khi dữ liệu và tải còn nhỏ, khi ứng dụng phụ thuộc vào tính năng MySQL đặc thù chưa được kiểm tra, khi không có kế hoạch sao lưu phục hồi đã diễn tập, hoặc khi chỉ muốn thử công nghệ mới mà không có mục tiêu đo được.
Kế hoạch thử nghiệm mười hai tuần cho miền dữ liệu bình luận
Tuần một đến ba: chuẩn bị. Xác định miền dữ liệu thử, liệt kê mọi câu SQL, giao dịch và tính năng MySQL mà ứng dụng bình luận dùng, đặt các ngưỡng thành công bằng số do chính nhóm quyết định trước khi chạy, ví dụ độ trễ phân vị 95 và tỷ lệ lỗi chấp nhận được.
Tuần bốn đến sáu: dựng cụm thử bằng cụm cục bộ hoặc Kubernetes theo hướng dẫn chính thức, nạp dữ liệu đã ẩn danh, chạy bộ kiểm thử tương thích với toàn bộ câu lệnh đã liệt kê. [1] Tiêu chí: mọi khác biệt hành vi được ghi lại và không còn khác biệt nào làm sai kết quả nghiệp vụ.
Tuần bảy đến chín: mô phỏng tải đột biến theo hình dạng lưu lượng một ngày tin nóng, thử tắt một nút, thử chuyển nút chủ DDL và chạy một DDL trong lúc có tải. [7][8] Tiêu chí: ứng dụng phục hồi mà không mất dữ liệu đã xác nhận, và thời gian DDL nằm trong ngưỡng đã đặt.
Tuần mười đến mười hai: chạy bóng song song với hệ thống thật, chỉ đọc, so sánh kết quả từng truy vấn. Nếu muốn thử bảng điều khiển phân tích thì bật TiFlash và so sánh với truy vấn hiện có. [1] Điều kiện thoát: dừng nếu khác biệt kết quả không giải thích được, nếu chi phí vận hành vượt ngân sách nhân sự, hoặc nếu ngưỡng đặt ra ở tuần ba không đạt sau hai vòng tinh chỉnh.
Kết luận
TiDB là một cơ sở dữ liệu SQL phân tán đáng cân nhắc cho những hệ thống đã vượt quá khả năng của MySQL đơn nút, với giấy phép Apache 2.0 rõ ràng và một quy trình DDL được thiết kế để an toàn khi nhiều nút cùng chạy. [1][2][7]
Cái giá là độ phức tạp vận hành và nhu cầu kiểm chứng tương thích. Tòa soạn trong kịch bản nên đi từng miền dữ liệu, đặt ngưỡng đo được từ đầu và chỉ mở rộng khi tiêu chí thoát được thỏa mãn.
Nguồn và phương pháp
Đây là nghiên cứu bàn giấy (desk research), không phải công trình khoa học đã qua phản biện. Tác giả không cài đặt, chạy, đo hiệu năng hay triển khai TiDB; mọi nhận định dựa trên văn bản trong kho tại commit 21e9dc3c9d2c48a08bb267928574c5732a76de23, kiểm tra ngày 2026-10-12.
Dự án được chọn từ kho lưu trữ GitHub Trending: pingcap/tidb xuất hiện 16 lần từ 2026-01-01 đến 2026-09-29; lần đầu ở danh sách Go, vị trí 7. [11] Kho lưu trữ này chỉ phủ danh sách Python, Go, JavaScript và Swift, thiếu hai ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng top 100 chính thức.
Các tệp đã đọc gồm README, LICENSE, chỉ mục kiến trúc, SECURITY.md gốc và của br [1][2][3][4][5], cùng năm tài liệu bổ sung: roadmap.md, hai tài liệu về luồng và vòng đời DDL, LICENSE.md của br và ghi chú về khung thực thi phân tán DXF [6][7][8][9][10]. Bản phát hành được ghi lại lúc thu thập là v7.5.8 (2026-09-17).
Nội dung kho được coi là dữ liệu tham khảo, không phải chỉ dẫn. Các điểm chưa xác minh được nêu trong từng mục.