Skip to main content

Tổng Quan Về Cơ Sở Dữ Liệu (Database)

Cập nhật: 2026-07-09

Mục lục​

1. Cơ sở dữ liệu là gì?​

Cụm từ "cơ sở dữ liệu" nghe hơi to tát nhưng bản chất của nó đơn giản. Hãy hình dung một cửa hàng ngày xưa ghi sổ khách bằng cách nhét từng tờ giấy vào một cái hộp — hôm nay một tờ, mai một tờ, cứ thế chất chồng lên nhau chẳng theo thứ tự gì cả. Đến lúc cần tìm thông tin một khách cụ thể, phải lục tung cả cái hộp lên, lật từng tờ một, mất cả buổi mới ra.

Giờ đổi cách làm: vẫn đống giấy đó nhưng chia vào từng ngăn kéo riêng — ngăn này để tên khách, ngăn kia để đơn hàng, mỗi ngăn dán nhãn rõ ràng. Chỉ cần biết mình tìm cái gì, kéo đúng ngăn ra là thấy ngay, không phải lục lọi gì nữa.

💡 Hình dung: Cái tủ có ngăn kéo dán nhãn đàng hoàng đó chính là hình dung gần nhất về một cơ sở dữ liệu.

Còn phần đứng ra sắp xếp, cất giữ rồi lấy đúng thứ mình cần mỗi khi hỏi tới, người ta gọi là hệ quản trị cơ sở dữ liệu, hay quen gọi tắt là DBMS (Database Management System). Nói cách khác, dữ liệu là đống giấy tờ, còn hệ quản trị chính là người đứng quản cái kho đó — biết rõ thứ gì nằm ở ngăn nào, lấy ra lúc nào cũng đúng, cũng nhanh.

2. Lịch sử ra đời của mô hình quan hệ và SQL​

Những năm 1960, máy tính đã có rồi, nhưng cách lưu dữ liệu thì khá vất vả. Muốn lấy một thông tin, người viết chương trình phải biết chính xác nó nằm ở đâu, đi qua đường nào — giống như phải thuộc lòng cả một cái bản đồ chằng chịt mới lần ra được.

Đến năm 1970, Edgar Codd, đang làm ở IBM, công bố một cách nghĩ khác hẳn: cứ xếp dữ liệu vào những cái bảng hàng với cột, không cần nhớ đường đi, chỉ cần biết mối quan hệ giữa các bảng với nhau. Ý tưởng đó nghe hay nhưng lúc đó vẫn chỉ nằm trên giấy — thậm chí chính IBM ban đầu còn ngó lơ, vì áp dụng mô hình mới đồng nghĩa cạnh tranh với IMS/DB, dòng cơ sở dữ liệu phân cấp đang mang lại doanh thu chính của hãng lúc đó.

Vài năm sau, một nhóm kỹ sư khác trong chính IBM bắt tay biến nó thành thứ chạy được thật. Trong lúc làm, họ nghĩ ra một ngôn ngữ để hỏi dữ liệu, sau này viết gọn lại thành ba chữ cái: SQL.

Tuy nhiên, người mang nó ra thị trường trước tiên lại không phải IBM mà là một công ty nhỏ sau đổi tên thành Oracle, tung ra sản phẩm thương mại đầu tiên chạy được SQL vào năm 1979. Bảy năm sau đó (1986), SQL được công nhận thành một chuẩn chung để dù dùng phần mềm của hãng nào, câu lệnh cũng chạy theo cùng một quy tắc.

Rồi đến năm 1995, một hệ quản trị mã nguồn mở tên MySQL xuất hiện — ai cũng dùng được miễn phí, và từ đó SQL không còn là sân chơi riêng của mấy công ty lớn nữa.

💡 Hình dung: Trước khi có chuẩn chung, mỗi hãng cơ sở dữ liệu nói một "phương ngữ" SQL hơi khác nhau. Việc chuẩn hóa năm 1986 giống như cả nước đồng ý dùng chung một ngôn ngữ phổ thông — ai học một lần là dùng được ở khắp nơi, không phải học lại mỗi khi đổi hãng.

3. Mô hình dữ liệu quan hệ và truy vấn bằng SQL​

