ClickHouse vs Snowflake năm 2026: Phân tích thời gian thực, độ trễ truy vấn & giảm 80% chi phí

Hướng dẫn này cung cấp một so sánh kiến trúc có thẩm quyền giữa ClickHouse và Snowflake vào năm 2026, đặc biệt tập trung vào phân tích thời gian thực, độ trễ truy vấn và hiệu quả chi phí. Chúng tôi sẽ phân tích các triết lý thiết kế cốt lõi của chúng, đặc điểm hiệu suất trên các tập dữ liệu hàng tỷ hàng, chiến lược nén cột và cung cấp một ma trận quyết định cụ thể cho các nhóm kỹ thuật dữ liệu.

Nền tảng Kiến trúc

Hiểu rõ kiến trúc cơ bản của ClickHouse và Snowflake là điều tối quan trọng để đánh giá những điểm mạnh và đánh đổi tương ứng của chúng. Cả hai đều là cơ sở dữ liệu phân tích dạng cột, nhưng mô hình triển khai, quản lý tài nguyên và chiến lược tối ưu hóa của chúng khác nhau đáng kể.

ClickHouse: Cỗ máy hiệu suất tự quản lý, định hướng hiệu suất

ClickHouse là một hệ quản trị cơ sở dữ liệu (DBMS) mã nguồn mở, định hướng cột, được thiết kế cho các khối lượng công việc xử lý phân tích trực tuyến (OLAP). Kiến trúc của nó được tối ưu hóa cho hiệu suất truy vấn cực cao và tốc độ nhập dữ liệu cao, thường đạt độ trễ dưới một giây trên petabyte dữ liệu.

Các nguyên tắc cốt lõi:

1. Lưu trữ dạng cột: Dữ liệu được lưu trữ theo từng cột, cho phép nén và I/O hiệu quả cho các truy vấn phân tích thường chỉ truy cập một tập hợp con các cột.
2. Thực thi truy vấn vector hóa: Các hoạt động được thực hiện trên toàn bộ vector (mảng) dữ liệu thay vì các giá trị riêng lẻ, tận dụng hiệu quả bộ nhớ cache CPU và các lệnh SIMD.
3. Xử lý song song lớn (MPP): Các truy vấn được phân phối trên nhiều nút và xử lý song song. Mỗi nút hoạt động trên các phân đoạn dữ liệu cục bộ của nó, giảm thiểu việc truyền dữ liệu qua mạng.
4. Họ công cụ MergeTree: Họ công cụ lưu trữ chính, được tối ưu hóa cho việc chèn thông lượng cao và hợp nhất dữ liệu hiệu quả trong nền. Nó hỗ trợ các tính năng như khóa chính, phân vùng dữ liệu và chỉ mục thưa.
5. Kiến trúc Shared-Nothing (Điển hình): Mặc dù ClickHouse có thể tích hợp với bộ nhớ dùng chung (ví dụ: S3), hiệu suất tối ưu của nó đạt được với các ổ SSD NVMe cục bộ trên mỗi nút, giảm thiểu độ trễ mạng cho việc truy cập dữ liệu.
6. Tự quản lý: Thường được triển khai trên bare metal, VM hoặc Kubernetes, cho phép các nhà vận hành kiểm soát chi tiết cơ sở hạ tầng, cấu hình và tối ưu hóa.

Mô hình triển khai: Một cụm ClickHouse điển hình trên Kubernetes bao gồm:

• Các nút ClickHouse: StatefulSets chạy các phiên bản máy chủ ClickHouse. Các nút này lưu trữ dữ liệu và thực thi các truy vấn.
• ClickHouse Keeper (hoặc ZooKeeper): Một dịch vụ điều phối phân tán để quản lý siêu dữ liệu cụm, DDL phân tán và sao chép. ClickHouse Keeper là giải pháp thay thế hiện đại, gốc.
• Bộ cân bằng tải: Phân phối các yêu cầu truy vấn đến giữa các nút ClickHouse.
• Ngăn xếp giám sát: Prometheus, Grafana để hiển thị hoạt động.

Snowflake: Kho dữ liệu đám mây gốc, được quản lý

Snowflake là một dịch vụ kho dữ liệu đám mây gốc được xây dựng trên kiến trúc dữ liệu dùng chung đa cụm độc đáo. Nó tách biệt hoàn toàn tính toán khỏi lưu trữ, mang lại khả năng đàn hồi, khả năng mở rộng và dễ quản lý chưa từng có.

Các nguyên tắc cốt lõi:

1. Kiến trúc dữ liệu dùng chung đa cụm:
   • Lớp lưu trữ: Tất cả dữ liệu được lưu trữ trong một dịch vụ lưu trữ tập trung, không phụ thuộc vào đám mây (ví dụ: S3, Azure Blob Storage, GCP Cloud Storage). Lớp này có khả năng mở rộng cao, bền bỉ và được Snowflake quản lý hoàn toàn. Dữ liệu được tổ chức thành các vi phân vùng bất biến.
   • Lớp tính toán (Kho ảo): Các cụm tính toán độc lập (Kho ảo) xử lý các truy vấn. Các kho này được cung cấp theo yêu cầu, có thể được mở rộng lên hoặc xuống và tự động tạm dừng/tiếp tục. Mỗi kho có bộ nhớ cache SSD cục bộ riêng.
   • Lớp dịch vụ đám mây: Điều phối các hoạt động giữa hai lớp còn lại, xử lý xác thực, quản lý siêu dữ liệu, tối ưu hóa truy vấn và quản lý giao dịch.
2. Tách biệt tính toán và lưu trữ: Thiết kế cơ bản này cho phép mở rộng độc lập các tài nguyên tính toán và lưu trữ, loại bỏ tranh chấp tài nguyên và cho phép các tính năng như sao chép không sao chép.
3. Dịch vụ được quản lý: Snowflake xử lý tất cả việc quản lý cơ sở hạ tầng, vá lỗi, nâng cấp và tối ưu hóa, trừu tượng hóa các phức tạp vận hành khỏi người dùng.
4. Lưu trữ dạng cột độc quyền: Dữ liệu trong các vi phân vùng được lưu trữ ở định dạng cột, nén, được tối ưu hóa cho các truy vấn phân tích. Người dùng không có quyền kiểm soát trực tiếp định dạng lưu trữ cơ bản hoặc bộ mã hóa nén.
5. Bộ nhớ đệm: Snowflake sử dụng nhiều lớp bộ nhớ đệm:
   • Bộ nhớ đệm kết quả: Lưu trữ kết quả của các truy vấn trước đó.
   • Bộ nhớ đệm kho: Bộ nhớ cache SSD cục bộ trên Kho ảo cho dữ liệu được truy cập thường xuyên.
   • Bộ nhớ đệm siêu dữ liệu: Để tối ưu hóa truy vấn.

Mô hình triển khai: Snowflake hoạt động hoàn toàn như một Dịch vụ phần mềm (SaaS). Người dùng tương tác với nó thông qua SQL, API hoặc trình kết nối, mà không cần quản lý bất kỳ cơ sở hạ tầng cơ bản nào.

Khả năng phân tích thời gian thực

Định nghĩa "thời gian thực" khác nhau, nhưng trong bối cảnh cơ sở dữ liệu phân tích, nó thường ngụ ý nhập dữ liệu với độ trễ tối thiểu và truy vấn nó trong vòng vài giây hoặc mili giây kể từ khi đến.

ClickHouse cho phân tích thời gian thực

ClickHouse xuất sắc trong các tình huống yêu cầu hiệu suất thời gian thực cực cao.

Nhập dữ liệu: ClickHouse được thiết kế để nhập dữ liệu thông lượng cao. Nó có thể xử lý hàng triệu hàng mỗi giây trên mỗi nút.

• Các câu lệnh INSERT INTO: Chèn trực tiếp được tối ưu hóa cao. Việc chèn theo lô là rất quan trọng để đạt hiệu suất tối ưu.
• Kafka Engine: Công cụ bảng Kafka cho phép ClickHouse tiêu thụ dữ liệu trực tiếp từ các chủ đề Kafka, cung cấp một đường ống nhập dữ liệu mạnh mẽ và độ trễ thấp. Các Chế độ xem Vật lý sau đó có thể xử lý dữ liệu luồng này thành các bảng tổng hợp.
• HTTP API: API linh hoạt để nhập dữ liệu từ nhiều nguồn khác nhau.

