Khám phá những ý tưởng chính của Michael Stonebraker đằng sau Ingres, Postgres và Vertica — và cách chúng định hình kho dữ liệu SQL, engine phân tích và kiến trúc dữ liệu ngày nay.
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.
Đâ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:
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:
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.
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.
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.
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.
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.
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.
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ế.
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 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 (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?
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ể:
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.
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.
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à:
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.
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ợ.
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.
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:
Đ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.
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ế.
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:
Đồ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ư:
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.
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.
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ã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.
Truy vấn phân tích thường:
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.
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.
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 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à 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.
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:
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:
Ý 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.
Ông là một trường hợp hiếm hoi mà những hệ thống nghiên cứu trở thành DNA sản phẩm thực tế. Những ý tưởng được chứng minh trong Ingres (SQL + tối ưu truy vấn), Postgres (mở rộng khả năng + tư duy MVCC) và Vertica (lưu trữ theo cột + MPP cho phân tích) xuất hiện trong cách xây dựng và tiếp thị kho dữ liệu, cơ sở dữ liệu OLTP và nền tảng streaming ngày nay.
SQL thắng thế vì nó cho phép bạn mô tả cái gì bạn muốn, trong khi cơ sở dữ liệu lo phần làm thế nào để lấy dữ liệu đó một cách hiệu quả. Sự tách bạch này đem lại:
Bộ tối ưu dựa trên chi phí dùng thống kê bảng để so sánh các kế hoạch truy vấn khả thi và chọn kế hoạch có chi phí kỳ vọng thấp nhất (I/O, CPU, bộ nhớ). Về thực tế, nó giúp bạn:
MVCC (Multi-Version Concurrency Control) giữ nhiều phiên bản của một dòng để người đọc thấy một snapshot nhất quán trong khi người ghi cập nhật. Nói đơn giản:
Khả năng mở rộng (extensibility) có nghĩa là cơ sở dữ liệu có thể an toàn thêm tính năng mới—kiểu dữ liệu, hàm, index—mà không phải fork hay viết lại engine. Điều này hữu ích khi bạn cần:
Quy tắc vận hành: coi extension như dependency—version hoá, test khi nâng cấp, và giới hạn ai được cài đặt chúng.
Row store tuyệt cho khi bạn thường đọc hoặc ghi cả bản ghi (OLTP). Column store tỏa sáng khi bạn quét nhiều hàng nhưng chỉ cần một vài trường (phân tích).
Heuristic đơn giản:
MPP (massively parallel processing) phân chia dữ liệu qua nhiều node để nhiều máy cùng thực hiện một truy vấn SQL. Phù hợp mạnh khi:
Cẩn thận với trade-off như lựa chọn phân phối dữ liệu, chi phí shuffle khi join, và trải nghiệm kém hơn cho cập nhật một hàng tần suất cao.
Vectorized execution xử lý dữ liệu theo lô (vector) thay vì từng hàng một, giảm overhead và tận dụng cache CPU. Bạn thường thấy:
Hệ thống batch chạy job theo lịch nên dữ liệu “tươi” có thể trễ. Hệ thống streaming coi các sự kiện là đầu vào liên tục và tính toán kết quả một cách tăng dần.
Những nơi streaming thực sự có giá trị:
Để giữ phép tính có giới hạn, streaming dùng windows (ví dụ: 5 phút gần nhất) thay vì “tất cả thời gian”.
Dùng nhiều hệ thống khi mỗi hệ thống có ranh giới workload rõ ràng và lợi ích đo được (chi phí, độ trễ, độ tin cậy). Để tránh bùng nổ công cụ:
Nếu cần khung chọn lựa, dùng checklist mindset như trong bài.