Quay lại ý tưởng của Codd: xếp dữ liệu vào bảng hàng với cột. Lấy ví dụ một bảng lưu thông tin khách hàng — mỗi hàng là một khách, mỗi cột là một loại thông tin (tên, số điện thoại, địa chỉ...).

Trong bảng đó luôn có một cột đặc biệt, giá trị của nó không bao giờ trùng nhau giữa hai hàng — gọi là khóa chính (primary key). Khóa chính giống như số căn cước của mỗi hàng, chỉ cần nhìn vào nó là biết ngay đang nói đến khách nào, không nhầm lẫn được.

Giờ có thêm một bảng khác lưu đơn hàng. Mỗi đơn hàng đương nhiên phải thuộc về một khách nào đó. Cách làm là bảng đơn hàng sẽ có thêm một cột chứa đúng khóa chính của bảng khách hàng — cột này gọi là khóa ngoại (foreign key). Nhờ cột đó, hai bảng vốn tách rời nhau bỗng nối lại được với nhau: cứ nhìn vào khóa ngoại là biết đơn hàng này của ai.

💡 Hình dung: Khóa ngoại giống như việc ghi đúng số căn cước của khách lên tờ hóa đơn, thay vì chép lại toàn bộ tên tuổi, địa chỉ của họ vào từng hóa đơn một. Chỉ cần nhìn số đó là tra ngược lại đúng người, dữ liệu khách không bị lặp lại ở hàng nghìn hóa đơn khác nhau.

Cả một hệ thống dữ liệu lớn thật ra cũng chỉ là hàng trăm, hàng nghìn cái bảng nối với nhau kiểu này, không hơn không kém.

Có bảng, có khóa nối rồi, nhưng làm sao để thực sự lấy được thông tin ra? Đây là lúc SQL xuất hiện. SQL không phải một ngôn ngữ để viết ra cả một ứng dụng, nó chỉ dùng để hỏi dữ liệu thôi. Điều hay là chỉ cần nói muốn cái gì chứ không cần chỉ ra từng bước phải làm như thế nào.

Ví dụ muốn lấy tên và số điện thoại của khách hàng nhưng chỉ những ai có địa chỉ ở Hà Nội:

SELECT ten, so_dien_thoai
FROM khach_hang
WHERE dia_chi = 'Ha Noi';
  • SELECT — chọn cột nào
  • FROM — lấy từ bảng nào
  • WHERE — lọc theo điều kiện gì; dòng nào khớp điều kiện thì được giữ lại, còn lại bỏ qua hết

Có lúc thông tin cần lại nằm ở hai bảng khác nhau, giống bảng khách hàng với bảng đơn hàng lúc nãy. Lúc đó dùng đến JOIN — ghép hai bảng lại dựa trên đúng cái khóa ngoại đã nối sẵn, để ra một kết quả duy nhất vừa có tên khách vừa có luôn đơn hàng của người đó. Cả một câu hỏi phức tạp xuyên qua nhiều bảng, gói gọn lại chỉ trong vài dòng lệnh như vậy.

Đây cũng là lý do SQL tồn tại gần 50 năm rồi mà vẫn chưa có gì thay thế được nó hết.

Primary Key & Foreign Keycustomersid (PK)namephoneaddressbalanceordersid (PK)customer_id (FK)productcreated_atcustomer_id (FK) in orders points to id (PK) in customers

4. Đảm bảo tính đúng đắn (ACID) và tốc độ (Index) trong SQL​

Nguyên tắc ACID​

Thêm một cột số dư tài khoản vào bảng khách hàng để lấy ví dụ: chị Lan muốn chuyển 500.000đ cho anh Minh. Nhìn thì đơn giản nhưng bên trong hệ thống phải làm đúng hai việc — trừ tiền bên chị Lan, cộng tiền bên anh Minh. Vấn đề là nếu trừ xong bên chị Lan mà đúng lúc đó mất điện hoặc phần mềm treo, chưa kịp cộng cho anh Minh thì sao? Tiền vừa biến mất khỏi hệ thống.

