Log, event và dữ liệu tracking thường không tăng theo cách tuyến tính. Một website có thể tạo vài nghìn event mỗi ngày khi mới vận hành, nhưng nhanh chóng tăng lên hàng triệu bản ghi khi traffic, số người dùng và số hệ thống cùng mở rộng.

Trong nhiều doanh nghiệp, những dữ liệu này ban đầu được lưu ngay trên server hoặc database của ứng dụng vì cách triển khai đơn giản. Nhưng khi volume tăng, cùng một kiến trúc có thể bắt đầu tạo ra nhiều vấn đề: disk đầy, database phình lớn, truy vấn chậm, backup lâu hơn và chi phí lưu dữ liệu lịch sử ngày càng khó kiểm soát.

Cloudflare R2 tiếp cận bài toán theo hướng khác. Đây là object storage được thiết kế để lưu lượng lớn dữ liệu phi cấu trúc, hỗ trợ các use case như data lake và batch output, đồng thời không tính phí egress bandwidth. Với doanh nghiệp đang lưu log, tracking hoặc event data theo mô hình cũ, LionTech có thể hỗ trợ audit hạ tầng hiện tại và đánh giá phần dữ liệu nào nên chuyển sang object storage để giảm áp lực cho server và database.

Lưu tập trung log, event và tracking data trên R2 để mở rộng storage và phục vụ analytics. 

Xem thêm: Cloudflare R2 cho AI Agent: Lưu trữ file, log, dataset và backup môi trường làm việc

1. Vì sao log, event và tracking data khác dữ liệu giao dịch thông thường?

Không phải dữ liệu nào cũng nên được lưu cùng một cách.

Một database giao dịch thường phù hợp với dữ liệu như:

Đây là các dữ liệu thường xuyên được đọc và cập nhật theo từng record.

Trong khi đó, log và event có đặc điểm khác:

Ví dụ, một website có thể tạo ra:

page_view

search

product_view

add_to_cart

checkout

purchase

api_request

application_error

security_event

Nếu tất cả dữ liệu này cùng đi vào database production, workload phân tích có thể cạnh tranh tài nguyên với chính ứng dụng.

2. Cách lưu truyền thống thường hoạt động như thế nào?

Có hai mô hình phổ biến.

2.1. Lưu log trực tiếp trên server

Ứng dụng ghi dữ liệu vào các file như:

access.log

application.log

error.log

events.log

Ưu điểm là rất đơn giản. Tuy nhiên, khi hệ thống có nhiều server, container hoặc region, dữ liệu bắt đầu bị phân tán.

Một sự cố có thể yêu cầu đội kỹ thuật kiểm tra:

Nếu một server bị xóa hoặc disk gặp vấn đề, log lịch sử cũng có thể mất nếu chưa được chuyển đi nơi khác.

2.2. Lưu toàn bộ event vào database

Một cách khác là tạo bảng:

events

tracking_events

application_logs

Với volume nhỏ, mô hình này có thể hoạt động tốt. Nhưng khi lượng dữ liệu tăng, database phải xử lý đồng thời:

Đây là lúc chi phí và độ phức tạp bắt đầu tăng.

3. Các vấn đề khi lưu log và event trên server truyền thống

3.1. Dung lượng disk bị giới hạn

Server luôn có giới hạn storage.

Nếu log tăng nhanh, đội vận hành phải:

Đây là công việc vận hành liên tục, không trực tiếp tạo ra giá trị từ dữ liệu.

3.2. Dữ liệu bị phân tán

Khi doanh nghiệp có nhiều service, mỗi service có thể lưu log riêng.

Ví dụ:

frontend server

backend API

payment service

authentication service

mobile backend

Việc điều tra một user journey có thể yêu cầu ghép dữ liệu từ nhiều nguồn.

3.3. Server ứng dụng phải gánh thêm workload lưu trữ

Server đáng lẽ nên tập trung vào:

Nếu cùng server phải giữ lượng lớn log lịch sử, storage có thể trở thành một phần của bài toán scale ứng dụng.

4. Vì sao database không phải nơi tối ưu để lưu mọi event?

Database rất mạnh, nhưng không phải lúc nào cũng là lựa chọn tốt cho dữ liệu append-heavy với volume lớn.

4.1. Event table có thể tăng rất nhanh

Giả sử một hệ thống tạo:

Nếu tất cả event nằm trong một bảng database, doanh nghiệp cần quản lý:

4.2. Analytics query có thể ảnh hưởng production

Một query như:

Đếm toàn bộ product_view trong 90 ngày

có thể phải scan lượng dữ liệu rất lớn.

Nếu cùng database đang phục vụ checkout hoặc API production, analytics workload có thể ảnh hưởng ứng dụng.

4.3. Chi phí database thường gắn với tài nguyên xử lý

Lưu thêm dữ liệu trong database không chỉ là thêm dung lượng.

Doanh nghiệp còn có thể phải tăng:

Trong khi rất nhiều log chỉ cần được giữ lại để audit hoặc phân tích sau này.

5. Object storage khác gì server storage và database?

Object storage lưu dữ liệu thành các object độc lập trong bucket.

Một object thường gồm:

Cloudflare R2 là object storage tương thích S3, có strong consistency và được thiết kế cho độ bền dữ liệu cao.

Thay vì:

INSERT từng event vào database

doanh nghiệp có thể:

Gom nhiều event

        ↓

Tạo file JSON hoặc Parquet

        ↓

Lưu thành object trong R2

Đây là mô hình phù hợp hơn với dữ liệu:

6. Bảng so sánh server, database và R2

R2 được Cloudflare định vị cho cả cloud-native applications, large batch outputs và data lake workloads.

7. Vì sao R2 phù hợp hơn cho log và event?

7.1. Storage được tách khỏi application server

Khi lưu log trên R2, việc tăng dữ liệu không yêu cầu mở rộng disk của server ứng dụng.

Kiến trúc chuyển từ:

Application

    ↓

Local disk

sang:

Application

    ↓

Pipeline / Logpush

    ↓

R2

Server và storage có thể scale độc lập.

7.2. Database production không phải giữ toàn bộ lịch sử event

Doanh nghiệp có thể giữ trong database những dữ liệu cần truy cập realtime, còn dữ liệu lịch sử đưa sang R2.

Ví dụ:

Database

R2

Cách này giúp giảm áp lực lưu trữ và analytics lên database chính.

7.3. Phù hợp với dữ liệu append-only

Event thường được tạo một lần và hiếm khi sửa.

Đây là mẫu dữ liệu rất phù hợp với object storage.

Ví dụ:

events/year=2026/month=07/day=04/

Các file mới được thêm theo thời gian mà không cần update từng record cũ.

8. R2 không có nghĩa là ghi từng event thành một object

Một lỗi thiết kế phổ biến là:

1 event = 1 object

Nếu có hàng triệu event, doanh nghiệp sẽ tạo hàng triệu object rất nhỏ.

Mô hình tốt hơn:

Events

   ↓

Buffer

   ↓

Batch

   ↓

Parquet / JSON

   ↓

R2

Cloudflare Pipelines có thể ingest event, transform bằng SQL và ghi dữ liệu vào R2 dưới dạng JSON hoặc Parquet, hoặc Apache Iceberg thông qua R2 Data Catalog.

8.1. Vì sao cần batch?

Batch giúp:

Ví dụ:

Thay vì:

event-1.json

event-2.json

event-3.json

...

Có thể tạo:

events-2026-07-04-08.parquet

chứa hàng nghìn event.

9. JSON hay Parquet phù hợp hơn?

R2 sink của Pipelines hiện hỗ trợ JSON và Parquet.

9.1. JSON

Phù hợp với:

Ưu điểm:

Nhược điểm:

9.2. Parquet

Phù hợp với:

Parquet là columnar format nên phù hợp khi query một số cột trong dataset lớn.

Cloudflare cũng cho phép đưa Logpush qua Pipelines để transform dữ liệu thành Parquet hoặc Apache Iceberg thay vì chỉ lưu raw JSON. Theo Cloudflare, cách này giúp dữ liệu compact hơn và hiệu quả hơn cho analytics.

10. Use case 1: Chuyển application logs khỏi server

Một doanh nghiệp có nhiều backend service.

Mỗi service đang ghi:

application.log

error.log

api.log

Sau vài tháng:

Kiến trúc mới:

Applications

     ↓

Log collection

     ↓

R2

Hoặc:

Cloudflare Logs

     ↓

Logpush

     ↓

R2

Cloudflare Logpush hỗ trợ gửi logs trực tiếp đến R2.

Lợi ích:

11. Use case 2: Chuyển tracking events khỏi database production

Một website thương mại điện tử ghi tất cả event vào bảng:

tracking_events

Ban đầu bảng chỉ có vài triệu records.

Sau một năm:

Kiến trúc mới:

Website / App

       ↓

Pipelines

       ↓

SQL Transform

       ↓

Parquet

       ↓

R2

Database chỉ giữ:

R2 giữ:

Doanh nghiệp tách được operational workload và analytical workload.

12. Use case 3: Lưu Cloudflare logs lâu dài

Cloudflare Logpush có thể gửi request hoặc event logs đến các destination khác nhau.

Một doanh nghiệp có thể lưu:

Pipelines hiện cũng có thể nhận một số Logpush dataset, transform rồi ghi vào R2.

Kiến trúc:

Cloudflare Logs

       ↓

Pipelines

       ↓

Filter / Transform

       ↓

Parquet / Iceberg

       ↓

R2

Điều này phù hợp với:

So sánh server/database truyền thống với R2 về khả năng scale, độ bền, chi phí và lưu trữ dữ liệu dài hạn. 

13. R2 phù hợp với data lake hơn database log table

Cloudflare mô tả R2 là storage phù hợp cho data lakes và big data workloads.