Truy vấn: Điểm mạnh chính của ClickHouse nằm ở khả năng thực thi các truy vấn phân tích phức tạp trên các tập dữ liệu khổng lồ với độ trễ dưới một giây. Độ trễ truy vấn P99 dưới 50ms có thể đạt được cho các truy vấn được tối ưu hóa tốt trên các bảng hàng tỷ hàng.

• Thực thi vector hóa: Xử lý dữ liệu theo khối, tối đa hóa việc sử dụng CPU.
• Chỉ mục bỏ qua dữ liệu: Các chỉ mục minmax, set, BloomFilter cho phép ClickHouse bỏ qua các phần lớn dữ liệu không liên quan đến truy vấn, giảm đáng kể I/O.
• Bộ nhớ đệm tích cực: Bộ nhớ đệm trang cấp độ hệ điều hành và bộ nhớ đệm phần dữ liệu riêng của ClickHouse.

Các trường hợp sử dụng:

• Phân tích công nghệ quảng cáo (phân tích luồng đấu giá, theo dõi hiển thị)
• Xử lý dữ liệu cảm biến IoT
• Giám sát mạng và phân tích bảo mật
• Phân tích giao dịch tài chính
• Giám sát hiệu suất ứng dụng (APM)

Snowflake cho phân tích thời gian thực

Snowflake chủ yếu được thiết kế như một kho dữ liệu mạnh mẽ, xuất sắc trong các truy vấn ad-hoc phức tạp và kinh doanh thông minh. Mặc dù nó cung cấp các tính năng để tải dữ liệu liên tục, khả năng "thời gian thực" của nó thường được đo bằng giây đến phút chứ không phải mili giây, đặc biệt đối với các truy vấn "lạnh".

Nhập dữ liệu: Snowflake cung cấp các cơ chế để tải dữ liệu liên tục và theo lô.

• Snowpipe: Một dịch vụ nhập dữ liệu liên tục, không máy chủ, tải dữ liệu từ bộ nhớ đám mây (ví dụ: S3, Azure Blob Storage) ngay khi nó đến. Nó được tối ưu hóa cho các lô nhỏ và độ trễ thấp.
• COPY INTO: Dành cho các tải lô lớn hơn, thường được lên lịch.
• Streams và Tasks: Dành cho việc thu thập dữ liệu thay đổi (CDC) và xử lý dữ liệu liên tục trong Snowflake.

Truy vấn: Snowflake mang lại hiệu suất mạnh mẽ cho các truy vấn phân tích, đặc biệt với các Kho ảo có kích thước phù hợp và đã được "làm nóng". Tuy nhiên, nó đưa ra một yếu tố quan trọng: độ trễ khởi động kho.

• Khởi động kho: Nếu một Kho ảo bị tạm dừng (để tiết kiệm chi phí), truy vấn đầu tiên đối với nó sẽ phải chịu độ trễ khởi động, thường dao động từ 5 đến 30 giây, trước khi quá trình thực thi truy vấn bắt đầu. Điều này khiến việc phân tích thời gian thực ở mức mili giây thực sự trở nên khó khăn đối với các truy vấn "lạnh".
• Bộ nhớ đệm: Bộ nhớ đệm kết quả và bộ nhớ đệm SSD cục bộ của kho tăng tốc đáng kể các truy vấn lặp lại.
• Tự động mở rộng: Các kho có thể tự động mở rộng (thêm nhiều cụm) để xử lý đồng thời, nhưng điều này không làm giảm độ trễ truy vấn riêng lẻ cho một truy vấn phức tạp duy nhất.

Các trường hợp sử dụng:

• Kho dữ liệu truyền thống
• Bảng điều khiển kinh doanh thông minh
• Phân tích hồ dữ liệu
• Chia sẻ và cộng tác dữ liệu
• Đường ống ELT

Độ trễ truy vấn & Hiệu suất

Phần này trực tiếp đề cập đến các yêu cầu độ trễ P99 và sự khác biệt về kiến trúc quyết định hiệu suất.

ClickHouse: P99 dưới 50ms trên hàng tỷ hàng

ClickHouse đạt được hiệu suất cực cao thông qua sự kết hợp giữa các tối ưu hóa cấp thấp và thiết kế kiến trúc.

Các yếu tố chính giúp tăng hiệu suất:

• Truy cập phần cứng trực tiếp: Khi tự lưu trữ, ClickHouse trực tiếp tận dụng phần cứng cơ bản (CPU, RAM, SSD NVMe) mà không có chi phí ảo hóa thường thấy trong các dịch vụ được quản lý.
• Công cụ truy vấn vector hóa: Xử lý dữ liệu theo các khối lớn, giảm thiểu chi phí gọi hàm và tối đa hóa việc sử dụng bộ nhớ cache CPU.
• Lưu trữ và nén dạng cột: Giảm I/O và dung lượng bộ nhớ.
• Chỉ mục thưa: Các chỉ mục minmax, set, BloomFilter cho phép ClickHouse nhanh chóng loại bỏ các phần dữ liệu không chứa dữ liệu liên quan, giảm đáng kể lượng dữ liệu đọc từ đĩa.
• Chế độ xem vật lý: Tổng hợp trước dữ liệu khi nhập, giúp các truy vấn đối với chế độ xem cực kỳ nhanh.

Kịch bản ví dụ: Phân tích sự kiện công nghệ quảng cáo Hãy xem xét một bảng ad_events với hàng tỷ hàng, ghi lại số lần hiển thị quảng cáo, số lần nhấp và chuyển đổi.

CREATE TABLE ad_events (
    event_time DateTime64(3) CODEC(DoubleDelta, ZSTD(1)),
    event_type LowCardinality(String) CODEC(ZSTD(1)),
    ad_id UInt64 CODEC(Delta, ZSTD(1)),
    user_id UUID CODEC(ZSTD(1)),
    campaign_id UInt32 CODEC(Delta, ZSTD(1)),
    country_code LowCardinality(String) CODEC(ZSTD(1)),
    bid_price Decimal64(4) CODEC(Gorilla, ZSTD(1)),
    revenue Decimal66(6) CODEC(Gorilla, ZSTD(1))
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_time, campaign_id, ad_id)
SETTINGS index_granularity = 8192;

-- Query: Calculate total revenue and impressions for top 10 campaigns in the last hour
SELECT
    campaign_id,
    sum(revenue) AS total_revenue,
    countIf(event_type = 'impression') AS impressions
FROM ad_events
WHERE event_time >= now() - INTERVAL 1 HOUR
GROUP BY campaign_id
ORDER BY total_revenue DESC
LIMIT 10;

Hiệu suất dự kiến (ClickHouse): Trên một cụm được cung cấp tốt (ví dụ: 3 nút với 64GB RAM, SSD NVMe, 16 lõi mỗi nút), truy vấn này trên tập dữ liệu hàng tỷ hàng (với các phân vùng liên quan) thường sẽ hoàn thành trong 20-100ms (P99), giả sử dữ liệu của giờ cuối cùng đang "nóng" trong bộ nhớ cache hoặc được đọc hiệu quả từ đĩa do phân vùng và lập chỉ mục tốt.

Snowflake: Độ trễ khởi động kho và bộ nhớ đệm

Hiệu suất của Snowflake phụ thuộc rất nhiều vào trạng thái Kho ảo và cơ chế bộ nhớ đệm của nó.

Các yếu tố hiệu suất chính:

• Kích thước Kho ảo: Các kho lớn hơn cung cấp nhiều tài nguyên tính toán và bộ nhớ cache cục bộ hơn, cải thiện tốc độ truy vấn.
• Trạng thái Kho (Nóng so với Lạnh): Một kho nóng (đang hoạt động) sẽ thực thi các truy vấn nhanh hơn nhiều so với một kho lạnh (bị tạm dừng), kho này sẽ phải chịu độ trễ khởi động.
• Bộ nhớ đệm kết quả: Nếu một truy vấn giống hệt đã được chạy gần đây, Snowflake có thể trả về kết quả từ bộ nhớ đệm kết quả của nó gần như ngay lập tức.
• Bộ nhớ đệm cục bộ của kho: Các khối dữ liệu được kho truy cập thường xuyên được lưu vào bộ nhớ đệm trên SSD cục bộ của nó, giảm I/O từ lớp lưu trữ từ xa.
• Vi phân vùng: Định dạng lưu trữ độc quyền của Snowflake cho phép loại bỏ hiệu quả các khối dữ liệu.

Kịch bản ví dụ: Phân tích sự kiện công nghệ quảng cáo (Tương đương Snowflake)

CREATE TABLE AD_EVENTS (
    EVENT_TIME TIMESTAMP_NTZ,
    EVENT_TYPE VARCHAR,
    AD_ID NUMBER,
    USER_ID VARCHAR,
    CAMPAIGN_ID NUMBER,
    COUNTRY_CODE VARCHAR,
    BID_PRICE DECIMAL(10, 4),
    REVENUE DECIMAL(12, 6)
);

-- Query: Calculate total revenue and impressions for top 10 campaigns in the last hour
SELECT
    CAMPAIGN_ID,
    SUM(REVENUE) AS TOTAL_REVENUE,
    COUNT_IF(EVENT_TYPE = 'impression') AS IMPRESSIONS
FROM AD_EVENTS
WHERE EVENT_TIME >= DATEADD(hour, -1, CURRENT_TIMESTAMP())
GROUP BY CAMPAIGN_ID
ORDER BY TOTAL_REVENUE DESC
LIMIT 10;

Hiệu suất dự kiến (Snowflake):

• Kho lạnh: Truy vấn ban đầu sẽ phải chịu độ trễ khởi động 5-30 giây cho kho, sau đó là thực thi truy vấn. Tổng độ trễ có thể là 10-40 giây.
• Kho nóng (Trung bình/Lớn): Nếu kho đã hoạt động và dữ liệu nằm trong bộ nhớ cache cục bộ của nó, truy vấn có thể hoàn thành trong 1-5 giây. Nếu bộ nhớ đệm kết quả được truy cập, nó sẽ dưới một giây.

Sự khác biệt quan trọng là độ trễ P99 được đảm bảo cho bất kỳ truy vấn nào. ClickHouse, khi được cấu hình đúng cách, có thể liên tục cung cấp P99 dưới 100ms cho các truy vấn phức tạp trên dữ liệu nóng. P99 của Snowflake sẽ cao hơn đáng kể do độ trễ khởi động lạnh vốn có, ngay cả khi thời gian truy vấn trung bình tốt cho các truy vấn nóng.

Bộ mã hóa nén dạng cột

Nén là nền tảng của cơ sở dữ liệu dạng cột, giúp giảm dung lượng lưu trữ và cải thiện hiệu suất truy vấn bằng cách giảm thiểu I/O.

ClickHouse: Kiểm soát chi tiết các bộ mã hóa

ClickHouse cung cấp khả năng kiểm soát rộng rãi các bộ mã hóa nén ở cấp độ cột, cho phép các kỹ sư tinh chỉnh lưu trữ và hiệu suất dựa trên đặc điểm dữ liệu.

Các bộ mã hóa phổ biến:

• LZ4: Mặc định, nén và giải nén nhanh. Lựa chọn tốt cho mục đích chung.
• ZSTD: Tỷ lệ nén cao hơn LZ4, với tốc độ giải nén chậm hơn một chút nhưng vẫn rất nhanh. Cung cấp các mức nén có thể cấu hình (ví dụ: ZSTD(1) cho tốc độ, ZSTD(19) cho nén tối đa).
• Delta: Dành cho dữ liệu số tăng dần hoặc thay đổi chậm (ví dụ: dấu thời gian, ID). Lưu trữ sự khác biệt giữa các giá trị liên tiếp, sau đó nén các delta này bằng một bộ mã hóa khác (ví dụ: Delta, ZSTD).
• DoubleDelta: Tối ưu hóa cho số dấu phẩy động, đặc biệt là dữ liệu chuỗi thời gian nơi các giá trị thay đổi chậm. Lưu trữ sự khác biệt của các sự khác biệt.
• Gorilla: Được thiết kế đặc biệt cho dữ liệu dấu phẩy động chuỗi thời gian, cung cấp tỷ lệ nén tuyệt vời bằng cách mã hóa các khác biệt XOR.
• T64: Dành cho số nguyên, đóng gói các giá trị thành ít bit hơn nếu chúng không sử dụng đủ 64 bit.
• FPC: Nén PFOR nhanh, một thuật toán nén số nguyên khác.

Áp dụng bộ mã hóa: Các bộ mã hóa được chỉ định trực tiếp trong câu lệnh CREATE TABLE:

