Một số khái niệm cơ bản về Data Store và những yếu tố lựa chọn đúng loại data store cho ứng dụng

Ngày nay, việc sử dụng đúng loại data stores là một trong những yếu tố quyết định đến sự thành công của việc phân tích, quản trị dữ liệu và xây dựng các ứng dụng. Với hàng trăm loại data stores trên thị trường thì việc lựa chọn này vẫn còn gây ra nhiều khó. Bài viết này sẽ cung cấp bức tranh toàn cảnh về data stores và cách để lựa chọn đúng loại Data Store cho từng trường hợp.

1. Một số khái niệm cơ bản về Data Store

1.1. Data store: 

là nơi để lưu trữ và quản lý dữ liệu nói chung, ngoài việc lưu trữ dữ liệu như database, data store còn được sử dụng để lưu trữ những loại dữ liệu khác như: raw files (text, audio, image, video…), emails, …Trong bài viết này sẽ tập trung vào 3 loại data stores phổ biến là: RDBMS, NoSQL database, và Object Store.

1.2.  Database (cơ sở dữ liệu): 

là tập hợp dữ liệu được quản lý bởi hệ quản trị cơ sở dữ liệu (database management system: dbms). Hiện nay, có 2 loại cơ sở dữ liệu quan hệ phổ biến là: hệ quản trị cơ sở dữ liệu quan hệ, thường gọi tắt là cơ sở dữ liệu quan hệ và NoSQL.

1.3.  Distributed database (cơ sở dữ liệu phân tán): 

là database lưu trữ dữ liệu trên nhiều máy tính, gọi là cluster, mỗi máy tính gọi là node.

1.4.  RDBMS (Cơ sở dữ liệu quan hệ): 

là cơ sở dữ liệu dựa trên các mô hình quan hệ, chúng ta thường gặp là hệ thống chứa các bảng có mối quan hệ 1-1, 1-nhiều và nhiều-nhiều. RDBMS sử dụng ngôn ngữ truy vấn có cấu trúc SQL (Structured Query Language) để truy vấn và update dữ liệu. Hầu hết các phương ngữ SQL (SQL-dialect) tùy vào các hãng sẽ có 1 số thay đổi nhưng tựu chung thường tuân thủ theo chuẩn SQL-92.

1.5.  NoSQL: 

Đây là cái tên từ khi ra đời đã gây ra nhiều nhầm lẫn, nhiều người nghĩ NoSQL là killer của SQL, có NoSQL thì sẽ không còn cần RDBMS lẫn SQL nữa. Tuy nhiên, NoSQL có nghĩa là Not Only SQL, một cách thiết kế cơ sở dữ liệu tập trung vào vấn đề lưu trữ (storage) và truy vấn (retrieval) hơn là thiết kế dạng bảng biểu như RDBMS.

1.6.  Transaction: 

là tập hợp của nhiều hành động (operation) để hoàn thành 1 mục đích, nhưng với quan sát bên ngoài chỉ giống như một hành động duy nhất. Ví dụ, khi chúng ta có 1 transaction chuyển tiền online, khi đó các hệ thống sẽ phải làm một loạt những hành động như: kiểm tra số tiền từ bên gửi có hợp lệ không, kiểm tra tài khoản nhận có tồn tại không, sau đó tiến hành trừ tiền ở bên gửi, và cuối cùng cộng tiền vào bên nhận.

1.7. OLTP vs OLAP:

–        OLTP (Online Transaction Processing): cho phép nhiều người dùng thực hiện đồng thời nhiều transaction. Ví dụ, các trang thương mại điện tử có các chức năng như xem, mua sản phẩm…là dạng OLTP.

–        OLAP (Online Analytical Processing) là hệ thống cho phép phân tích dữ liệu, thường các dữ liệu này được sinh ra từ OLTP. Ví dụ: trong hệ thống thương mại điện tử thì việc thống kê doanh số theo tháng, quý, năm hoặc đo đạc các sản phẩm bán chạy… là dạng OLAP.

1.8.  Data Warehouse: 

là loại hệ quản trị cơ sở dữ liệu thực thi truy vấn và phân tích dữ liệu lịch sử. Thường kết hợp với các Business Intelligence (BI) tool để đưa ra các báo cáo.

1.9.  ACID:

ACID viết tắt của Atomicity, Consistency, Isolation and Durability.