Đây chính là lý do người ta đặt ra một nhóm nguyên tắc cho mọi giao dịch, gọi tắt là ACID:

  • Atomicity (tính nguyên tử): hai việc trừ với cộng phải đi cùng nhau — làm được cả hai thì mới tính, còn không thì hủy hết, quay lại y như chưa từng làm gì.
  • Consistency (tính nhất quán): sau giao dịch, dữ liệu vẫn phải hợp lý (ví dụ số dư không được phép âm).
  • Isolation (tính cô lập): nếu đúng lúc đó có người khác đang xem số dư của chị Lan, họ sẽ không thấy cái trạng thái lửng lơ mới trừ mà chưa cộng — chỉ thấy trước hoặc sau, không có ở giữa.
  • Durability (tính bền vững): một khi hệ thống đã báo giao dịch thành công thì dù có tắt máy ngay sau đó, số dư mới vẫn còn nguyên, không mất đi đâu cả.

Index và cây B​

Bảng khách hàng lúc nãy chỉ có vài dòng nên nhìn phát ra ngay. Nhưng nếu bảng đó phình lên vài triệu dòng thì sao? Cách ảo nhất là dò từ dòng đầu tiên xem có khớp không, không khớp thì qua dòng kế, cứ thế đến khi gặp đúng thì dừng. Tệ nhất là khách cần tìm lại nằm ở dòng cuối cùng, coi như phải quét qua hết cả triệu dòng. Cách này gọi là quét toàn bảng (full table scan), và với dữ liệu lớn nó chậm đến mức không ai chấp nhận nổi.

Giải pháp là dựng thêm một cấu trúc phụ bên cạnh bảng gọi là chỉ mục (index), phổ biến nhất là một dạng cây gọi là cây B (B-tree). Thay vì dò từng dòng, giờ chỉ cần đứng ở gốc cây so sánh một lần, biết ngay phải rẽ sang bên nào; xuống một tầng lại so sánh, lại rẽ. Cứ thế, bảng triệu dòng nhưng cây chỉ cần đi qua vài tầng là chạm tới đúng dòng cần tìm, không phải sờ vào phần còn lại.

💡 Hình dung: Khác biệt giữa quét toàn bảng với dùng cây B đúng là khác biệt giữa việc phải đọc hết một cuốn sách để tìm một câu, với việc lật thẳng đến đúng trang nhờ mục lục.

Full Table Scan vs B-Tree IndexFull Table Scan (slow)row 1row 2row 3...match!check every rowO(N) comparisonsB-Tree Index (fast)5020706572 ✓O(log N) comparisons

5. Bài toán mở rộng quy mô và sự ra đời của NoSQL​

Cây B giải quyết được bài toán tìm nhanh trên một cái máy, nhưng đến giữa những năm 2000, có mấy công ty gặp phải một bài toán khác hẳn — dữ liệu không còn vừa một cái máy nữa. Google phải lưu và tìm kiếm gần như toàn bộ trang web; Amazon phải phục vụ hàng chục triệu người mua sắm cùng lúc, không được phép đứng sập dù chỉ một giây.

Cách cũ để chịu tải nhiều hơn là nâng cấp một cái máy — thêm máy mạnh, thêm bộ nhớ — gọi là Scale Up. Nhưng nâng đến một mức, dù có tiền cũng không mua nổi cái máy nào mạnh hơn nữa. Thế là thay vì dồn vào một máy, họ chia dữ liệu ra hàng nghìn máy nhỏ chạy song song, gọi là Scale Out.

💡 Hình dung: Giống một quán ăn đang quá tải khách. Scale Up là thuê đầu bếp giỏi hơn, mua bếp to hơn cho đúng một quán đó — làm được đến một mức thì hết chỗ nâng cấp. Scale Out là mở thêm nhiều chi nhánh nhỏ chạy song song, khách đông bao nhiêu cũng chỉ cần mở thêm chi nhánh mới.

Năm 2006, Google công bố cách họ làm hệ thống lưu trữ tên BigTable, chạy trên hàng nghìn máy như vậy. Một năm sau (2007), Amazon cũng công bố hệ thống của riêng họ tên Dynamo, ưu tiên việc lúc nào cũng phải trả lời được hơn là lúc nào cũng phải chính xác tuyệt đối. Hai bài viết đó truyền cảm hứng cho hàng loạt công cụ lưu trữ mới ra đời sau đó, tất cả đều đi theo hướng chia nhỏ, chạy song song, khác hẳn kiểu một bảng - một máy như trước giờ.