CREATE TABLE sensor_data (
    timestamp DateTime64(3) CODEC(DoubleDelta, ZSTD(1)),
    device_id UUID CODEC(ZSTD(1)),
    temperature Float32 CODEC(Gorilla, ZSTD(1)),
    humidity Float32 CODEC(Gorilla, ZSTD(1)),
    status LowCardinality(String) CODEC(ZSTD(1))
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (device_id, timestamp);

Khả năng kiểm soát chi tiết này cho phép các kỹ sư đạt được sự cân bằng tối ưu giữa chi phí lưu trữ và hiệu suất truy vấn. Ví dụ, Gorilla và DoubleDelta rất tốt cho các số liệu chuỗi thời gian, trong khi Delta tốt cho các ID tuần tự.

Snowflake: Nén tự động, độc quyền

Snowflake quản lý tất cả các khía cạnh của lưu trữ dữ liệu, bao gồm nén, một cách tự động. Người dùng không có quyền kiểm soát trực tiếp các bộ mã hóa nào được sử dụng hoặc cách dữ liệu được nén.

Đặc điểm chính:

• Tối ưu hóa tự động: Lớp lưu trữ của Snowflake tự động phát hiện các mẫu dữ liệu và áp dụng các thuật toán nén phù hợp nhất (ví dụ: mã hóa độ dài chạy, mã hóa từ điển, mã hóa delta, các bộ mã hóa đa năng khác nhau).
• Độc quyền: Các thuật toán chính xác và cách triển khai của chúng là độc quyền của Snowflake.
• Minh bạch: Sự trừu tượng hóa này đơn giản hóa việc quản lý dữ liệu cho người dùng, nhưng loại bỏ khả năng tinh chỉnh cho các yêu cầu hiệu suất hoặc chi phí cụ thể ở cấp độ cột.
• Tác động: Mặc dù người dùng không kiểm soát nó, việc nén tự động của Snowflake rất hiệu quả, góp phần vào chi phí lưu trữ hiệu quả và hiệu suất truy vấn của nó.

So sánh bộ mã hóa nén

Mô hình chi phí thực tế

Chi phí thường là yếu tố quyết định, đặc biệt khi mở rộng khối lượng công việc phân tích. Phần này cung cấp một so sánh thực tế dựa trên xu hướng giá năm 2026 và các mô hình sử dụng điển hình.

Giả định cho mô hình chi phí:

• Khối lượng dữ liệu: 10TB dữ liệu thô, tăng 1TB/tháng.
• Tải truy vấn: Trung bình đến cao, yêu cầu hiệu suất ổn định.
• Nhập dữ liệu: Thông lượng cao, liên tục.
• Khu vực: US East (Virginia).
• Chi phí vận hành: Bao gồm cho ClickHouse, ngụ ý cho Snowflake.

ClickHouse: Tự lưu trữ trên Kubernetes (AWS EKS)

Mô hình này giả định một cụm ClickHouse cấp sản xuất được triển khai trên AWS EKS, tận dụng các phiên bản EC2 và bộ nhớ EBS.

Cấu hình cụm:

• Các nút dữ liệu: 3 phiên bản r6gd.2xlarge (8 vCPU, 64GB RAM, 950GB NVMe SSD) để lưu trữ dữ liệu và thực thi truy vấn. Các phiên bản này được tối ưu hóa cho khối lượng công việc chuyên sâu về bộ nhớ và lưu trữ cục bộ nhanh.
• Các nút ClickHouse Keeper: 3 phiên bản c6a.large (2 vCPU, 4GB RAM) để điều phối phân tán.
• Lưu trữ EBS: 10TB gp3 để sao lưu và lưu trữ, 3000 IOPS, thông lượng 125 MB/giây. (NVMe cục bộ trên r6gd là bộ nhớ chính).
• Mạng & Bộ cân bằng tải: AWS ALB, mạng EKS.
• Giám sát: Prometheus, Grafana (chạy trên các phiên bản nhỏ riêng biệt hoặc cụm EKS dùng chung).
• Chi phí vận hành: Chi phí ước tính cho thời gian của SRE/Kỹ sư dữ liệu (tương đương bán thời gian) để bảo trì, nâng cấp và khắc phục sự cố.

| Danh mục | Mục | Chi phí hàng tháng (Ước tính) | Ghi chú