–        Atomicity: Tất cả operation (hành động) trong 1 transaction phải cùng thành công thì transaction đó mới được thực thi, chỉ cần 1 operation lỗi thì cả transaction đó sẽ bị rollback.

–        Consistency: Khi 1 transaction đã thành công và commit thì các truy vấn trong tương lai đến các dữ liệu mà translation đó thay đổi sẽ phải giống nhau. Ví dụ, 1 transaction update cột “salary” trong bảng employee của 1 record về 10M thì tất cả các truy vấn sau này đến record này sẽ trả về là 10M, chứ không có chuyện truy vấn này ra 10M, truy vấn khác ra 9M.

–        Isolation: Đảm bảo nhiều transaction diễn ra đồng thời, nhưng không gây ra sự thiếu nhất quán về dữ liệu trong database.

–        Durability: Khi 1 transaction đã thành công, dữ liệu mà nó thay đổi sẽ được lưu trữ vào trong database.

1.10. CAP Theorem:

CAP theorem nói về việc do Network Partition, distributed database không thể vừa đảm bảo tính Consistency và Availability, chỉ có thể chọn 1 trong 2 thuộc tính này.

• Ví dụ lựa chọn Availability hơn là Consistency

Giả sử ta có 2 service A và service B, dữ liệu được lưu ở key/value store gồm có 3 nodes. Khi service A update giá trị counter từ 6 thành 8, giá trị này được lưu xuống key/value store nhưng do Network Partition thì chỉ có 2 node là update được dữ liệu là 8, còn 1 node là 6. Khi service B đọc giá trị counter, nếu như chấp nhận availability cao hơn consistency thì vẫn cho phép service B đọc giá trị counter = 6.

• Ví dụ lựa chọn Consistency hơn là Availability.

Vẫn như ví dụ trên, nếu coi Consistency cao hơn Availability, thì khi service B đọc counter, hệ thống sẽ không phản hồi lại.

2. So sánh Cơ sở dữ liệu quan hệ (RDBMS) và NoSQL

2.1. Toàn cảnh về RDBMS

Bảng dưới đây sẽ liệt kê các loại cơ sở dữ liệu quan hệ phổ biến nhất hiện nay.

2.2. Toàn cảnh về NoSQL database.

NoSQL database tồn tại từ rất lâu nhưng thực sự phổ biến vào những năm 2000 khi giá ổ cứng giảm mạnh, lượng dữ liệu thu thập lớn hơn rất nhiều và nhu cầu xử lý các định dạng dữ liệu không chỉ ở dạng có cấu trúc mà cả bán cấu trúc và phi cấu trúc. Có 5 loại NoSQL phổ biến: Key-Value, Document, Columnar, Graph và Search. Chúng ta sẽ đi sâu vào từng loại.

2.2.1. Key-Value store.

Lưu trữ dữ liệu dưới cặp khóa key và value, trong đó value có thể có nhiều dạng data types như: integer, string, array.

Các loại Key-Value store phổ biến.

Những ứng dụng nên dùng Key-Value store:

• Insert tần suất cao như web session logs. Lưu session của user đăng nhập vào ứng dụng.
• Những ứng dụng yêu cầu việc ghi data rất nhanh.
• Caching dữ liệu, cho phép query dữ liệu rất nhanh.
•  Những ứng dụng không nên dùng Key-Value store:
• Những ứng dụng yêu cầu truy vấn phức tạp hoặc truy xuất theo kiểu SQL.

2.2.2. Document store.

•  Mỗi dòng (document) dữ liệu trong document store chứa đầy đủ thông tin để định nghĩa dòng dữ liệu đó mà không cần có metadata để mô tả. Dữ liệu có thể ở dạng HTML, XML, JSON.
•  Mỗi document có 1 khóa chính.
• Hỗ trợ ACID nhưng chỉ trong 1 document chứ không phải toàn database.
• Truy xuất dữ liệu thông qua APIs.
• Trường hợp tăng hiệu suất, document store sẽ sharding data chạy trên nhiều node của cluster.
•  Do JSON file rất cồng kềnh nên document store sẽ nén lại thành binary JSON (BSON).

Những ứng dụng nên dùng Document store:

•  Ứng dụng cần schema linh hoạt (schemaless), ví dụ trong thương mại điện tử: mỗi sản phẩm sẽ có thuộc tính khác nhau, sách sẽ khác đồ điện tử…do vậy nên dùng Document store.
•  Ứng dụng yêu cầu truy xuất nhanh, đặc biệt là migrate từ những ứng dụng cũ từ RDBMS lên.

Các loại Document Store phổ biến.

2.2.3. Columnar store.

Columnar store hay còn gọi là Column-oriented sẽ lưu trữ dữ liệu trên đĩa theo dạng cột thay vì dạng hàng như thông thường. Columnar store tăng tốc độ cho truy vấn trong phân tích dữ liệu (data analytic).

Ví dụ, ta có bảng Employee như hình trên với 4 cột là ID, Last Name, First Name, Bonus (số tiền nhận thêm). Các loại cơ sở dữ liệu thông thường sẽ lưu dữ liệu theo kiểu row-oriented, tức là, các hàng dữ liệu lưu theo chiều dọc, hàng với ID = 513001 nằm trên 502333, …mỗi hàng sẽ chứa đủ dữ liệu của 4 cột. Bây giờ, nếu muốn phân tích dữ liệu như tính số tiền bonus trung bình cho các nhân viên. Lúc này, engine sẽ quét qua tất cả các row rồi tính tổng các bonus và chia cho số row. Tưởng tượng, nếu ta có hàng triệu row, thì câu query này sẽ rất tốn kém. Với columnar store, dữ liệu của bảng sẽ được lưu trữ theo dạng cột, tức là các cột của bảng Employee sẽ được dạt phẳng được lưu trữ trên cùng 1 hàng, ví dụ: các ID sẽ nằm ngang trên 1 hàng, Bonus trên 1 hàng, như vậy số lượng row lưu trữ trong column-oriented sẽ bằng số lượng cột của bảng. Lúc này, nếu ta muốn tính số tiền trung bình cần bonus, engine chỉ việc cộng tổng giá trị ở hàng chứa dữ liệu bonus mà thôi.

• Những ứng dụng nên dùng Columnar store:

• Các ứng dụng phân tích muốn filter và aggregate data theo các cột. Ví dụ, phân tích log data.
•  Lưu trữ và phân tích time-serie data.

• Không nên dùng columnar store trong các trường hợp:

• Các ứng dụng OLTP.
• Các ứng dụng cần ACID.
•  Các ứng dụng có số lượng data không qua lớn.

• Các loại Document Store phổ biến.

2.2.4. Graph data store.

Dữ liệu phân cấp (hierarchical data) khá phổ biến trong các ứng dụng hiện nay. Ví dụ, danh sách Employee trong 1 công ty, sẽ có những nhân viên là “sếp” của các nhân viên khác. RDBMS mô hình những dữ liệu dạng này sử dụng khóa ngoại. Với ví dụ trên bảng Employee có các cột ID (khóa chính – PK), Name, Date Of Birth, Gender, ManagerID (FK tới ID). Mỗi lần muốn tìm danh sách các nhân viên cho 1 manager nhất định ta sẽ cần join bảng Employee với chính nó. Trong trường hợp số lượng bản ghi cực lớn và mức phân cấp sâu thì việc join này sẽ rất tốn kém. Graph store được ra đời để lưu trữ những dữ liệu phân cấp phức tạp, giúp việc truy vấn hiệu quả hơn rất nhiều. Dữ liệu được biểu diễn dưới dạng đồ thị với các node, và mối quan hệ giữa các node này là các cạnh, có thể dễ dàng truy vấn từ 1 node này tới node khác thông qua việc đi qua các cạnh nối giữa chúng.

Những ứng dụng nên dùng Graph store:

–        Graph store dùng để lưu trữ những dữ liệu phân cấp, có mối quan hệ chặt chẽ với nhau. Ví dụ như: mạng xã hội.

Những không nên dùng Graph store:

–        Những ứng dụng cần sử dụng SQL JOIN.

       Các loại Graph store phổ biến: 

2.2.5. Search data store.

Search data store cho phép search hiệu quả theo wildcard, grouping dữ liệu và ranking. Search store sử dụng 2 thuật toán tiêu biểu là inverted index và TF-IDF. Inverted index sẽ “băm” các từ trong document thành các index, TF-IDF sẽ xác định độ quan trọng của các từ khóa đó.

Những ứng dụng dùng search store:

–        Cần tìm kiếm hiệu quả, ví dụ như tìm kiếm từ khóa trong thương mại điện tử hoặc bất kể những ứng dụng cần search trên lượng dữ liệu lớn.

Những ứng dụng không nên dùng search store:

–        Đòi hỏi ACID.

Các loại search store phổ biến.

Một số loại Data Stores khác

Trong trường hợp cần lưu trữ các loại raw file, thì HDFS và Object Store là 2 loại data store rất phổ biến.

1. Object store.

Object store được dùng để lưu raw data rất hiệu quả, đơn giản hóa quá trình lưu trữ và truy xuất các loại dữ liệu này.

 Khi nào nên dùng Object store:

–        Khi cần lưu trữ dữ liệu raw, với chi phí thấp.

–        Khi sử dụng những công cụ big data để truy xuất dữ liệu. Hầu hết các công nghệ big data SQL-On-Hadoop như Apache Drill, Hive, Amazon Athena, Impala, Presto đều hỗ trợ truy vấn dữ liệu trên Object store.

Các loại Object store phổ biến. 

2. HDFS

HDFS là core của công nghệ big data Hadoop. Dữ liệu trên HDFS sẽ được replicate (mặc định) thành 3 bản, nên khả năng availability rất tốt. Dữ liệu trên HDFS có thể được xử lý bởi rất nhiều những công cụ phân tích như MapReduce, Apache Spark, Apache Hive, Apache Pig, Apache Impala, …

3. Những yếu tố quyết định để lựa chọn đúng loại data store cho các ứng dụng

3.1. Ứng dụng yêu cầu operational workload hay analytic workload.

Operational workload là thường là các ứng dụng OLTP, yêu cầu database tối ưu việc insert, update, các transaction cần ACID mạnh. Chúng ta có thể dùng RDBMS cho dạng này.

Analytic workload bao gồm những ứng dụng OLAP, yêu cầu database tối ưu cho việc đọc dữ liệu, thực thi những phép toán định lượng như sums, averages, minimums và maximums…Chúng ta nên sử dụng columnar data store cho dạng này.

Ngoài ra, có loại lai giữa hai loại này gọi là “hybrid transactional and analytic processing” (HTAP), ví dụ như những bài toán phát hiện gian lận theo thời gian thực (real-time fraud detection). Chúng ta nên dùng các loại in-memory data store như key-value store.

3.2. Cách thức lưu trữ và truy vấn dữ liệu.

Yếu tố tiếp theo ảnh hưởng đến quyết định lựa chọn data store là cách thức chúng ta lưu trữ và truy vấn dữ liệu.

Trường hợp dữ liệu ở dạng phân cấp hoặc mối quan hệ giữa các data point phức tạp thì sử dụng graph store.

Trường hợp chúng ta chỉ muốn truy xuất dữ liệu dựa trên key, dữ liệu được lưu dưới bất kể dạng gì không cần quan tâm đến data type thì sử dụng key-value store.

Trường hợp dữ liệu có cấu trúc, yêu cầu truy xuất dữ liệu định lượng như sum, average, min, max thì xem xét xử dụng RDBMS.

Trường hợp dữ liệu có nhiều thuộc tính trong schema, hoặc chứa tag như JSON, XML thì sử dụng document store.

Trường hợp lưu raw file với chi phí thấp xem xét sử dụng object store.

3.3. Chi phí và kinh nghiệm

Sau khi đã quyết định được loại data store nào, để quyết định chính xác database cần dùng thì sẽ cân nhắc đến yếu tố chi phí và kinh nghiệm. Chẳng chúng ta quyết định dùng RDBMS, nếu như ngân sách nhiều, có thể lựa chọn những loại database leading market như Oracle, Microsoft SQL Server, nếu như là startup với ngân sách hạn chế ta có thể chọn open-source như Postgre. Ngoài ra, kinh nghiệm thực tế của đội ngũ cũng sẽ ảnh hưởng đến lựa chọn cuối cùng.

Ngày nay, rất nhiều ứng dụng được triển khai theo mô hình microservices, trong đó mỗi service thực thi những vai trò khác nhau và sử dụng data store riêng, do vậy trong 1 ứng dụng chúng ta có thể sử dụng kết hợp nhiều loại data store khác nhau. Hi vọng bài viết này giúp bạn có cái nhìn bao quát về các loại data store và đưa ra các lựa chọn phù hợp.