OLTP (Online Transaction Processing) là kiểu hệ thống xử lý rất nhiều giao dịch nhỏ cùng lúc: bán một món hàng, ghi một bút toán, cập nhật một tồn kho. OLAP (Online Analytical Processing) là kiểu hệ thống trả lời câu hỏi tổng hợp trên khối lượng lớn: doanh thu ba năm theo vùng, theo nhóm hàng, theo tháng. Hai loại tải này có yêu cầu gần như đối nghịch, nên được thiết kế, lưu trữ và tối ưu theo cách khác nhau.
Với nhà quản lý, hiểu khác biệt này giải thích được những hiện tượng quen thuộc: vì sao chạy báo cáo cuối tháng làm phần mềm bán hàng chậm, vì sao bộ phận CNTT đòi xây kho dữ liệu riêng, và vì sao một số nhà cung cấp quảng bá hệ thống "làm được cả hai". Bài này giải thích cơ chế bên dưới mà không cần bạn biết lập trình.
So sánh OLTP và OLAP theo chín tiêu chí
Bảng dưới mô tả hai đầu điển hình của một dải liên tục; nhiều hệ thống thực tế nằm ở giữa.
| Tiêu chí | OLTP | OLAP |
|---|---|---|
| Câu hỏi điển hình | Đơn hàng số này gồm những gì, khách còn nợ bao nhiêu | Doanh thu theo vùng, theo quý trong ba năm |
| Thao tác chính | Thêm, sửa, xoá từng dòng | Đọc và tổng hợp hàng triệu dòng |
| Số người dùng đồng thời | Rất nhiều: thu ngân, nhân viên kho, khách đặt hàng | Ít hơn: phân tích viên, quản lý |
| Thời gian phản hồi mong đợi | Mili giây | Vài giây đến vài phút |
| Thiết kế dữ liệu | Chuẩn hoá cao, tránh lặp | Phi chuẩn hoá, mô hình chiều |
| Cách lưu trữ điển hình | Theo dòng | Theo cột |
| Dữ liệu | Trạng thái hiện tại | Lịch sử nhiều năm |
| Yêu cầu nhất quán | Nghiêm ngặt từng giao dịch (ACID) | Nhất quán theo lô nạp |
| Hậu quả khi chậm | Khách chờ ở quầy, mất đơn | Báo cáo trễ |
Hàng cuối cùng là lý do kinh doanh để tách hai hệ thống: hậu quả khi OLTP chậm là mất tiền ngay, còn OLAP chậm chỉ làm báo cáo trễ. Không nên để loại tải ít khẩn cấp làm hại loại tải khẩn cấp.
Vì sao chuẩn hoá tốt cho giao dịch nhưng tệ cho phân tích
Mô hình quan hệ do Edgar F. Codd đề xuất năm 1970 cùng các dạng chuẩn hoá giúp hệ thống giao dịch tránh lặp dữ liệu: tên khách hàng chỉ lưu một chỗ, đơn hàng chỉ lưu mã khách. Khi khách đổi tên, chỉ sửa một dòng; không có nguy cơ hai nơi lưu hai tên khác nhau. Với hàng nghìn thao tác ghi mỗi giây, đây là thiết kế đúng: mỗi giao dịch chạm vào ít dòng nhất có thể.
Nhưng một câu hỏi phân tích như "doanh thu theo ngành hàng, theo tỉnh của khách, theo tháng" trên cơ sở dữ liệu chuẩn hoá có thể phải nối năm, bảy bảng: dòng đơn hàng, đơn hàng, sản phẩm, nhóm sản phẩm, ngành hàng, khách hàng, địa chỉ. Mỗi phép nối trên hàng triệu dòng tốn tài nguyên và giữ khoá trên bảng, làm chậm các giao dịch đang diễn ra. Mô hình chiều trong kho dữ liệu đi theo hướng ngược lại: chấp nhận lặp thông tin mô tả (tên ngành hàng lặp trên mọi sản phẩm của ngành đó) để câu hỏi phân tích chỉ cần nối một bảng lớn với vài bảng nhỏ.
Đây là ví dụ kinh điển của việc không có thiết kế tốt nhất tuyệt đối, chỉ có thiết kế tốt nhất cho một loại tải. Tranh cãi "chuẩn hoá hay phi chuẩn hoá" giữa kỹ sư thường là tranh cãi giữa hai người đang nghĩ về hai loại tải khác nhau.
Lưu theo dòng và lưu theo cột: cơ chế đằng sau tốc độ
Lưu theo dòng. Cơ sở dữ liệu giao dịch thường ghi mọi trường của một bản ghi nằm cạnh nhau trên đĩa: mã đơn, ngày, khách, sản phẩm, số lượng, giá. Khi cần đọc hoặc sửa một đơn hàng, hệ thống lấy cả khối một lần. Đây là cách nhanh nhất cho thao tác trên từng bản ghi.
Lưu theo cột. Cơ sở dữ liệu phân tích ghi mọi giá trị của một cột nằm cạnh nhau: toàn bộ cột ngày, rồi toàn bộ cột số tiền. Câu hỏi "tổng tiền theo tháng" chỉ cần đọc hai cột trong số có thể vài chục cột, bỏ qua phần còn lại. Với bảng rộng, lượng dữ liệu phải đọc giảm nhiều lần.
Nén hiệu quả hơn. Giá trị trong cùng một cột thường giống nhau (cột tỉnh thành chỉ có vài chục giá trị lặp lại), nên nén theo cột đạt tỷ lệ cao. Dữ liệu nhỏ hơn thì đọc từ đĩa và đưa vào bộ nhớ nhanh hơn.
Xử lý theo lô véc-tơ. Bộ máy truy vấn hiện đại xử lý cả khối giá trị cùng cột một lúc, tận dụng tốt bộ nhớ đệm và lệnh véc-tơ của CPU. Đây là một lý do khiến kho dữ liệu đám mây quét hàng trăm triệu dòng trong vài giây.
Cái giá phải trả. Ghi hoặc sửa một bản ghi đơn lẻ trong kho lưu theo cột chậm và tốn kém, vì phải chạm vào nhiều vùng lưu trữ. Vì vậy kho phân tích thích nạp theo lô hơn là ghi từng dòng.
Khối OLAP, cuộc tranh luận năm 1993 và điều còn lại ngày nay
Thuật ngữ OLAP được Codd và cộng sự đưa ra năm 1993 trong một báo cáo đề xuất mười hai quy tắc cho công cụ phân tích đa chiều. Báo cáo này sau đó gây tranh cãi vì được một hãng phần mềm OLAP tài trợ, điều không được nêu rõ khi công bố, khiến nhiều người xem nó như tài liệu tiếp thị hơn là nghiên cứu độc lập. Dù vậy, thuật ngữ đã ở lại và trở thành tên gọi chung của cả một nhóm công nghệ.
Thế hệ đầu của OLAP là khối dữ liệu đa chiều (MOLAP): dữ liệu được tính sẵn tổng theo mọi tổ hợp chiều (sản phẩm × vùng × tháng) và lưu trong cấu trúc chuyên dụng. Người dùng thao tác các phép quen thuộc: cuộn lên (roll-up) từ tháng lên quý, khoan xuống (drill-down) từ vùng xuống cửa hàng, cắt lát (slice) lấy một tháng, xoay (pivot) đổi hàng thành cột. Khối trả lời rất nhanh nhưng tốn thời gian tính lại mỗi khi nạp dữ liệu mới và phình nhanh khi số chiều tăng. Song song có ROLAP, chạy phân tích đa chiều trực tiếp trên cơ sở dữ liệu quan hệ.
Ngày nay, với kho lưu theo cột đủ nhanh để tổng hợp ngay khi truy vấn, nhu cầu tính sẵn khối giảm đi nhiều. Nhưng tư duy đa chiều vẫn nguyên giá trị: các phép cuộn lên, khoan xuống, cắt lát chính là cách người dùng thao tác trên mọi công cụ BI, và bảng tổng hợp tính sẵn vẫn được dùng cho dashboard cần phản hồi tức thì.
Dấu hiệu doanh nghiệp đang để tải phân tích làm hại hệ thống giao dịch
Nếu doanh nghiệp bạn gặp từ hai dấu hiệu trở lên dưới đây, đã đến lúc tách luồng báo cáo khỏi cơ sở dữ liệu nghiệp vụ:
- Phần mềm bán hàng hoặc ERP chậm rõ rệt vào ngày đầu tháng, khi các phòng đồng loạt chạy báo cáo.
- Bộ phận CNTT cấm chạy một số báo cáo trong giờ hành chính, hoặc yêu cầu đăng ký giờ chạy.
- Có báo cáo phải chạy qua đêm mới xong, và hỏng nếu ai đó sửa dữ liệu trong lúc chạy.
- Phân tích viên được cấp tài khoản đọc trực tiếp cơ sở dữ liệu chính, viết truy vấn tự do không qua kiểm soát.
- Nhà cung cấp phần mềm nghiệp vụ cảnh báo về hiệu năng hoặc từ chối hỗ trợ khi có truy vấn bên ngoài.
Các bước xử lý theo mức tốn kém tăng dần: dời lịch chạy báo cáo nặng ra ngoài giờ cao điểm; tạo bản sao chỉ đọc của cơ sở dữ liệu cho báo cáo (giảm tải nhưng vẫn dùng thiết kế chuẩn hoá); xây kho dữ liệu riêng với mô hình chiều và lưu theo cột. Mỗi bước đều hợp lý ở một giai đoạn, không cần nhảy thẳng tới bước cuối.
HTAP: hệ thống "làm được cả hai" có xoá được ranh giới?
Khái niệm. HTAP (Hybrid Transactional/Analytical Processing), thuật ngữ được Gartner phổ biến khoảng giữa thập niên 2010, chỉ các hệ thống xử lý cả giao dịch lẫn phân tích trên cùng một nền, thường bằng cách giữ song song bản lưu theo dòng và bản lưu theo cột của cùng dữ liệu, đồng bộ tự động.
Lợi ích thật. Phân tích gần thời gian thực mà không cần luồng ETL, phù hợp với những quyết định vận hành cần số tức thì như kiểm soát tồn kho khi bán hàng nhanh hoặc phát hiện giao dịch bất thường.
Điều HTAP không làm thay. Nó không tích hợp dữ liệu từ nhiều hệ thống nguồn khác nhau, không thay việc thống nhất định nghĩa, và không giữ lịch sử dimension. Doanh nghiệp có năm hệ thống nghiệp vụ vẫn cần một nơi tích hợp.
Nhận định. Ranh giới OLTP–OLAP đang mờ dần ở tầng công nghệ, nhưng ở tầng quản trị dữ liệu thì không. Câu hỏi cần đặt cho nhà cung cấp quảng bá HTAP là: hệ thống của họ giải quyết bài toán độ trễ, hay bài toán tích hợp? Phần lớn doanh nghiệp vừa đang gặp bài toán thứ hai.
Đọc một truy vấn phân tích đi qua hai loại hệ thống
Để thấy khác biệt cụ thể, hãy theo một câu hỏi giả định: "tổng doanh thu theo tỉnh của khách trong ba năm qua", trên bảng dòng hoá đơn khoảng 50 triệu dòng, mỗi dòng 40 cột.
- Trên cơ sở dữ liệu giao dịch lưu theo dòng: hệ thống phải đọc gần như toàn bộ 50 triệu dòng với đủ 40 cột, vì các trường của một dòng nằm chung khối; sau đó nối sang bảng đơn hàng, khách hàng, địa chỉ để lấy tỉnh. Trong lúc đó, các thao tác ghi hoá đơn mới phải tranh tài nguyên đĩa và bộ nhớ với truy vấn này.
- Trên kho dữ liệu lưu theo cột với mô hình chiều: hệ thống chỉ đọc ba cột của bảng fact (ngày, khoá khách, doanh thu), đã nén mạnh, rồi nối với một dimension khách hàng nhỏ đã có sẵn cột tỉnh. Lượng dữ liệu phải đọc chỉ còn một phần nhỏ so với cách trên.
- Nếu có bảng tổng hợp tính sẵn doanh thu theo tháng theo tỉnh, câu hỏi trả lời gần như tức thì vì chỉ phải đọc vài nghìn dòng. Cái giá là bảng đó phải được làm mới sau mỗi lần nạp và không trả lời được câu hỏi ở độ hạt chi tiết hơn.
- Kết luận cho người quản lý: cùng một câu hỏi, chênh lệch thời gian có thể từ hàng chục phút xuống vài giây, và quan trọng hơn, hệ thống bán hàng không bị ảnh hưởng. Đó là phần lớn giá trị kỹ thuật của việc tách OLAP khỏi OLTP.
Câu hỏi thường gặp
Bản sao chỉ đọc (read replica) có đủ thay cho kho dữ liệu không?
Bản sao chỉ đọc giải quyết vấn đề tải lên hệ thống chính, nhưng vẫn giữ thiết kế chuẩn hoá, chỉ chứa dữ liệu của một hệ thống và không giữ lịch sử thay đổi. Nó là bước trung gian tốt khi chỉ có một nguồn, chưa thay được kho khi cần tích hợp nhiều nguồn.
ACID là gì và vì sao quan trọng với OLTP?
ACID là bốn tính chất của giao dịch: nguyên tử, nhất quán, cô lập, bền vững. Nó đảm bảo một lần chuyển hàng không bị ghi nửa chừng, hai thu ngân không bán cùng một món hàng cuối cùng. Với hệ thống tiền và hàng, đây là yêu cầu không thể nhân nhượng.
Excel PivotTable có phải là OLAP không?
Về tư duy thì có: PivotTable cho phép cuộn lên, khoan xuống, cắt lát, xoay trên dữ liệu đa chiều. Excel còn kết nối được tới khối OLAP và mô hình dữ liệu. Giới hạn nằm ở khối lượng, khả năng chia sẻ và kiểm soát định nghĩa khi nhiều người cùng dùng.
Cơ sở dữ liệu NoSQL thuộc loại OLTP hay OLAP?
Phần lớn cơ sở dữ liệu NoSQL phổ biến như dạng tài liệu hay khoá–giá trị được thiết kế cho tải giao dịch quy mô lớn, gần với OLTP. Một số hệ thống lưu theo cột rộng hoặc chuyên chuỗi thời gian lại phục vụ phân tích. Cần xem thiết kế cụ thể thay vì xếp theo nhãn.
Doanh nghiệp nhỏ dùng phần mềm thuê bao có cần quan tâm OLTP và OLAP không?
Ít hơn, vì nhà cung cấp lo phần hạ tầng. Nhưng bạn vẫn gặp giới hạn: báo cáo dựng sẵn của phần mềm thuê bao thường chạy trên dữ liệu giao dịch nên hạn chế về độ phức tạp và lịch sử. Khi cần kết hợp nhiều phần mềm, bạn sẽ cần xuất dữ liệu ra nơi phân tích riêng.