Một data lake có thể chứa:

raw/

clean/

analytics/

archive/

Ví dụ:

raw/http-logs/

raw/app-events/

clean/user-events/

clean/security-events/

analytics/daily-funnel/

Database không biến mất khỏi kiến trúc.

Nó chỉ được dùng đúng vai trò hơn.

Database:

Object storage:

14. R2 Data Catalog mở rộng khả năng phân tích như thế nào?

Khi doanh nghiệp trưởng thành hơn về dữ liệu, các file rời có thể được quản lý dưới dạng Apache Iceberg tables thông qua R2 Data Catalog.

Cloudflare R2 Data Catalog là managed Apache Iceberg catalog được tích hợp vào R2 và có thể kết nối với các engine tương thích như Spark, Snowflake và PyIceberg.

Kiến trúc lúc này:

Logs / Events

      ↓

Pipelines

      ↓

Iceberg Tables

      ↓

R2 Data Catalog

      ↓

Analytics

Điều này giúp R2 chuyển từ nơi lưu file thành nền tảng cho các workload analytics lớn hơn.

Xem thêm: Cloudflare R2 Data Catalog là gì? Ứng dụng Apache Iceberg cho phân tích dữ liệu doanh nghiệp

15. R2 có thật sự rẻ hơn cách lưu truyền thống không?

Không thể kết luận mọi trường hợp đều rẻ hơn nếu chưa audit workload.

Chi phí cần xem gồm:

Tuy nhiên, R2 có một lợi thế rõ ràng là Cloudflare không tính phí egress bandwidth.

Điều này đáng chú ý khi dữ liệu cần được:

Nhưng doanh nghiệp vẫn cần tính toán operations và storage class phù hợp. R2 có các storage class khác nhau, và Infrequent Access có minimum storage duration 30 ngày.

16. Khi nào không nên chuyển toàn bộ dữ liệu sang R2?

R2 không thay thế database cho mọi workload.

Không nên dùng R2 làm nơi chính cho dữ liệu cần:

Ví dụ:

Không nên thay database order bằng object storage.

Nhưng nên cân nhắc đưa:

order_events

order_history

tracking logs

audit trail

sang lớp storage phân tích hoặc lịch sử.

17. Cách chọn nơi lưu cho từng loại dữ liệu

Nguyên tắc đơn giản:

Dữ liệu cần transaction và update thường xuyên → database.

Dữ liệu volume lớn, append-heavy và cần lưu lịch sử → object storage.

18. Checklist audit hạ tầng lưu log và event

18.1. Kiểm tra nguồn dữ liệu

18.2. Kiểm tra nơi lưu hiện tại

18.3. Kiểm tra retention

18.4. Kiểm tra cách sử dụng

18.5. Thiết kế lại storage tier

Có thể chia:

Hot data

Dữ liệu mới, cần truy cập thường xuyên.

Warm data

Dữ liệu dùng cho analytics định kỳ.

Archive data

Dữ liệu giữ vì compliance hoặc lịch sử.

19. Lộ trình chuyển từ lưu truyền thống sang R2

Không nên chuyển mọi thứ cùng lúc.

Giai đoạn 1: Audit

Giai đoạn 2: Tách dữ liệu mới

Bắt đầu gửi event mới vào:

Pipeline → R2

Không cần migrate dữ liệu cũ ngay.

Giai đoạn 3: Chuyển lịch sử

Move:

Giai đoạn 4: Analytics-ready

Chuyển từ raw JSON sang:

Giai đoạn 5: Tối ưu retention

Thiết kế lifecycle và storage class theo giá trị dữ liệu.

20. Kết luận: Log và event cần một lớp lưu trữ khác dữ liệu giao dịch

Server và database không phải lựa chọn sai. Chúng chỉ trở nên không phù hợp khi được dùng để giữ mọi loại dữ liệu.

Log, event và tracking data có đặc điểm riêng: volume lớn, tăng liên tục, chủ yếu append và thường cần lưu lịch sử dài hạn. Khi những dữ liệu này nằm mãi trên server hoặc trong database production, hạ tầng có thể phải chịu thêm chi phí storage, maintenance và analytics workload không cần thiết.

Cloudflare R2 cung cấp một lớp object storage phù hợp hơn cho các dataset lớn, data lake và batch output. Khi kết hợp với Logpush hoặc Pipelines, doanh nghiệp có thể đưa log và event ra khỏi hạ tầng vận hành chính, chuẩn hóa chúng thành JSON, Parquet hoặc Iceberg và xây nền tảng phân tích về sau.

Nếu doanh nghiệp đang gặp tình trạng database phình lớn, server đầy log hoặc chi phí lưu dữ liệu lịch sử ngày càng tăng, LionTech có thể hỗ trợ audit hạ tầng dữ liệu hiện tại, xác định workload phù hợp để chuyển sang R2 và xây dựng lộ trình tối ưu storage theo từng loại dữ liệu.

Liên hệ với LionTech tại: