Michael Stonebraker và cơ sở dữ liệu hiện đại: Những gì ông đã thay đổi

Tại sao công việc của Stonebraker vẫn hiện diện trong stack dữ liệu của bạn

Michael Stonebraker là một nhà khoa học máy tính mà các dự án của ông không chỉ ảnh hưởng tới nghiên cứu cơ sở dữ liệu — chúng trực tiếp định hình sản phẩm và các mẫu thiết kế mà nhiều đội vận hành hàng ngày. Nếu bạn từng dùng cơ sở dữ liệu quan hệ, kho phân tích, hoặc hệ thống streaming, bạn đã hưởng lợi từ những ý tưởng mà ông đã giúp chứng minh, xây dựng, hoặc phổ biến.

Bạn sẽ nhận được gì từ bài viết này

Đây không phải tiểu sử hay tour lý thuyết học thuật về cơ sở dữ liệu. Thay vào đó, bài viết nối hệ thống chính của Stonebraker (như Ingres, Postgres và Vertica) với các lựa chọn bạn thấy trong các stack dữ liệu hiện đại:

• Tại sao SQL trở thành ngôn ngữ chung cho công việc dữ liệu
• Tại sao các engine phân tích trông và hành xử khác so với cơ sở dữ liệu OLTP
• Tại sao “một cơ sở dữ liệu cho mọi thứ” thường thất bại trong thực tế
• Cách các lựa chọn kiến trúc ảnh hưởng đến chi phí, hiệu năng và độ tin cậy

“Cơ sở dữ liệu hiện đại” nghĩa là gì (ngôn ngữ dễ hiểu)

Một cơ sở dữ liệu hiện đại là bất kỳ hệ thống nào có thể đáng tin cậy:

• Lưu dữ liệu an toàn (để bạn không mất nó)
• Truy vấn nhanh (để các đội trả lời câu hỏi)
• Mở rộng khi khối lượng và người dùng tăng (không bị sập)
• Giữ đúng dưới sự đồng thời (kết quả khớp với thực tế)

Các cơ sở dữ liệu khác nhau tối ưu những mục tiêu này theo cách khác nhau — đặc biệt khi so sánh ứng dụng giao dịch, dashboard BI và pipeline thời gian thực.

Lời hứa của bài viết này

Chúng ta sẽ tập trung vào tác động thực tiễn: những ý tưởng xuất hiện trong thế giới “warehouse + lake + stream + microservices” ngày nay, và cách chúng ảnh hưởng tới việc bạn mua, xây và vận hành. Mong đợi các giải thích rõ ràng, các trade-off và hệ quả trong thực tế — không phải đào sâu vào chứng minh hay chi tiết triển khai.

Dòng thời gian ngắn và hữu ích về các mốc chính của ông

Sự nghiệp của Stonebraker dễ hiểu nhất như một chuỗi hệ thống được xây cho các công việc cụ thể — rồi ta thấy các ý tưởng hay nhất lan vào sản phẩm thương mại.

Những năm 1970: Ingres — biến cơ sở dữ liệu quan hệ thành có thể dùng được

Ingres bắt đầu như một dự án học thuật chứng minh cơ sở dữ liệu quan hệ có thể nhanh và thực tế, chứ không chỉ là lý thuyết. Nó giúp phổ biến tư duy truy vấn kiểu SQL và tối ưu dựa trên chi phí mà sau này trở thành chuẩn trong các engine thương mại.

Những năm 1980–1990: Postgres — khả năng mở rộng và “để cơ sở dữ liệu tiến hóa”

Postgres (hệ thống nghiên cứu dẫn đến PostgreSQL) thử nghiệm một cược khác: cơ sở dữ liệu không nên là chức năng cố định. Bạn nên có thể thêm kiểu dữ liệu mới, phương pháp lập chỉ mục mới, và hành vi phong phú hơn mà không phải viết lại toàn bộ engine.

Nhiều tính năng “hiện đại” bắt nguồn từ thời kỳ này — kiểu dữ liệu mở rộng, hàm do người dùng định nghĩa, và một cơ sở dữ liệu có thể thích nghi khi workload thay đổi.

Những năm 2000: Lưu trữ theo cột và thiết kế ưu tiên phân tích

Khi phân tích tăng, hệ thống hướng hàng (row-oriented) gặp khó với các quét lớn và phép tổng hợp. Stonebraker thúc đẩy lưu trữ theo cột và các kỹ thuật thực thi liên quan nhằm chỉ đọc các cột cần thiết và nén chúng tốt — những ý tưởng nay trở thành tiêu chuẩn trong cơ sở dữ liệu phân tích và kho dữ liệu trên mây.

Giữa những năm 2000: Vertica — MPP cho phân tích như một sản phẩm

Vertica mang các ý tưởng nghiên cứu về cột vào một engine SQL massively parallel processing (MPP) thương mại, thiết kế cho các truy vấn phân tích lớn. Mô hình này lặp lại trong ngành: nguyên mẫu nghiên cứu xác nhận khái niệm; một sản phẩm ổn định hóa nó cho độ tin cậy, tooling và các ràng buộc khách hàng thực tế.

Những năm 2010 trở đi: streaming và “dụng cụ phù hợp cho workload”

Công việc sau này mở rộng sang xử lý luồng và các engine theo workload — tranh luận rằng một cơ sở dữ liệu tổng quát hiếm khi thắng ở mọi nơi.

Nguyên mẫu nghiên cứu so với sản phẩm (tại sao phân biệt quan trọng)

Nguyên mẫu xây để kiểm tra giả thuyết nhanh; sản phẩm phải ưu tiên vận hành: nâng cấp, giám sát, bảo mật, hiệu năng dự đoán và hỗ trợ. Ảnh hưởng của Stonebraker rõ vì nhiều ý tưởng nguyên mẫu đã được mang vào cơ sở dữ liệu thương mại như những tính năng mặc định thay vì lựa chọn ngách.

Ingres: Biến cơ sở dữ liệu quan hệ thành thực tế

Ingres (viết tắt của INteractive Graphics REtrieval System) là bằng chứng sớm của Stonebraker rằng mô hình quan hệ có thể hơn một lý thuyết thanh lịch. Khi đó, nhiều hệ thống được xây quanh các phương pháp truy cập tùy chỉnh và đường dẫn dữ liệu theo ứng dụng.

Ingres đặt ra một vấn đề đơn giản, thân thiện với doanh nghiệp:

Làm sao để cho phép người ta đặt câu hỏi linh hoạt với dữ liệu mà không phải viết lại phần mềm mỗi khi câu hỏi thay đổi?

Ingres cố gắng sửa gì

Cơ sở dữ liệu quan hệ hứa rằng bạn có thể mô tả cái gì bạn muốn (ví dụ: “khách hàng ở California có hóa đơn quá hạn”) thay vì làm thế nào để lấy nó từng bước. Nhưng để lời hứa đó trở thành hiện thực cần một hệ thống có thể:

• Lưu dữ liệu an toàn trong các bảng
• Chấp nhận ngôn ngữ truy vấn cấp cao gần giống SQL
• Biến truy vấn đó thành kế hoạch hiệu quả một cách tự động

Ingres là bước lớn hướng tới phiên bản “thực tế” của tính toán quan hệ — một hệ có thể chạy trên phần cứng thời đó và vẫn cảm thấy đáp ứng.

Việc chấp nhận SQL và sinh ra những khái niệm tối ưu truy vấn cơ bản

Ingres giúp phổ biến ý tưởng rằng cơ sở dữ liệu nên làm phần khó của việc lập kế hoạch truy vấn. Thay vì dev phải tinh chỉnh mọi đường dẫn truy cập dữ liệu, hệ thống có thể chọn chiến lược như đọc bảng nào trước, dùng index nào, và cách join các bảng.

Điều này giúp tư duy kiểu SQL lan rộng: khi bạn có thể viết truy vấn khai báo, bạn iterate nhanh hơn, và nhiều người hơn có thể đặt câu hỏi trực tiếp — analyst, đội sản phẩm, thậm chí bộ phận tài chính — mà không phải đợi báo cáo tùy chỉnh.

Tại sao tối ưu dựa trên chi phí quan trọng

Khái niệm thực tế lớn là tối ưu dựa trên chi phí: chọn kế hoạch truy vấn có “chi phí” kỳ vọng thấp nhất (thường là sự kết hợp I/O, CPU và bộ nhớ), dựa trên thống kê về dữ liệu.

Điều đó quan trọng vì thường có nghĩa là:

• Truy vấn nhanh hơn mà không cần thay đổi ứng dụng
• Ít phần cứng hơn để đạt cùng hiệu năng
• Hiệu năng dự đoán hơn khi tập dữ liệu lớn dần

Ingres không phát minh mọi mảnh tối ưu hiện đại, nhưng nó giúp thiết lập mẫu: SQL + một bộ tối ưu là điều biến hệ thống quan hệ từ “ý hay” thành công cụ hàng ngày.

Postgres: Ý tưởng lớn về cơ sở dữ liệu có thể mở rộng

Các cơ sở dữ liệu quan hệ ban đầu thường giả định một tập kiểu dữ liệu cố định (số, văn bản, ngày) và một tập thao tác cố định (lọc, join, tổng hợp). Điều đó hoạt động tốt — cho đến khi các đội bắt đầu lưu kiểu thông tin mới (địa lý, log, time series, identifier chuyên ngành) hoặc cần tính năng hiệu năng chuyên biệt.

Với thiết kế cứng nhắc, mỗi yêu cầu mới trở thành lựa chọn tệ: ép dữ liệu vào blob văn bản, gắn thêm hệ thống riêng, hoặc chờ vendor thêm hỗ trợ.

Khả năng mở rộng — giải thích dễ hiểu

Postgres thúc đẩy ý tưởng khác: cơ sở dữ liệu nên mở rộng được — nghĩa là bạn có thể thêm khả năng mới một cách có kiểm soát, mà không phá vỡ tính an toàn và đúng như bạn mong đợi từ SQL.

Nói đơn giản, mở rộng giống như thêm phụ kiện được chứng nhận cho một máy khoan thay vì tự sửa lại động cơ. Bạn có thể dạy cơ sở dữ liệu “mẹo mới”, trong khi vẫn giữ giao dịch, quyền, và tối ưu truy vấn hoạt động như một tổng thể mạch lạc.

Cách điều này định hình hệ sinh thái extension hiện đại

Tư duy này hiện rõ trong hệ sinh thái PostgreSQL ngày nay (và nhiều hệ lấy cảm hứng từ Postgres). Thay vì chờ một tính năng lõi, các đội có thể dùng extension đã được kiểm duyệt tích hợp tốt với SQL và tooling vận hành.

Ví dụ ở mức cao:

• Kiểu dữ liệu tùy chỉnh: lưu giá trị phong phú (ví dụ: điểm địa lý, khoảng, hoặc cấu trúc giống JSON) như thành phần chính.
• Hàm tùy chỉnh: thêm logic domain có thể dùng trực tiếp trong truy vấn và báo cáo.
• Tùy chọn lập chỉ mục: chọn loại index phù hợp cho các pattern truy cập khác nhau, giúp cùng một truy vấn SQL chạy nhanh hơn nhiều.

Điểm mấu chốt là Postgres coi “thay đổi khả năng của cơ sở dữ liệu” như mục tiêu thiết kế — không phải việc làm thêm — và ý tưởng đó vẫn ảnh hưởng cách các nền tảng dữ liệu hiện đại tiến hóa.

Giao dịch và đồng thời: Đảm bảo kết quả đúng khi mở rộng

Cơ sở dữ liệu không chỉ lưu thông tin — chúng đảm bảo thông tin luôn đúng, kể cả khi nhiều thứ xảy ra cùng lúc. Đó là vai trò của giao dịch và kiểm soát đồng thời, và là lý do lớn khiến hệ thống SQL được tin dùng cho công việc thực tế.

Giao dịch đảm bảo những gì thực sự

Một giao dịch là một nhóm thay đổi phải thành công hoặc thất bại như một đơn vị.

Nếu bạn chuyển tiền giữa các tài khoản, đặt đơn hàng, hoặc cập nhật tồn kho, bạn không thể chấp nhận kết quả “nửa chừng”. Giao dịch đảm bảo bạn không kết thúc với đơn hàng bị tính tiền mà chưa giữ hàng — hoặc tồn kho giảm mà không có đơn nào được ghi nhận.

Về thực tế, giao dịch đem lại:

• Tính nhất quán dễ giải thích cho con người: cơ sở dữ liệu không “áp dụng một phần” thay đổi.
• Khả năng phục hồi: nếu điều gì đó sập giữa chừng, hệ thống có thể rollback về trạng thái an toàn.

Đồng thời: mớ hỗn độn thực tế cần xử lý

Đồng thời nghĩa là nhiều người (và ứng dụng) đọc và thay đổi dữ liệu cùng lúc: thanh toán khách hàng, nhân viên hỗ trợ sửa hồ sơ, job nền cập nhật trạng thái, analyst chạy báo cáo.

Không có quy tắc cẩn thận, đồng thời tạo ra các vấn đề như:

• Cập nhật bị mất: hai người sửa cùng bản ghi; một người ghi đè người kia.
• Đọc bẩn: ai đó thấy dữ liệu sau đó bị rollback.
• Báo cáo không nhất quán: truy vấn thấy trạng thái “trước” và “sau” lẫn lộn.

MVCC giải thích đơn giản

Một cách tiếp cận có ảnh hưởng là MVCC (Multi-Version Concurrency Control). Về khái niệm, MVCC giữ nhiều phiên bản của một dòng trong một thời gian ngắn, nên người đọc có thể giữ một snapshot ổn định trong khi người ghi thực hiện cập nhật.

Lợi ích lớn là đọc ít chặn ghi hơn, và người ghi không thường xuyên bị dừng bởi các truy vấn dài. Bạn vẫn có được tính đúng, nhưng với ít chờ đợi hơn.

Tại sao điều này quan trọng trong workload SQL hiện đại

Ngày nay các cơ sở dữ liệu phục vụ workload hỗn hợp: ghi ứng dụng cao cộng với truy vấn đọc cho dashboard, view khách hàng và phân tích vận hành. Hệ thống SQL hiện đại dựa vào kỹ thuật như MVCC, khoá thông minh và mức cách ly để cân bằng tốc độ với độ đúng — để bạn có thể mở rộng hoạt động mà không đánh đổi niềm tin vào dữ liệu.

Lưu trữ theo cột: Bước ngoặt cho hiệu năng phân tích

Cơ sở dữ liệu hướng hàng được xây cho xử lý giao dịch: nhiều đọc/ghi nhỏ, thường chạm một khách hàng, một đơn, một tài khoản một lần. Thiết kế đó tuyệt khi bạn cần lấy hoặc cập nhật một bản ghi hoàn chỉnh nhanh.

Hàng vs cột (tuyệt ví dụ hàng ngày)

Hãy nghĩ về một bảng tính. Row store giống như lưu mỗi hàng vào một thư mục riêng: khi bạn cần “mọi thứ về Đơn #123”, bạn kéo một thư mục. Column store giống như sắp xếp theo cột: ngăn kéo cho “order_total”, ngăn cho “order_date”, ngăn cho “customer_region”.

Với phân tích, hiếm khi bạn cần cả thư mục — bạn thường hỏi “Doanh thu theo vùng quý trước?” Truy vấn đó chạm vài trường trên hàng triệu bản ghi.

Tại sao workload phân tích thích cột

Truy vấn phân tích thường:

• Quét phần lớn bảng
• Chỉ dùng vài cột
• Tổng hợp (SUM/AVG/COUNT) và lọc mạnh

Với lưu trữ theo cột, engine có thể chỉ đọc các cột được tham chiếu, bỏ qua phần còn lại. Đọc ít dữ liệu từ đĩa (và ít di chuyển qua bộ nhớ) thường là lợi ích lớn nhất cho hiệu năng.

Nén không chỉ để tiết kiệm chỗ

Các cột có xu hướng nhiều giá trị lặp lại (vùng, trạng thái, loại). Điều này khiến chúng dễ nén — và nén có thể tăng tốc phân tích vì hệ thống đọc ít byte hơn và đôi khi vận hành trực tiếp trên dữ liệu nén hiệu quả hơn.

Sự chuyển dịch lớn hơn

Lưu trữ theo cột đánh dấu sự chuyển từ database ưu tiên OLTP sang engine ưu tiên phân tích, nơi quét, nén và tổng hợp nhanh trở thành mục tiêu thiết kế chính thay vì tính năng phụ.

Vertica và MPP cho phân tích: nhân rộng SQL cho truy vấn lớn

Vertica là ví dụ rõ ràng về cách các ý tưởng của Stonebraker về cơ sở dữ liệu phân tích trở thành sản phẩm mà đội có thể chạy trong production. Nó lấy bài học từ lưu trữ theo cột và ghép với thiết kế phân tán nhằm giải quyết vấn đề cụ thể: trả lời truy vấn SQL phân tích lớn nhanh, ngay cả khi khối lượng dữ liệu vượt quá một máy chủ đơn.

MPP nghĩa là gì (ngôn ngữ dễ hiểu)

MPP nghĩa là nhiều máy cùng làm việc trên một truy vấn SQL cùng lúc.

Thay vì một server đọc toàn bộ dữ liệu và thực hiện mọi việc, dữ liệu được chia trên các node. Mỗi node xử lý lát cắt của nó song song, và hệ thống kết hợp kết quả từng phần thành câu trả lời cuối cùng.

Đây là cách một truy vấn mất hàng phút trên một máy có thể giảm xuống còn giây khi trải trên cluster — với điều kiện dữ liệu phân phối tốt và truy vấn có thể song song hóa.

Nó cho phép gì trong thực tế

Hệ thống phân tích kiểu Vertica tỏa sáng khi bạn có nhiều hàng và muốn quét, lọc, tổng hợp chúng hiệu quả. Các case điển hình:

• Dashboard đọc bảng fact lớn (phân tích sản phẩm, hiệu suất marketing, metric vận hành)
• Báo cáo định kỳ và phân tích ad-hoc bằng SQL
• Tổng hợp lớn (cohort hàng ngày, funnel, top-N, rollup theo nhiều chiều)

Trade-offs so với cơ sở dữ liệu giao dịch

MPP không thay thế drop-in cho hệ thống transactional. Chúng tối ưu cho đọc nhiều hàng và tính tổng, không cho nhiều cập nhật nhỏ.

Kết quả là các trade-off phổ biến:

• Độ tươi: dữ liệu thường đến theo lô hoặc micro-batch hơn là hàng-đơn vị
• Cập nhật: cập nhật/xoá từng hàng thường chậm hoặc phức tạp vận hành hơn
• Độ trễ: tuyệt cho truy vấn phân tích giây–phút; không lý tưởng cho transaction hướng người dùng mili-giây

Ý chính là tập trung: Vertica và hệ tương tự có tốc độ bằng cách điều chỉnh lưu trữ, nén và thực thi song song cho phân tích — rồi chấp nhận những giới hạn mà hệ thống giao dịch tránh.