Lưu trữ dữ liệu: so sánh tệp · cơ sở dữ liệu · blockchain

1. Tổng quan

A. Định nghĩa

Đây là ba phương thức tiêu biểu để lưu trữ·quản lý dữ liệu: tệp là lưu trữ theo đơn vị tệp của hệ điều hành, cơ sở dữ liệu (DBMS) là quản lý tích hợp·tập trung dữ liệu được cấu trúc hóa bằng schema, còn blockchain là sổ cái phân tán (distributed ledger) bất biến (immutable), liên kết các khối thành chuỗi và lưu giữ trên nhiều nút phân tán.

Điểm phân biệt cốt lõi xuyên suốt ba phương thức là 'đặt niềm tin (trust) vào dữ liệu ở đâu'. Với tệp, ứng dụng tự quản lý định dạng·tính nhất quán, nên trách nhiệm về niềm tin hoàn toàn thuộc về ứng dụng. Với cơ sở dữ liệu, máy chủ DBMS trung tâm (và người quản trị vận hành nó) kiểm soát dữ liệu bằng kiểm soát truy cập·giao dịch·ràng buộc để bảo đảm niềm tin. Ngược lại, blockchain khác biệt căn bản ở chỗ tạo ra niềm tin bằng sự đồng thuận (Consensus) của nhiều nút mà không cần người quản trị trung tâm. Không ai có thể một mình giả mạo·sửa đổi bản ghi, và dữ liệu một khi đã được xác lập (finality) trên thực tế không thể đảo ngược.

Sự khác biệt về 'chủ thể tin cậy' này phân tách ba đặc tính là tính toàn vẹn (integrity), hiệu năng (performance) và tính sẵn sàng (availability) theo những cách khác nhau. Giao niềm tin cho ứng dụng thì đơn giản và nhanh nhưng tính nhất quán yếu; giao cho máy chủ trung tâm thì có được tính nhất quán mạnh và hiệu năng được tối ưu nhưng máy chủ đó trở thành điểm tin cậy duy nhất và điểm lỗi duy nhất tiềm ẩn; giao cho sự đồng thuận của nhiều nút thì có được khả năng chống giả mạo·sửa đổi và tính minh bạch nhưng phải trả giá lớn về hiệu năng·chi phí do chi phí của quá trình đồng thuận. Vì vậy, việc dùng phương thức nào luôn quy về câu hỏi yêu cầu "dữ liệu này cần mức độ tin cậy·hiệu năng·minh bạch nào".

B. Bối cảnh ra đời và sự cần thiết

Tính chất của dữ liệu rất đa dạng. Có dữ liệu cấu trúc đơn giản và yêu cầu nhất quán thấp như tệp cấu hình hệ thống hay log máy chủ, có dữ liệu giao dịch không cho phép một chút bất nhất nào như số dư tài khoản ngân hàng·số lượng tồn kho, và cũng có dữ liệu chỉ có giá trị khi 'không ai có thể lén sửa' như bằng cấp·chứng chỉ hay lịch sử chuỗi cung ứng. Ba phương thức cùng tồn tại chính vì sự đa dạng này. Không một kho lưu trữ vạn năng nào có thể đáp ứng tối ưu mọi yêu cầu, nên phải chọn phương thức phù hợp với tính chất dữ liệu thì mới tối ưu đồng thời chi phí·hiệu năng·niềm tin. Vấn đề lựa chọn này vượt ra ngoài so sánh khái niệm đơn thuần, ảnh hưởng trực tiếp đến các quyết định ban đầu của thiết kế kiến trúc hệ thống, nên quan trọng từ góc nhìn của Kỹ sư chuyên nghiệp (Professional Engineer).

Về mặt lịch sử, ba phương thức này cũng lần lượt xuất hiện 'để vượt qua giới hạn của phương thức trước'. Các hệ thống thông tin ban đầu quản lý dữ liệu bằng hệ thống tệp nhưng vấp phải vấn đề trùng lặp·bất nhất·đồng thời (còn gọi là vấn đề phụ thuộc dữ liệu·dư thừa dữ liệu), nên từ thập niên 1970 trở đi chuyển sang DBMS. DBMS giải quyết vấn đề này bằng tích hợp tập trung, nhưng trong môi trường mà nhiều chủ thể khó tin tưởng lẫn nhau (giao dịch đa bên·dịch vụ phi tập trung), vẫn còn lại vấn đề niềm tin mới là 'ai tin vào trung tâm', và sau Bitcoin năm 2009, blockchain nổi lên như một nỗ lực giải quyết vấn đề này bằng phi tập trung dựa trên đồng thuận. Tức là ba phương thức gần với các lựa chọn được tích lũy để đáp ứng các yêu cầu khác nhau về niềm tin·quy mô hơn là các sản phẩm thay thế cho nhau.

2. Cấu trúc của ba phương thức

Ba phương thức lưu trữ khác nhau ngay từ cấu trúc vật lý·logic chứa dữ liệu. Sơ đồ cấu trúc dưới đây cho thấy nơi đặt niềm tin (ứng dụng → máy chủ trung tâm → mạng phân tán) càng sang phải càng phân tán.

flowchart LR
  subgraph FILE["Tệp (ứng dụng quản lý)"]
    A1["Ứng dụng"] --> A2["Hệ thống tệp của OS"]
  end
  subgraph DB["DBMS (tích hợp tập trung)"]
    B1["Nhiều client"] --> B2["Máy chủ DBMS trung tâm"]
    B2 --> B3["Schema có cấu trúc/Chỉ mục"]
  end
  subgraph BC["Blockchain (sổ cái phân tán)"]
    C1["Nút"] --- C2["Nút"]
    C2 --- C3["Nút"]
    C3 --- C1
  end
  FILE --> DB --> BC
  style BC fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Phương thức tệp lưu dữ liệu theo đơn vị tệp, còn định dạng nội dung (CSV·JSON·nhị phân, v.v.) và tính toàn vẹn do ứng dụng đọc·ghi chịu trách nhiệm. Không có tầng trung gian DBMS nên cấu trúc nhẹ và truy cập trực tiếp, nhưng cùng một dữ liệu dễ bị trùng lặp ở nhiều tệp và khi nhiều chương trình cùng sửa đổi thì tính nhất quán dễ bị phá vỡ. Không có cơ chế cưỡng chế quan hệ·ràng buộc giữa các dữ liệu nên quy mô càng lớn thì chi phí quản lý càng tăng vọt. Lịch sử các hệ thống thông tin ban đầu trải qua 'giới hạn của hệ thống tệp' rồi chuyển sang DBMS bắt nguồn từ điểm này.

Cơ sở dữ liệu (DBMS) quản lý tích hợp dữ liệu theo cấu trúc được định nghĩa bằng schema (với mô hình quan hệ là bảng·dòng·cột), và máy chủ trung tâm kiểm soát tập trung giao dịch·điều khiển tương tranh·quyền truy cập·sao lưu. Nó được thiết kế để nhiều ứng dụng chia sẻ cùng dữ liệu mà vẫn loại bỏ trùng lặp (chuẩn hóa) và duy trì tính nhất quán, nên đã trở thành tiêu chuẩn trên thực tế trong hầu hết nghiệp vụ doanh nghiệp coi trọng tính nhất quán. Tuy nhiên, vì toàn bộ niềm tin tập trung vào máy chủ trung tâm này, người quản trị máy chủ có quyền sửa đổi dữ liệu và sự cố máy chủ có thể dẫn ngay đến gián đoạn dịch vụ, nên các biện pháp sẵn sàng như dự phòng·nhân bản là bắt buộc.

Blockchain chứa dữ liệu trong các khối, mỗi khối chứa giá trị băm của khối ngay trước để liên kết thành chuỗi. Sổ cái này được nhiều nút sao chép·lưu giữ giống hệt nhau, và khối mới chỉ được thêm vào khi vượt qua thuật toán đồng thuận (PoW·PoS, v.v.). Nếu sửa nội dung của một khối, giá trị băm của nó thay đổi và toàn bộ liên kết của các khối sau bị phá vỡ; để hợp thức hóa điều này phải chiếm được đa số năng lực tính toán·cổ phần của mạng, nên trên thực tế không thể giả mạo·sửa đổi. Không có người quản trị trung tâm nên chống chịu tốt với sự kiểm soát·kiểm duyệt của một chủ thể cụ thể, nhưng vì mọi nút phải lưu cùng dữ liệu và tham gia đồng thuận nên chi phí lưu trữ·độ trễ xử lý lớn.

3. So sánh chi tiết về tính toàn vẹn·hiệu năng·tính sẵn sàng

Đặt ba phương thức cạnh nhau theo các khía cạnh cấu trúc·chủ thể quản lý·tính toàn vẹn·hiệu năng·tính sẵn sàng, vị trí của mỗi phương thức trở nên rõ ràng. Bảng dưới đây là khung xương của phép so sánh, còn phần văn xuôi bên dưới giải thích 'tại sao lại có sự khác biệt như vậy'.

Sự khác biệt về tính toàn vẹn sinh ra từ việc cơ chế cưỡng chế tính nhất quán nằm ở đâu. Tệp không có cơ chế cưỡng chế nên lỗi của ứng dụng·truy cập đồng thời dẫn thẳng đến bất nhất. DBMS bảo đảm tính nhất quán ở cấp hệ thống bằng ACID (tính nguyên tử·nhất quán·cô lập·bền vững) của giao dịch cùng ràng buộc·điều khiển tương tranh. Ví dụ, trong chuyển khoản, rút tiền và nạp tiền được gộp vào một giao dịch để cưỡng chế 'phản ánh toàn bộ hoặc hủy toàn bộ'. Blockchain cung cấp tính toàn vẹn dưới dạng 'bản ghi một khi đã xác lập thì không thay đổi' nhờ đồng thuận và chuỗi băm, gần với 'khả năng chống giả mạo·sửa đổi về sau', một bản chất khác với tính nhất quán của DBMS.

Sự khác biệt về hiệu năng phân tách ở chi phí tạo ra niềm tin. Tệp đọc·ghi trực tiếp không qua tầng trung gian nên truy cập đơn giản là nhanh nhất. DBMS xử lý nhanh các truy vấn phức tạp ngay cả trên lượng dữ liệu lớn nhờ chỉ mục·tối ưu truy vấn·bộ đệm. Blockchain phải để nhiều nút kiểm chứng·đồng thuận·sao chép mọi giao dịch nên thông lượng thấp. Chênh lệch về số liệu thực tế cũng lớn — DB quan hệ truyền thống và mạng thanh toán thương mại xử lý từ hàng nghìn~hàng chục nghìn giao dịch mỗi giây trở lên, trong khi Bitcoin được biết là khoảng 7 giao dịch mỗi giây, Ethereum ở mức vài chục giao dịch (đang được cải thiện nhờ layer 2·nâng cấp), nên khó dùng nguyên trạng cho xử lý lượng lớn·thời gian thực.

Sự khác biệt về tính sẵn sàng gắn trực tiếp với nơi đặt niềm tin. Với tệp, kho lưu trữ chứa tệp đó chính là điểm lỗi duy nhất. DBMS tuy tập trung nhưng ứng phó sự cố bằng nhân bản (replication)·clustering·dự phòng — dù vậy, sự chuẩn bị này đòi hỏi thiết kế·chi phí bổ sung. Blockchain có nhiều nút giữ cùng một sổ cái nên dù một số nút ngừng hoạt động mạng vẫn tiếp tục vận hành, có tính sẵn sàng cao về mặt cấu trúc. Tức là thiết kế 'loại bỏ điểm tin cậy duy nhất' quay trở lại thành thế mạnh về mặt tính sẵn sàng.

Đặc tính minh bạch·kiểm toán (audit) của ba phương thức cũng khác nhau nhiều. Với tệp, khó truy vết ai đã thay đổi gì khi nào nếu không có cơ chế riêng; DBMS có thể lưu lịch sử thay đổi nếu thiết lập log kiểm toán (audit log), nhưng có hạn chế là chính log đó có thể bị sửa bằng quyền quản trị. Blockchain ghi công khai mọi giao dịch vào sổ cái và được nhiều nút kiểm chứng, nên trên thực tế không thể để một chủ thể cụ thể lén xóa hay thay đổi lịch sử về sau. 'Tính minh bạch có thể kiểm chứng' này trở thành giá trị khác biệt riêng của blockchain trong các tình huống 'phải chia sẻ sự thật ngay cả với đối tác không thể tin tưởng' như giao dịch đa bên·báo cáo pháp quy.

4. Tiêu chí lựa chọn và ví dụ lai

Việc dùng phương thức nào được quyết định bởi yêu cầu dữ liệu. Luồng ra quyết định dưới đây là trình tự đánh giá thường dùng trong thực tiễn.

flowchart TD
  Q1{"Chống giả mạo·niềm tin phi tập trung<br/>có phải là cốt lõi không?"}
  Q1 -- Có --> BC["Blockchain (hoặc lai băm on-chain)"]
  Q1 -- Không --> Q2{"Có cần tính nhất quán·tích hợp·<br/>truy vấn phức tạp không?"}
  Q2 -- Có --> DB["Cơ sở dữ liệu (DBMS)"]
  Q2 -- Không --> FILE["Lưu trữ tệp"]
  style BC fill:#e8f0fe,stroke:#2f6fed

Nếu chống giả mạo·minh bạch·niềm tin phi tập trung là cốt lõi thì blockchain phù hợp, nhưng hiệu năng·chi phí lưu trữ·ứng phó quy định là gánh nặng. Nếu tính nhất quán·tích hợp·truy vấn phức tạp·giao dịch quan trọng thì DBMS là tối ưu, và hầu hết nghiệp vụ doanh nghiệp (kế toán·đơn hàng·tồn kho·quản lý khách hàng) thuộc loại này. Lưu cấu hình đơn giản·log·media dung lượng lớn thì tệp (hoặc object storage) là kinh tế nhất. Các hệ thống thực tế kết hợp cả ba.

Điểm đặc biệt cần thận trọng khi đánh giá lựa chọn là không nhầm lẫn giữa yêu cầu 'cần phi tập trung' và yêu cầu 'dữ liệu quan trọng'. Dù dữ liệu quan trọng đến đâu, nếu chủ thể quản lý dữ liệu đó là một cơ quan tin cậy duy nhất (máy chủ của ngân hàng·cơ quan) thì thường DBMS là đủ; lợi ích của blockchain chỉ phát huy khi 'nhiều bên tham gia khó tin tưởng lẫn nhau' phải chia sẻ một sổ cái chung. Ngược lại, nếu chỉ có một bên tham gia hoặc là nội bộ tổ chức đã có sẵn niềm tin thì blockchain dễ trở thành thiết kế thừa. Nếu bỏ qua sự phân biệt này, người ta sẽ chạy theo độ hot của công nghệ và chọn sai kho lưu trữ.

Xem xét các ví dụ cụ thể về sự kết hợp ba phương thức sẽ giúp hiểu rõ hơn. Thứ nhất, trong truy vết lịch sử chuỗi cung ứng (ví dụ: lịch sử phân phối·thực phẩm), tài liệu·hình ảnh gốc được đặt off-chain (tệp·object storage), chỉ đưa băm kiểm chứng của từng giai đoạn lên blockchain để chứng minh 'ai đã ghi gì khi nào' mà không bị giả mạo. Thứ hai, trong xác minh tính xác thực của văn bản điện tử·chứng nhận (bằng tốt nghiệp·hợp đồng), nội dung văn bản nằm ở DBMS của cơ quan, còn băm (dấu vân tay) của nó được ghi lên blockchain, sau đó đối chiếu bản gốc với băm để phát hiện giả mạo. Thứ ba, log·media của dịch vụ quy mô lớn được lưu ở tệp/object storage, còn siêu dữ liệu·chỉ mục của chúng được quản lý bằng DBMS để bảo đảm hiệu năng tìm kiếm·tổng hợp. Như vậy, phân vai 'bản gốc nặng đặt ở nơi rẻ và nhanh, bằng chứng tin cậy đặt ở nơi không thể giả mạo' là thiết kế thực tế.

5. Chuyên sâu — lai on-chain/off-chain và xu hướng gần đây

Mô hình lai on-chain/off-chain là cách thừa nhận thẳng thắn giới hạn về hiệu năng·lưu trữ của blockchain và chỉ lấy đặc tính tin cậy của nó. Dữ liệu gốc dung lượng lớn (tài liệu·hình ảnh·lượng lớn bản ghi) được lưu off-chain (DBMS·tệp·hệ thống tệp phân tán IPFS, v.v.), và chỉ giá trị băm (dấu vân tay) của dữ liệu đó được đưa lên on-chain. Vì chỉ cần bản gốc thay đổi một chút là băm khác đi, chỉ cần đối chiếu băm on-chain với bản gốc off-chain là có thể kiểm chứng có bị giả mạo·sửa đổi hay không. Cách này tránh được chi phí·độ trễ khi đưa dữ liệu lớn lên blockchain mà vẫn giữ được giá trị cốt lõi là 'khả năng chứng minh'.

Tư duy lai này gần đây cũng thấm vào chính cơ sở dữ liệu. Một số DBMS thương mại·mã nguồn mở tích hợp 'bảng sổ cái không thể thay đổi (ledger/immutable table)' hoặc tính năng kiểm chứng mật mã (chuỗi băm), cố gắng cung cấp một phần đặc tính 'phát hiện giả mạo·sửa đổi' ngay trong DB trung tâm mà không cần blockchain. Điều này nhắm vào nhu cầu trung gian 'không cần đến mức phi tập trung nhưng muốn giữ lại bằng chứng giả mạo·sửa đổi', cho thấy ranh giới của các phương thức lưu trữ không cố định mà đang tiến hóa, hấp thu ưu điểm của nhau theo yêu cầu.

Các xu hướng gần đây đáng chú ý từ góc nhìn của Kỹ sư chuyên nghiệp như sau. Thứ nhất, mở rộng hiệu năng (layer 2) — hệ sinh thái Ethereum đang nâng thông lượng bằng các layer 2 như rollup (Optimistic·ZK-Rollup), xử lý nhiều giao dịch off-chain và chỉ ghi bản tóm tắt lên on-chain. Thứ hai, blockchain có cấp phép cho doanh nghiệp — các chuỗi riêng tư/liên minh như Hyperledger Fabric giới hạn nút tham gia để giảm chi phí đồng thuận và đáp ứng yêu cầu quy định·quyền riêng tư. Thứ ba, xung đột với quy định dữ liệu — tính bất biến của blockchain xung đột với 'quyền được lãng quên (quyền xóa)' trong luật bảo vệ dữ liệu cá nhân, nên thiết kế tuyệt đối không đưa nguyên văn dữ liệu cá nhân lên on-chain mà chỉ giữ băm·tham chiếu đã trở thành khuyến nghị tiêu chuẩn trên thực tế. Thứ tư, lưu trữ đa dạng (Polyglot Persistence) — cách tiếp cận chia dùng DB quan hệ·NoSQL·tệp·blockchain theo tính chất dữ liệu ngay trong một hệ thống đang trở nên phổ biến. (Thông lượng·số liệu tiêu chuẩn mới nhất của từng dự án thay đổi nhanh, nên khi thiết kế thực tế nên xác nhận bằng tài liệu chính thức mới nhất của từng nền tảng.)

6. Lưu ý và hàm ý

Từ góc nhìn của Kỹ sư chuyên nghiệp, việc so sánh ba phương thức lưu trữ phải được hiểu không phải là 'bản thân công nghệ' mà là vấn đề thiết kế 'sự cân bằng giữa niềm tin·hiệu năng·chi phí phù hợp với yêu cầu'.

1. Blockchain không phải là vạn năng. Nó chỉ có giá trị khi thực sự cần chống giả mạo·minh bạch·niềm tin phi tập trung (truy vết chuỗi cung ứng, chứng nhận, lịch sử giao dịch đa bên). Nếu dùng blockchain cho dữ liệu nghiệp vụ thông thường không cần những điều đó, nó sẽ trở thành phương án kém hơn DBMS, chỉ đem lại suy giảm hiệu năng·chi phí lưu trữ·độ phức tạp vận hành. Đánh giá tỉnh táo trước 'có cần blockchain không' là điểm khởi đầu của thiết kế.

2. Lai là giải pháp thực tế. Sự thỏa hiệp đặt bản gốc dung lượng lớn ở off-chain (DBMS·tệp) và chỉ đặt băm kiểm chứng ở on-chain là chuẩn mực trên thực tế, nắm được đồng thời hiệu năng·chi phí và niềm tin. Thay vì khăng khăng lưu trữ thuần on-chain, cảm quan thiết kế tối thiểu hóa 'cái gì sẽ được đưa lên on-chain' là quan trọng.

3. Phải lấy thiết kế dựa trên đặc tính dữ liệu (polyglot) làm nguyên tắc. Ngay trong một hệ thống, chia dùng tệp·DB·blockchain theo loại dữ liệu để chỉ lấy ưu điểm và tránh nhược điểm của từng phương thức. Khi đó, quản trị dữ liệu phân loại tính nhất quán·vòng đời·mẫu truy cập·yêu cầu quy định của dữ liệu phải được thực hiện trước.

4. Phải coi quy định·tuân thủ là yêu cầu hạng nhất khi lựa chọn phương thức lưu trữ. Đặc biệt, tính bất biến của blockchain xung đột với quyền xóa dữ liệu cá nhân, nên nguyên tắc loại thông tin định danh cá nhân khỏi on-chain và chỉ giữ băm·tham chiếu phải được xác lập ngay ở giai đoạn kiến trúc. Các quy định bảo vệ dữ liệu cá nhân trong và ngoài Hàn Quốc cùng yêu cầu giám sát tài chính là những ràng buộc mạnh chi phối việc chọn kho lưu trữ.

5. Phải xem xét cả tổng chi phí sở hữu (TCO) và mức độ trưởng thành vận hành. Blockchain·hệ thống phân tán có chi phí phát triển·vận hành·tuyển dụng nhân lực cao, và mức độ trưởng thành công nghệ·tiêu chuẩn vẫn còn biến động. Thay vì triển khai chỉ vì độ hot của công nghệ mới, cần đánh giá đánh đổi cân nhắc đồng thời năng lực vận hành của tổ chức và chi phí bảo trì dài hạn.

Tài liệu tham khảo

• AWS, "Khái niệm lưu trữ tệp·khối·đối tượng và cơ sở dữ liệu" — https://aws.amazon.com/products/storage/
• Hyperledger Foundation, "Hyperledger Fabric Documentation" — https://hyperledger-fabric.readthedocs.io/
• Ethereum, "Scaling / Layer 2" — https://ethereum.org/en/developers/docs/scaling/

Tóm tắt một câu: Tệp (ứng dụng quản lý·đơn giản·nhanh), DBMS (tích hợp tập trung·ACID·tối ưu hóa) và blockchain (sổ cái phân tán·bất biến·phi tập trung) phân tách về tính toàn vẹn·hiệu năng·tính sẵn sàng tùy theo 'đặt niềm tin ở đâu'; tích hợp·nhất quán·truy vấn phức tạp phù hợp với DBMS, chống giả mạo·minh bạch·niềm tin phi tập trung phù hợp với blockchain, nhưng trong thực tế người ta thỏa hiệp bằng mô hình lai băm on-chain + bản gốc off-chain và lưu trữ polyglot theo đặc tính dữ liệu.