Đến năm 2009, một kỹ sư tên Johan Oskarsson đứng ra tổ chức một buổi gặp mặt bàn về mấy công cụ này ở San Francisco, và cần một cái tên ngắn để làm hashtag. Người gợi ý đúng ba chữ NoSQL — vốn là một cái tên cũ từng dùng cho một dự án khác hồi cuối những năm 1990 — là kỹ sư Eric Evans, trả lời trên kênh IRC #cassandra. Từ đó, cái tên này gắn luôn với cả một hướng đi mới của ngành lưu trữ dữ liệu.

Scale Up vs Scale OutScale Upserverbigger servermore CPU / RAMOne machine gets biggerScale Outnode 1node 2node 3node 4Many machines run in parallel

6. Định lý CAP và hai triết lý ACID vs BASE​

Định lý CAP​

Làm sao một hệ thống chạy trên nhiều máy, dù vài nốt trong cụm rớt mạng, vẫn trả lời được? Điều này liên quan đến một quy luật gọi là định lý CAP. Năm 2000, Eric Brewer đưa ra ý này: với một hệ thống dữ liệu chạy trên nhiều máy, chỉ có thể đảm bảo tối đa hai trong ba thứ cùng lúc, chứ không thể có đủ cả ba:

  • Consistency: mọi máy luôn thấy cùng một dữ liệu giống hệt nhau.
  • Availability: hệ thống luôn trả lời được yêu cầu.
  • Partition tolerance: hệ thống vẫn sống dù mất kết nối giữa các máy.

Chuyện chọn lựa chỉ xảy ra đúng một thời điểm: lúc mạng giữa các máy bị đứt. Bình thường không đứt mạng thì mấy máy vẫn đồng bộ dữ liệu tốt, vừa nhất quán vừa trả lời được, chẳng phải đánh đổi gì cả. Nhưng đúng lúc đứt mạng, hai cụm máy không nói chuyện được với nhau nữa, hệ thống buộc phải chọn: hoặc ngưng trả lời để chắc chắn dữ liệu không bị sai lệch, hoặc vẫn trả lời nhưng chấp nhận dữ liệu hai bên có thể tạm thời khác nhau. Không có lựa chọn nào đúng tuyệt đối, tùy vào việc hệ thống đó đang phục vụ cái gì.

Lúc Brewer nêu ý này tại một hội nghị năm 2000, nó mới chỉ là một giả thuyết. Đến năm 2002, hai nhà nghiên cứu Seth Gilbert và Nancy Lynch ở MIT mới chứng minh được nó bằng toán học chặt chẽ, biến CAP từ một quan sát thực tế thành một định lý đúng nghĩa.

💡 Hình dung: Giống ba lời hứa của một chuỗi cửa hàng có nhiều chi nhánh: lúc nào cũng trả lời khách (Availability), chi nhánh nào cũng cho thông tin giống hệt nhau (Consistency), và vẫn hoạt động được dù đường dây liên lạc giữa các chi nhánh bị đứt (Partition tolerance). Bình thường giữ được cả ba, nhưng đúng lúc đứt dây thật, chỉ giữ nổi tối đa hai trong ba lời hứa đó.

CAP Theorem: Pick 2 of 3ConsistencyAvailabilityPartition ToleranceOnly 2 of 3 can be keptduring a network partition

ACID vs BASE​

Hai cách phản ứng lúc mất kết nối đại diện cho hai trường phái khác hẳn nhau trong thiết kế hệ dữ liệu:

  • Bên chọn dừng lại để giữ đúng dữ liệu đi theo triết lý ACID (ưu tiên số một là không bao giờ được sai) — như phần giao dịch ngân hàng đã nói ở trên.
  • Bên chọn vẫn trả lời, chấp nhận lệch tạm thời, đi theo triết lý BASE. Cái tên này ra đời năm 2008, do kỹ sư Dan Pritchett ở eBay đặt ra trong bài viết "BASE: An ACID Alternative", chơi chữ đối lập hẳn với ACID. BASE gồm ba ý:
    • Basically Available: luôn cơ bản trả lời được, dù dữ liệu trả về chưa chắc mới nhất.
    • Soft state: trạng thái có thể tự đổi theo thời gian, ngay cả khi không có ai vừa thao tác gì.
    • Eventually consistent: dữ liệu sẽ đồng bộ lại, chỉ là không phải ngay lập tức mà sau một khoảng thời gian ngắn.

Ngân hàng chuyển tiền thì chắc chắn cần ACID, nhưng nếu một lượt thích trên mạng xã hội thì chậm đồng bộ vài giây cũng chẳng ai để ý. Vấn đề chỉ là chọn đúng triết lý cho đúng việc, không có công thức chung cho tất cả.

7. Bốn nhóm cơ sở dữ liệu NoSQL​

7.1 Key-Value​

Nhóm đơn giản nhất, cũng là nền tảng cho gần như mọi thứ còn lại. Mỗi mẩu dữ liệu chỉ có một cái khóa duy nhất, đưa khóa vào là lấy ra đúng giá trị tương ứng — không cần biết bên trong giá trị đó chứa gì, không có bảng, không có cột, không cần khai báo cấu trúc trước.

💡 Hình dung: Cứ hình dung nó như một cái tủ khóa khổng lồ, biết đúng số khóa là mở được đúng ngăn ngay lập tức, không cần dò qua ngăn nào khác.

Đại diện quen thuộc nhất là Redis, ra đời năm 2009 khi một lập trình viên người Ý cần một chỗ lưu cực nhanh để phân tích lượt truy cập web theo thời gian thực (MySQL lúc đó không kham nổi tốc độ đó). Redis giữ toàn bộ dữ liệu trong bộ nhớ RAM chứ không phải ổ đĩa, tốc độ đọc ghi gần như tức thời, cực hợp để làm bộ nhớ đệm hay lưu phiên đăng nhập. Amazon cũng có phiên bản dịch vụ riêng theo hướng này gọi là DynamoDB, ra mắt năm 2012, dựa trên chính ý tưởng từ bài báo Dynamo nội bộ của họ hồi 2007.

SET user:1001 "Nguyen Van A"
GET user:1001

Chỉ hai lệnh: SET ghi giá trị vào đúng khóa user:1001, GET đưa khóa vào là lấy ra ngay giá trị tương ứng — không có khái niệm bảng, không có JOIN.

7.2 Document​

Cũng lưu dữ liệu theo từng bản ghi nhưng khác bảng SQL ở một điểm quan trọng: bảng SQL bắt buộc mọi hàng có đủ y hệt các cột, thiếu cột nào cũng phải để trống. Document thì không bắt như vậy — mỗi bản ghi giờ là một khối dữ liệu tự thân viết theo kiểu JSON, muốn thêm trường nào, lồng bao nhiêu tầng bên trong cũng được. Bản ghi này có trường A, bản ghi kia không có cũng chẳng sao.

💡 Hình dung: Giống một tủ hồ sơ khách hàng, mỗi bộ hồ sơ dày mỏng khác nhau tùy người — có người chỉ vài trang, có người kèm theo cả xấp giấy tờ phụ lục. Không ai bắt hồ sơ nào cũng phải đúng số trang như nhau.

Đại diện tiêu biểu nhất là MongoDB. Nó xuất phát từ một công ty tên 10gen, thành lập năm 2007 bởi mấy kỹ sư từng làm ở DoubleClick. Ban đầu họ định làm hẳn một nền tảng đám mây nhưng cái cơ sở dữ liệu họ dựng kèm theo lại được đón nhận hơn hẳn, nên đến năm 2009 họ tách riêng nó ra làm mã nguồn mở, đặt tên MongoDB — ghép từ chữ humongous nghĩa là khổng lồ.

Bên trong MongoDB lưu dữ liệu ở một dạng gọi là BSON, về cơ bản vẫn là JSON, chỉ là được mã hóa lại thành dạng nhị phân để đọc ghi nhanh hơn. Cái linh hoạt này cực kỳ hợp khi dữ liệu hay đổi hình dạng, ví dụ thông tin sản phẩm, mỗi loại lại có một mớ thuộc tính khác hẳn nhau. Đổi lại, việc giữ cho các bản ghi luôn đúng chuẩn thì phải tự lo liệu nhiều hơn.

db.products.insertOne({ name: "Ao thun", price: 150000, sizes: ["S", "M", "L"] })
db.products.find({ price: { $lt: 200000 } })

Không cần khai báo trước bảng products có những cột nào — cứ insertOne một document JSON là xong, kể cả khi document tiếp theo có thêm trường mà document trước không có.

7.3 Column Family​

Gần giống bảng SQL ở chỗ vẫn có hàng có cột, nhưng số cột trong mỗi hàng lại có thể khác nhau và mở rộng gần như không giới hạn — hàng này có thể có ba cột, hàng kia có 300 cột, tùy dữ liệu thực tế cần lưu, không cần khai báo trước hết tất cả.

💡 Hình dung: Giống một cuốn sổ tay ghi chép mở, mỗi trang (mỗi hàng) muốn ghi bao nhiêu mục cũng được — trang này ghi ba dòng, trang kia ghi ba trăm dòng — không cần kẻ sẵn số cột cố định áp dụng cho mọi trang như một biểu mẫu in sẵn.

Đại diện tiêu biểu nhất là Apache Cassandra. Nó ra đời tại Facebook, xây bởi Avinash Lakshman (chính người từng viết bài Dynamo cho Amazon lúc trước) cùng với Prashant Malik, để phục vụ tính năng tìm kiếm hộp thư của Facebook. Công bố mã nguồn mở tháng 7 năm 2008, rồi đưa vào Apache Software Foundation làm Incubator project từ tháng 3 năm 2009; đến tháng 2 năm 2010 thì Cassandra chính thức tốt nghiệp, trở thành một dự án cấp cao (top-level project) của tổ chức này.

Cassandra thừa hưởng cách tổ chức dữ liệu theo cột từ BigTable của Google, nhưng lại dùng kiến trúc phân tán kiểu Dynamo của Amazon — xếp các máy thành một vòng tròn, không có máy nào là trung tâm cả. Mọi máy trong vòng đều ngang hàng nhau; ghi dữ liệu vào một máy, nó tự lan sang mấy máy lân cận trên vòng để nhân bản. Kể cả khi vài máy trong vòng gặp sự cố, cả hệ thống vẫn không hề hấn gì vì dữ liệu vẫn nằm ở những bản sao khác.

CREATE TABLE messages (
  user_id text,
  sent_at timestamp,
  content text,
  PRIMARY KEY (user_id, sent_at)
);
SELECT * FROM messages WHERE user_id = 'alice';

Cú pháp CQL (Cassandra Query Language) cố tình viết giống SQL cho dễ làm quen, nhưng PRIMARY KEY ở đây còn quyết định luôn dữ liệu được rải sang máy nào trong vòng tròn — khác hẳn khóa chính SQL vốn chỉ để định danh hàng.

Cái tên Cassandra lấy từ một nhà tiên tri trong thần thoại Hy Lạp — người luôn nói đúng nhưng chẳng ai chịu tin cả.

7.4 Graph​

Nhóm nhìn thẳng vào chính cái mà SQL hay gặp khó: mối quan hệ nhiều tầng giữa các thực thể.

💡 Hình dung: Giống một tấm sơ đồ quan hệ dán trên tường, mỗi người là một điểm, mỗi đường nối là một mối quan hệ. Muốn biết ai quen ai qua bao nhiêu bước, chỉ cần lần theo đường nối trên sơ đồ, không cần ghép nối nhiều bảng lại với nhau như SQL.

Ý tưởng bắt đầu từ năm 2000, khi Emil Eifrem đang ngồi trên máy bay gặp bế tắc với chính hệ thống mình đang xây, vì cứ join hết bảng này sang bảng khác mà vẫn không diễn tả nổi các mối quan hệ chồng chéo. Ông vẽ ra trên một tờ giấy ăn một cách nhìn khác hẳn — không phải bảng mà là các nút nối với nhau. Nút gọi là node, đại diện cho một thực thể; đường nối giữa hai node gọi là relationship, đại diện cho mối quan hệ, và bản thân đường nối đó cũng có thể mang thêm thông tin riêng.

Năm 2007, ý tưởng đó chính thức trở thành một công ty ở Thụy Điển, ra đời cơ sở dữ liệu đồ thị nổi tiếng nhất hiện nay: Neo4j. Neo4j có hẳn một ngôn ngữ truy vấn riêng gọi là Cypher, do kỹ sư Andrés Taylor thiết kế và được mở mã nguồn năm 2015, cho phép hỏi thẳng theo kiểu quan hệ — kiểu như "tìm bạn của bạn của người này" — mà không cần join qua join lại như SQL, vì dữ liệu vốn đã được lưu sẵn dưới dạng các đường nối. Ảnh hưởng của Cypher lớn đến mức năm 2023, tổ chức ISO công bố hẳn một chuẩn quốc tế cho ngôn ngữ truy vấn đồ thị (GQL) lấy chính Cypher làm nền tảng chính.

MATCH (a:Person {name: "Alice"})-[:FRIEND]->(b)-[:FRIEND]->(c)
RETURN DISTINCT c.name

Câu lệnh trên đọc gần như tiếng Anh thường: tìm các node Person tên Alice, đi theo cạnh FRIEND hai bước, trả về tên những người ở bước thứ hai — chính là "bạn của bạn" mà SQL phải join bảng nhiều lần mới ra được.

Đây cũng là lý do nhóm đồ thị rất hợp với các bài toán như tìm bạn chung trên mạng xã hội, gợi ý sản phẩm dựa trên hành vi tương tự, hay phát hiện một nhóm giao dịch bất thường có liên kết vòng vo với nhau. Tất cả những bài toán đó đều xoay quanh một câu hỏi chung: từ đây đi qua bao nhiêu bước thì tới được đó.

Four NoSQL Data ModelsKey-Valuekey→valueDocument{ name: ... price: ... sizes: [...] }Column FamilyGraph

8. Hướng đi mới: NewSQL và Vector Database​

Ranh giới giữa các nhóm không phải lúc nào cũng rạch ròi. Có hai hướng đi gần đây không nằm gọn trong khung SQL hay NoSQL cũ mà đứng ở giữa hoặc vượt hẳn ra ngoài.

NewSQL​

Thuật ngữ này được nhà phân tích Matthew Aslett đặt ra năm 2011. Ý tưởng là vừa giữ được SQL, giữ được ACID đầy đủ, vừa scale ra nhiều máy như NoSQL — không phải đánh đổi bên nào.

💡 Hình dung: Giống một chuỗi cửa hàng nhượng quyền chuẩn hóa — mỗi chi nhánh (máy chủ) vận hành độc lập nhưng theo đúng một quy chuẩn duy nhất, khách ghé chi nhánh nào cũng nhận được đúng một trải nghiệm, không lệch pha giữa nơi này với nơi khác.

Đại diện đầu tiên là Spanner, hệ thống nội bộ mà Google công bố năm 2012, đồng bộ đồng hồ giữa hàng nghìn máy chủ khắp thế giới để đảm bảo mọi nơi đều thấy cùng một dữ liệu cùng một lúc. Sau đó, năm 2015, ba kỹ sư từng làm ở Google — Spencer Kimball, Peter Mattis và Ben Darnell, những người từng trực tiếp dùng BigTable và Spanner nội bộ — lấy chính ý tưởng đó làm ra một phiên bản mã nguồn mở đặt tên CockroachDB, ai cũng dùng được, không cần làm việc ở Google.

Vector Database​

Gắn liền với làn sóng AI mấy năm gần đây. Mọi văn bản, hình ảnh đều có thể được chuyển thành một dãy số nhiều chiều gọi là vector, sao cho những thứ có ý nghĩa gần nhau thì dãy số cũng nằm gần nhau. Nhờ vậy, thay vì tìm đúng từng chữ, hệ thống có thể tìm những thứ na ná về mặt ý nghĩa. Đây chính là nền tảng cho cách các mô hình AI hiện nay tra cứu thêm thông tin trước khi trả lời.

💡 Hình dung: Giống một thư viện xếp sách theo chủ đề thay vì theo số thứ tự bảng chữ cái. Hỏi "cuốn nào giống cuốn này" là tìm được ngay những cuốn nằm gần nhau về chủ đề, dù tên sách chẳng trùng chữ nào với nhau.

