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
| STT | RDBMS | NoSQL |
| 1. | ACID: hỗ trợ ACID như là 1 trong những đặc tính cơ bản. | ACID: hỗ trợ rất hạn chế. |
| 2. | Schema: Cần phải chỉ định schema ngay trong quá trình tạo table, mỗi khi insert/update dữ liệu cần phải đảm bảo đúng kiểu dữ liệu và các constraint của bảng. Quá trình này còn gọi là schema-on-write. | Không cần chỉ định schema trước. Khi truy vấn đến dữ liệu mới cần quan tâm kiểu dữ liệu. Quá trình này gọi là schema-on-read. |
| 3. | Làm việc tốt với dữ liệu có cấu trúc (structured data). | Có thể làm việc với dữ liệu có cấu trúc (structure data), bán cấu trúc (semi-structured data), và phi cấu trúc (unstructured data). |
| 4. | Thông thường các hệ thống OLTP được thiết kế chạy trên 1 server. Muốn tăng tải thì thường cần scale-up tức là cắm thêm RAM, CPU vào server đó. | Scale theo kiểu scale-out, tức là chúng ta gắn thêm node (server) vào cluster khi muốn mở rộng khả năng chịu tải. |
| 5. | Data access: Thường dùng SQL hoặc ODBC hoặc native APIs. | Data access: hầu hết dùng APIs, tuy nhiên xu hướng gần đây các NoSQL bắt đầu hỗ trợ truy vấn dữ liệu qua SQL. |
| 6. | Query pattern: thường sử dụng các câu SQL phức tạp, JOIN nhiều bảng với nhau. | Hầu hết không hỗ trợ JOIN. |
| 7. | Performance: thường cải tiến tốc độ xử lý bằng cách partition hoặc dùng index. | Cải tiến tốc độ xử lý bằng việc dùng index hoặc sharding. |
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.
| STT | Vendor | Mô tả |
| 1 | Oracle | Oracle dẫn đầu thị trường trong mảng RDBMS. Họ cũng sở hữu và cung cấp opensource cho MySQL. Từ phiên bản Oracle 12c có hỗ trợ columnar store(*) và JSON data type. |
| 1 | Microsoft | Microsoft SQL Server cùng với Oracle dẫn đầu thị trường. Từ SQL Server 2016 cũng hỗ trợ columnar data store và JSON data type. Microsoft Azure SQL cung cấp SQL Server trên nền cloud. |
| 3. | Teradata | Chú trọng hỗ trợ ứng dụng Datawarehouse. |
| 4. | Amazon | – Amazon Aurora là relational database tương thích với MySQL
– Amazon Relational Database Service (RDS) là dịch vụ web cho phép người dùng sử dụng các leading RDBMS như: Oracle, Microsoft SQL Server, PostgreSQL, Amazon Aurora, MariaDB. Amazon RDS cung cấp khả năng scale database và tự động quản trị các hệ thống database. – Redshift được sử dụng cho các hệ thống data warehouse cực lớn lên tới petabytes dữ liệu. |
| 5. | IBM | – DB2 của IBM có thể chạy trên nền Windows, Linux cũng như mainframe.
– DashDB chạy trên nền cloud sử dụng core của DB2 – Netezza Analytics hỗ trợ datawarehouse. Được build trên nền của PostgreSQL.
|
| 6. | Google Cloud SQL cung cấp các loại database như: MySQL, PostgreSQL, SQL Server | |
| 7. | PostgreSQL | Đây là loại RDBMS open-source phổ biến nhất, nó hỗ trợ cả việc lưu trữ JSON document và key-value data type. |
| 8. | MemSQL | MemSQL kết hợp lưu trữ dữ liệu trên cả ổ đĩa và đặc biệt là RAM. Đây được coi là loại In-Memory RDBMS phổ biến cho phép truy cập và xử lý dữ liệu near-real-time |
| 9. | VoltDB | Là loại in-memory RDBMS cho phép scale theo cluster. |
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.
| STT | Vendor/Products | Features |
| 1. | Redis | – Redis là loại key-value được dùng rộng rãi nhất hiện nay. Redis hỗ trợ cả document và time-series.
– Redis lưu trữ dữ liệu chủ yếu trên memory, nhưng cũng có lựa chọn lưu trữ trên ổ đĩa để tăng độ availability. – Redis có cả bản trả phí và open-source. – Có thể cài Redis on-premise hoặc dùng cloud. |
| 2. | Riak | – Riak là loại key-value hỗ trợ high available và fault tolerance tốt nhất. Với các ứng dụng cần down-time cực thấp thì Riak là lựa chọn hàng đầu. |
| 3. | Memcached | – Memcached một thời dẫn đầu lĩnh vực key-value. Tuy nhiên nó phù hợp với những ứng dụng nhỏ hơn và data tĩnh khi so với Redis.
– Memcached theo kiến trúc multithread thay vì single thread như Redis |
| 4. | Hazelcast | – Hazelcast được thiết kế để import lượng lớn dữ liệu.
– Hazelcast có cả bản open-source và bản thương mại on-premise và cloud. |
| 5. | Aerospike | Aerospike lưu index và dữ liệu trên memory hoặc trên SSD |
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.
| STT | Vendor/Products | Features |
| 1. | MongoDB | – MongoDB là loại NOSQL phổ biến nhất.
– Cung cấp khả năng sharding rất mạnh. – Dễ sử dụng. |
| 2. | Amazon DynamoDB | – Một trong những loại Cloud database phổ biến nhất.
– Hỗ trợ không chỉ Document store mà cả key-value và graph (plug-in với TitanDB). |
| 3. | Apache CouchDB | – CouchDB là dạng open-source.
– Hiệu năng hoạt động cao. Nhiều tổ chức lớn chuyển sang dùng CouchDB do tính ổn định và dễ mở rộng. |
| 4. | Couchbase | – Couchbase được phát triển bởi cùng đội ngũ Apache CouchDB, Couchbase có cả bản open-source lẫn thương mại
– Couchbase hợp tác với memcached, nên hỗ trợ đồng thời việc truy vấn rất nhanh dựa trên caching ở RAM và lưu trữ trên ổ đĩa. – Rất nhiều tổ chức lớn dùng bản thương mại của Couchbase |
| 5. | IBM Cloudant | – Sử dụng cùng core với Apache CouchDB.
– Được host bởi IBM với SLA lên tới 99.99%. |
| 6. | MarkLogic | – Ban đầu MarkLogic là dạng XML database, nhưng giờ nó hỗ trợ cả document store lẫn search store. |
| 7. | Microsoft Azure DocumentDB | – Tương thích với MongoDB, do đó chúng ta có thể viết ứng dụng dùng MongoDB sau đó migrate lên Azure cloud. |
| 8. | Google Cloud Datastore | – Google Cloud Datastore cung cấp dịch vụ tự động sharding và replication. |
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.
| STT | Vendor/Products | Features |
| 1. | Apache Cassandra | – Cassandra có cả bản open-source và trả phí trên DataStax
– Ban đầu được Facebook phát triển dựa trên Amazon DynamoDB và Google Bigtable – Truy cập dữ liệu qua SQL-like Cassandra Query Language (CQL). – Hỗ trợ cả key-value store và graph store. |
| 2. | Apache Hbase | – Open-source dựa trên Google Bigtable.
– Tương tác chặt chẽ với Hadoop ecosystem. – Truy xuất dữ liệu qua Java, Thrift và RESTful APIs |
| 3. | Apache Accumulo | – Lưu trữ dữ liệu trên HDFS
– Hỗ trợ fine-grained access. |
| 4. | Amazon Redshift | – Lưu trữ và xử lý lượng lớn dataset cho mục đích phân tích dữ liệu. |
| 5. | Snowflake | – Cloud-base dùng để xây dựng data warehouse, data lake. |
| 6. | SAP HANA | – Đây là loại columnar store lưu trữ dữ liệu trên RAM. Do vậy phù hợp với những phân tích dữ liệu thời gian thực (real-time analysis). |
| 7. | CockroachDB | – Hỗ trợ cả row-oriented và column-oriented |
| 8. | MariaDB ColumnStore | – Đây là columnar storage engine của MariaDB, được thiết kế cho phân tích dữ liệu lớ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:
| STT | Vendor/Products | Features |
| 1. | Neo4j | – Đây là loại graph store phổ biến nhất.
– Từng được sử dụng để tìm những mối liên hệ giữa các thực thể trong vụ scandal “hồ sơ Panama” |
| 2. | OrientDB | – Open source
– OrientDB là dạng lai giữa document và graph |
| 3. | TitanDB | – Ban đầu TitanDB là mã mở, sau đó bị mua bởi DataStax và tích hợp vào trong DataStax Enterprise
– Đội ngũ đứng sau TitanDB chuyển qua phát triển graph store mới là JanusGraph |
| 4. | JanusGraph | – Phát triển bởi team từng phát triển TitanDB
– Open source – Có thể truy xuất dữ liệu qua REST API hoặc High-performance Native API |
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.
| STT | Vendor/Products | Features |
| 1. | ElasticSearch | – Open source dựa trên Apache Lucene Core. Apache Lucene được phát triển bởi Doug Cutting, cha đẻ của Hadoop.
– ElasticSearch hiện được phát triển chính bởi công ty Elastic. Elastic cung cấp bản thương mại với các tính năng cao cấp như: security, monitoring, visualization và graph – Ngoài ra, Elastic cũng kết hợp ElasticSearch vào stack công nghệ rất phổ biến là ELK, bao gồm LogStash và Kibana. |
| 2. | Apache Solr | – Cũng là open source dựa trên core là Apache Lucene. Apache Solr có kết hợp chặt chẽ với Hadoop ecosystem. |
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.
- 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.
| STT | Vendor/Products | Features |
| 1. | Amazon S3 (Simple Storage Service) | – Đây là loại Object store phổ biến nhất. 1 trong những dịch vụ nổi bật nhất của AWS.
– Hỗ trợ durability lên tới 11 9’s và availability là 4 9’s. – Với “cold data”, những data không cần truy xuất thường xuyên có thể dùng dịch vụ Glacier với chi phí vô cùng thấp. |
| 2. | Microsoft Azure Blob Storage | – Có thể truy xuất dữ liệu trên Azure Storage thông qua REST API, hỗ trợ hầu hết các loại ngôn ngữ lập trình.
– Dữ liệu trên Azure Storage có thể được dùng trên những ứng dụng như Azure Data lake Store |
| 3. | Google Cloud Storage | – Truy xuất qua RESTful webservice. Dữ liệu sẽ là read-only
– Google storage lưu trữ dữ liệu dưới dạng JSON hoặc CSV format. Truy vấn theo kiểu SQL, nhưng data trả về theo dạng JSON. |
- 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.
| Bài viết độc quyền của chuyên gia FPT IS
Tác giả Nguyễn Việt Cường – Phó Giám đốc Trung tâm Giáo dục trực tuyến VioEdu |
