OLTP và OLAP

Bối cảnh

Sao Mai là một chuỗi cửa hàng tạp hoá và đồ gia dụng. Chuỗi bắt đầu từ một cửa hàng và đang mở thêm cửa hàng mới. Mỗi cửa hàng bán hàng qua máy tính tiền; dữ liệu bán hàng được gửi về văn phòng để các phòng ban làm báo cáo. Tên chuỗi và mọi số liệu trong bài là giả lập.

Sáng 15/09/2026, phòng Kinh doanh mở lại báo cáo tiền hàng bán ra trong tuần 07/09–13/09/2026 để xem theo cửa hàng. Trong tình huống giả lập của bài này, báo cáo đọc trực tiếp từ hệ thống bán hàng. Cùng lúc ấy, nhân viên thu ngân phản ánh việc lưu hoá đơn chậm hơn thường lệ.

Một đồng nghiệp đề nghị xây data warehouse riêng để chạy báo cáo. Muốn xét đề nghị này, cần biết báo cáo có làm chậm việc lưu hoá đơn không, hay nguyên nhân nằm ở mạng hoặc việc khác trong hệ thống.

Bài này xét hai nhu cầu dùng dữ liệu để chọn bước tiếp theo. Tình huống nói về báo cáo tuần, khác với lần báo cáo ngày về trễ trong bài “Hành trình của dữ liệu”.

Xử lý giao dịch và xử lý phân tích

Khi thu ngân lưu hoá đơn, hệ thống cần ghi đúng món hàng, số lượng, giá bán và trạng thái thanh toán. Nếu khách vừa trả tiền mà hoá đơn chưa lưu được, cửa hàng khó tiếp tục phục vụ. Khi tra lại hoá đơn, nhân viên cũng cần tìm đúng giao dịch ấy, chứ không cần đọc cả lịch sử bán hàng.

Xử lý giao dịch trực tuyến (Online Transaction Processing, OLTP) là cách xử lý phục vụ các giao dịch đang diễn ra, như tạo hoá đơn, ghi nhận thanh toán hoặc cập nhật giao dịch theo nghiệp vụ. “Trực tuyến” ở đây không chỉ việc mua hàng trên mạng; bán tại quầy cũng có nhu cầu này. Hệ thống cần xử lý từng giao dịch đúng và đủ nhanh để công việc tiếp tục.

Phòng Kinh doanh lại muốn biết cửa hàng nào bán được nhiều tiền hàng trong tuần. Họ cần gom các dòng hàng theo cửa hàng rồi cộng lại. Nếu muốn so các kỳ, họ còn cần dữ liệu lịch sử của những kỳ đó. Một giao dịch riêng lẻ không trả lời được câu hỏi này.

Xử lý phân tích trực tuyến (Online Analytical Processing, OLAP) là cách xử lý phục vụ việc tổng hợp, so sánh và tìm hiểu dữ liệu, thường qua nhiều giao dịch và nhiều kỳ. Người dùng có thể xem tổng của chuỗi, rồi xem theo cửa hàng hoặc nhóm hàng để hiểu vì sao tổng thay đổi.

Hai kiểu xử lý khác nhau ở công việc cần phục vụ. Hệ thống giao dịch vừa ghi vừa đọc, như khi tra hoá đơn. Nơi phân tích chủ yếu đọc để tính báo cáo, nhưng cũng nhận và cập nhật dữ liệu.

Cùng những dòng hàng ấy có thể phục vụ cả hai nhu cầu; khác nhau là phạm vi dữ liệu, cách xử lý và thời điểm cần kết quả. Một hệ thống có thể phục vụ cả OLTP lẫn OLAP nếu đáp ứng được các yêu cầu ấy.

Tách tải là tách phần việc nào

Tải trong bài là phần công việc hệ thống phải xử lý. Khi nhiều báo cáo cùng đọc và tính trên dữ liệu bán hàng, chúng có thể dùng tài nguyên mà việc lưu hoá đơn cũng đang cần. Hệ thống có thể phải chờ, nên công việc ở quầy bị chậm dù báo cáo không sửa hoá đơn nào.

Tách tải phân tích nghĩa là cho việc đọc và tính báo cáo chạy ở nơi có tài nguyên riêng, giảm phần việc dùng chung với hệ thống bán hàng. Tạo thêm một bảng mà vẫn dùng chung tài nguyên thì tải vẫn chưa tách. Việc lấy dữ liệu sang nơi riêng cũng có thể gây tải lên nguồn, nên cần xét cả khâu này và lúc chạy báo cáo.

Data warehouse là nơi tập hợp và tổ chức dữ liệu để phục vụ báo cáo, phân tích. Data warehouse riêng hợp khi cần dữ liệu lịch sử, kết hợp nhiều nguồn và phục vụ báo cáo đều đặn. Với nhu cầu tổng hợp nhỏ, tệp xuất sẵn hoặc bảng tổng ở nơi xử lý riêng có thể đủ. Vì vậy, chọn cách tách tải chưa có nghĩa là phải chọn data warehouse.

Tách tải cũng có phần phải đánh đổi: dữ liệu phân tích có thể chưa theo kịp giao dịch vừa ghi, và có thêm việc chuyển dữ liệu, đối chiếu, vận hành. Nếu quản lý cần kết quả ngay sau mỗi lần bán, nhịp cập nhật phải đáp ứng nhu cầu đó. Còn khi chỉ xem lại tuần đã kết thúc, bản dữ liệu đã chốt kỳ có thể đủ, chưa cần cập nhật liên tục.

Ví dụ giải sẵn

Cùng dữ liệu, khác phạm vi cần dùng

Bảng sau ghi yêu cầu nghiệp vụ, không ghi kết quả đo tốc độ.

Khi tra hoá đơn HD1001, phần dữ liệu cần xem có 2 dòng hàng:

Khi tổng hợp tuần, phần dữ liệu cần tính có 6 dòng hàng. Báo cáo lấy số lượng nhân đơn giá rồi cộng theo cửa hàng, không trừ giảm giá và hàng trả lại. Đây là cách tính tiền hàng bán ra của phòng Kinh doanh trong bộ dữ liệu, không phải tiền thực thu.

Phạm vi yêu cầu cho biết cần dữ liệu của những dòng nào; phần mềm thực tế đọc bao nhiêu dòng còn tuỳ cách tìm hoá đơn và tính tổng. Bộ dữ liệu nhỏ này chỉ minh hoạ sự khác nhau giữa tra một giao dịch và tổng hợp nhiều giao dịch, không cho biết Sao Mai có quá tải hay đặt ra ngưỡng số dòng để quyết định tách.

Phiếu xét tách tải đã điền

Với sự cố ở đầu bài, bước trước mắt là tìm bằng chứng và giảm ảnh hưởng tới quầy trong lúc kiểm tra.

Hai việc cùng chậm là dấu hiệu cần kiểm, chưa đủ xác nhận nguyên nhân. Người phụ trách kỹ thuật có thể so các khoảng tương đương có và không chạy báo cáo, đồng thời xét mạng và các việc khác. Nên dùng ghi nhận hiện có nếu đã đủ rõ, tránh cố chạy báo cáo nặng giữa lúc đông khách để thử.

Nếu tách, đường đi dự kiến có thể viết như sau:

1. Hệ thống bán hàng tiếp tục ghi và tra giao dịch tại quầy.
2. Phần dữ liệu cần phân tích được chuyển sang nơi xử lý riêng theo lịch đã thống nhất.
3. Báo cáo đọc và tính ở nơi riêng; người xem biết dữ liệu đã cập nhật tới mốc nào.

Nếu cần tìm hoá đơn vừa thanh toán, nhân viên vẫn dùng hệ thống bán hàng, vì nơi phân tích có thể chưa nhận được giao dịch ấy.

Khi nào nên làm, khi nào chưa cần

Nên ưu tiên tách khi đã có bằng chứng tải phân tích làm chậm việc bán hàng, sự cố lặp lại và người dùng cần báo cáo ngay trong giờ bán. Nhu cầu phân tích nhiều kỳ hoặc nhiều nguồn cũng có thể là lý do tổ chức nơi phân tích riêng, dù quầy chưa chậm. Ưu tiên tách là giải quyết việc dùng chung tài nguyên, chưa phải mua ngay một data warehouse lớn. Trong lúc chuẩn bị, có thể dừng hoặc dời báo cáo chưa cấp thiết. Với báo cáo cần đúng giờ, hãy thống nhất cách cung cấp kết quả tạm đáp ứng được nhu cầu.

Có thể tách sau khi có dấu hiệu ảnh hưởng nhưng chưa rõ nguyên nhân, hoặc khi dời giờ chạy vẫn đáp ứng cả việc bán hàng lẫn báo cáo. Trong lúc chờ, có thể thu hẹp kỳ cần đọc, dùng lại kết quả đã tính cho cùng kỳ hoặc xuất dữ liệu để phân tích riêng, miễn người dùng chấp nhận lịch và vẫn có đủ dữ liệu để quyết định. Nếu bán hàng vẫn bị ảnh hưởng, cần xét lại lựa chọn tách.

Chưa cần tách khi báo cáo ít, phạm vi nhỏ, hệ thống hiện tại đáp ứng được cả việc bán lẫn giờ cần báo cáo. Với phân tích một lần trên kỳ đã chốt, tệp xuất sẵn có thể đủ. Khi báo cáo chậm vì batch (lô dữ liệu) chưa tới, tách nơi tính báo cáo cũng không làm batch tới sớm hơn. Nên xử lý chỗ đang chờ trước.

Tự làm

Hiểu nhầm thường gặp

“OLTP là bán trên mạng, OLAP là báo cáo trên mạng.” Hai tên nói về kiểu xử lý. Bán tại quầy cũng cần xử lý giao dịch; bản tổng hợp từ tệp xuất vẫn phục vụ nhu cầu phân tích.

“Báo cáo chỉ đọc thì không thể làm chậm bán hàng.” Việc đọc và tính vẫn có thể dùng chung tài nguyên với giao dịch; mức ảnh hưởng cần được kiểm trên hệ thống đang dùng.

“Báo cáo chậm là phải xây data warehouse riêng.” Có thể báo cáo đang chờ dữ liệu, cách tính chưa phù hợp hoặc hệ thống còn vấn đề khác. Nếu dời lịch hay thu hẹp phạm vi vẫn đáp ứng nhu cầu, chưa cần tách.

“Tách rồi thì số liệu vừa bán sẽ có ngay và chắc chắn đúng.” Nơi phân tích còn phải nhận, kiểm và tính dữ liệu. Tách tải không tự sửa lỗi dữ liệu hay khác biệt trong cách tính doanh thu.

Tóm tắt

• Xử lý giao dịch phục vụ công việc đang diễn ra; xử lý phân tích tổng hợp và so sánh dữ liệu để trả lời câu hỏi. Cùng dữ liệu có thể phục vụ cả hai.
• Báo cáo chỉ đọc vẫn có thể ảnh hưởng việc lưu hoá đơn nếu dùng chung tài nguyên. Cần kiểm nguyên nhân trước khi quyết định tách.
• Ưu tiên tách khi ảnh hưởng đã rõ và không thể dời báo cáo khỏi giờ cần dùng. Có thể tách sau nếu còn phải kiểm nguyên nhân; chưa cần khi cách hiện tại đáp ứng cả hai nhu cầu.
• Tách tải cần xét cả lúc lấy dữ liệu, mức độ mới, đối chiếu và vận hành. Data warehouse riêng là một lựa chọn, không phải điều kiện để có phân tích.

Thuật ngữ trong bài

Mẫu tải về: Phiếu xét tách tải (Word). Nội dung giống bảng đã điền ở mục Ví dụ giải sẵn, để trống cho bạn điền.

Bài liên quan: “Hành trình của dữ liệu” giúp phân biệt báo cáo chờ dữ liệu với tính báo cáo chậm. “Chọn kiểu nền tảng dữ liệu” xét lựa chọn nền tảng khi đã rõ nhu cầu. “Đồng bộ và độ trễ” nói về cách lấy dữ liệu và nhịp cập nhật theo giờ cần dùng.