Điều thú vị nhất tính đến thời điểm này là vector không còn cần một cơ sở dữ liệu riêng biệt nữa — những cái tên quen thuộc như PostgreSQL giờ chỉ cần gắn thêm phần mở rộng pgvector là đã tìm kiếm được theo kiểu đó ngay trong chính cơ sở dữ liệu cũ. Dĩ nhiên ở quy mô cực lớn, một cơ sở dữ liệu vector riêng như Pinecone vẫn có chỗ đứng — dù khoảng cách đang thu hẹp dần: đến tháng 3 năm 2026, phần mở rộng pgvectorscale giúp PostgreSQL đạt hiệu năng cạnh tranh ngang Pinecone ngay cả ở quy mô hàng chục triệu vector, điều gần như không tưởng vài năm trước. Xu hướng chung là ranh giới giữa các loại cơ sở dữ liệu đang mờ dần đi, chứ không còn tách bạch như trước.

9. Nên chọn cơ sở dữ liệu nào?​

Câu trả lời không có một đáp số chung cho tất cả, nhưng có một cách hỏi giúp đi đúng hướng khá nhanh.

💡 Hình dung: Giống việc đi khám bệnh — bác sĩ giỏi không kê ngay một loại thuốc cho mọi triệu chứng, mà hỏi lần lượt từng câu để thu hẹp dần chẩn đoán. Chọn cơ sở dữ liệu cũng vậy: trả lời đúng vài câu hỏi mấu chốt là thu hẹp được ngay xuống một vài lựa chọn hợp lý.

  1. Dữ liệu có cấu trúc rõ ràng, cố định không? Có cần join nhiều bảng hay giao dịch phải chính xác tuyệt đối (kiểu ngân hàng) không? → Nếu có, đi thẳng về phía SQL.
  2. Quy mô lớn đến mức một máy không kham nổi mà vẫn cần giữ nguyên SQL với ACID? → Đi về phía NewSQL.
  3. Nếu dữ liệu hay đổi hình dạng, không cố định trước được:
    • Chỉ cần tra cứu cực nhanh theo một khóa duy nhất → Key-Value.
    • Là một khối tài liệu lồng nhau → Document.
    • Cần ghi liên tục với khối lượng khổng lồ trên hàng nghìn máy → Column Family.
    • Câu hỏi chính xoay quanh việc ai quen ai, cái gì liên quan tới cái gì qua nhiều bước → Graph.
    • Cần tìm những thứ giống nhau về mặt ý nghĩa, phục vụ AI → Vector Database.

Một hệ thống thật ngoài đời gần như chẳng bao giờ chỉ dùng một cơ sở dữ liệu — người ta ghép SQL để giữ đơn hàng cho chắc chắn, key-value để cache cho nhanh, document cho dữ liệu thay đổi hình dạng, graph cho phần quan hệ, vector cho phần tìm theo ý nghĩa, mỗi loại lo đúng phần việc nó mạnh nhất. Cách làm đó có tên riêng gọi là Polyglot Persistence. Thuật ngữ này xuất hiện từ khoảng năm 2008, rồi được nhắc tới nhiều hơn qua các bài viết của Martin Fowler sau đó.

Điều khá thú vị là tính đến nay, ranh giới giữa các nhóm đang mờ dần thật: chuẩn SQL mới nhất đã cho phép truy vấn kiểu đồ thị ngay trong chính SQL, còn phần tìm kiếm theo vector giờ lại chui thẳng vào trong những cơ sở dữ liệu quan hệ quen thuộc. Nói cách khác, câu hỏi không còn là SQL hay NoSQL nữa, mà là bài toán trước mắt cần gì rồi chọn đúng công cụ cho đúng việc đó.

Which Database Should I Choose?Fixed schema, needmulti-table ACID?yesSQLnoScale beyond one machine,still need ACID?yesNewSQLnoWhat matters most?single-key lookupnested documentmassive writesmulti-hop linkssemantic searchKey-ValueDocumentColumnFamilyGraphVector DBReal systems usually combine several of these (Polyglot Persistence)

Nguồn tham khảo​

Nguồn gốc: Tổng Quan Về Cơ Sở Dữ Liệu | Database — kênh Học Giải Thuật Cùng HPN

Nguồn bổ sung (chi tiết research thêm ngoài transcript gốc, verify ngày 2026-07-09):