Hiểu và chọn database trong NoSQL DBMS [Part1] - Các loại NoSQL DBMS
NoSQL
6
Database
33
White

MasBeeju viết ngày 27/07/2019

Chào những người anh em! Trong thời đại công nghệ hiện nay, có rất nhiều hướng để giải quyết một bài toán. Database (chính xác là DBMS - database management system) cũng vậy, càng ngày càng ra những engine mới để đáp ứng nhu cầu của người dùng. DBMS có thể chia thành 2 loại là RDBMS( relational database management system) và NoSQL DBMS. NoSQL sinh sau đẻ muộn nhưng lại vươn lên khá nhanh vì có những tính chất, tính năng mà RDBMS không hỗ trợ. Ở đây có anh em nào tiếp xúc với NoSQL DBMS hằng ngày nhưng lại hơi mơ hồ, chưa có cái nhìn tổng quát lẫn cụ thể về nó không? Có ai đang làm trên những hệ thống dùng MongoDB, Redis, nhưng lại không thực sự hiểu chúng? Có ai đang build up dự án nhưng lại đang phân vân không biết chọn loại database nào ? Để giải quyết những vấn đề ấy thì mình sẽ nói về các loại NoSQL, đi sâu vào tính chất và suy luận ra các trường hợp sử dụng của chúng nha.

Các loại NoSQL DBMS:
• Key-value store
• Document store
• Wide comlumn store
• Graph store

Key-value store

Định nghĩa:

Mô hình dữ liệu đơn giản nhất. Khi mình biết key, thì mô hình này là cách nhanh nhất để lấy value. Mô hình này không có ngôn ngữ truy vấn, nhưng nó vẫn cung cấp cách lưu trữ, truy xuất và cập nhật dữ liệu bằng cách sử dụng các lệnh get, put và delete đơn giản.

Ví dụ:

DBMS: Redis, Amazon DynamoDB , FoundationDB.
Twitter sử dụng Redis để phân phối Twitter timeline(Link)
Pinterest sử dụng Redis để lưu trữ danh sách users, followers, unfollowers và nhiều thứ nữa(Link)
Redis thường xuyên được sử dụng làm Caching database để tăng tốc tốc độ của ứng dụng.

Trường hợp sử dụng:

Chia sẻ dữ liệu giữa các ứng dụng như distributed cache hoặc để lưu trữ dữ liệu user session, user preference và profile, shopping cart và thậm chí là Real-time bidding (Đặt giá thầu).

Giải thích:

Trong thời đại hiện nay, những application xây dựng lên thì hay đi đôi với authentication/authorization, thậm chí là có những hệ thống mà mọi application của nó dùng 1 identity server duy nhất để xác thực, thì việc handle authentication/authorization rất quan trọng. 1 trong những cách đó là session store, anh em nào biết session rồi thì pass qua câu chuyện xạo chúa mà mình sắp kể nhé:

Hệ thống của ta chỉ implement theo kiểu basic authentication :expressionless:, hoặc là chỉ dùng token thôi, thì phía server của mình sướng, chả phải lưu trữ thêm thông tin đăng nhập của user gì cả. Rồi một ngày có 1 cuộc gọi từ 1 khách hàng *hịn của mình:
Khách xịn: -Em ơi có đứa nào nó đang xài tài khoản của anh, out ra giùm anh cái.
Ta: :unamused:Hmm, được không ta... :scream: Sao mà out ra giùm được bà nội, hệ thống mình cho client lưu trữ thông tin đăng nhập hết chứ có giữ thông tin này ở server đâu, chỉ biết đợi phiên đăng nhập hết hạn thôi. :dizzy_face:
Khách xịn: -Sao hả chú, out được chưa?
Ta: -Dạ để em implement thêm đã. Nửa năm sau nhé anh.:sweat_smile:
Khách xịn: -:triumph:
Đấy, khách hàng là thượng đế, ta phải chiều cả những khách hàng khó tính. Nhưng mà kiểu gì thì kiểu, ta cũng phải bảo vệ người dùng của mình chứ! Trở lại vấn đề, nếu không lưu trữ lại gì trên server của mình thì làm sao quản lý chặt được. Vậy ta sẽ lưu trữ session để quản lý mạnh về authentication/authorization. Với lại, tưởng tượng 1 người dùng đang sử dụng nhiều app của 1 hệ thống, rồi từ 1 trong những app đó đăng xuất từ tài khoản 1 và đăng nhập vào tài khoản 2, thì các app khác vẫn đang xài token của tài khoản 1, không đăng xuất cũng không switch qua tài khoản 2, lúc này các app của người dùng không đồng bộ, thống nhất với nhau. Những vấn đề trên đã nói lên việc lưu trữ user session hoặc các thông tin của user( tuỳ cách handle, có thể là token luôn) ở phía server quan trọng như thế nào.

Hết chuyện session. Tiếp theo, biết là việc lưu trữ user session quan trọng rồi đấy, nhưng tại sao chúng ta lại dùng cái thằng Key-value store này chứ?:flushed: =>Đơn giản vì nó đơn giản :D Không cần query phức tạp mà chỉ cần lưu trữ session, lúc cần thì get, update value chỉ cần biết key.
Trường hợp tiếp theo, mô hình này được sử dụng cho shopping cart và Real-time bidding, trong khi hồi xưa đến giờ chúng ta vẫn nghĩ mấy cái liên quan đến tiền bạc này nọ thì chọn RDBMS đi chứ sao lại dùng NoSQL key-value gì?:confused:
No,no. RDBMS rất mạnh về consistency, nhưng khi implement trên hệ thống phân tán thì vẫn là eventually consistency mà thôi, nghĩa là ở 1 nơi thì check request sẽ thấy gói mì tôm với quả cà chua trong giỏ rồi, cứ đinh ninh là sẽ ăn tô mì như bên dưới, nhưng mà nơi khác check thì chỉ thấy mỗi quả cà chua không (quả này mà mua hàng thì về nhà chỉ có ăn cà chua hấp :stuck_out_tongue_winking_eye:)
alt text
Nên mình khẳng định NoSQL vẫn có vị thế khi handle những hệ thống về real-time, nó lại hỗ trợ scale-out rất tốt nên chả có gì chúng ta phải ngại. Anh em đang hỏi mình thằng key-value store này hanle kiểu gì hả? Chứ trong khi đặt thầu quan trọng đến từng khoảnh khắc, không handle tốt thì 1 ông chốt giá thấp lại thắng thầu ông giá cao, hoặc là kết quả thầu khác nhau tại các server trên thế giới chứ chả chơi :joy:
alt text

Bởi vì nếu áp dụng mô hình này thì near real-time, độ trễ lan truyền của các database rất là thấp, nghĩa là cái thời gian mà các database không consistent rất là thấp. Bí quyết của mô hình này là gì? Chính là nằm ở sự đơn giản của nó.
Khi ta cầm một thứ bùi nhùi trong tay (giá trị phức tạp) thì chúng ta sẽ kiểm tra, xử lý, rồi lại truyền tay cho người khác, rồi người đó lại nghi ngờ, phải kiểm tra thứ bùi nhùi đó có kim tiêm HIV không :unamused: Hết cả thời gian! Giờ chúng ta chỉ sử dụng giá trị cực đơn giản cho value, thì các hệ thống có phải xử lý, kiểm tra nhiều không? Không! Nice choose :+1:
Một số db server lại nâng cao tốc độ hơn nữa bằng cách sử dụng ổ SSD hoặc flash storage, kiểu này thì sợ gì nữa các bác :D

Document store

Định nghĩa:

Mô hình dữ liệu để lưu trữ đối tượng tài liệu theo kiểu semi-structured(bán cấu trúc) và metadata(siêu dữ liệu), schema-free nha anh em. Mô hình này cũng là key-value thôi nhưng mà value ở đây là nguyên 1 cái object phức tạp hơn kiểu key-value hồi nãy. Những datase theo mô hình này thì thường dùng JSON format để thể hiện các đối tượng. Nhưng Json thì hỗ trợ type không phong phú bằng Bson, nên anh em để ý thêm vấn đề này nhé. Hiện tại thì mình biết MongoDB và LiteDB hỗ trợ format Bson.

Ví dụ:

DBMS: MongoDB, CouchDB, Elasticsearch, Solr.
SEGA sử dụng MongoDB để xử lý hàng chục triệu tài khoản trong trò chơi.
Chicago sử dụng MongoDB để tạo ra app WindyGrid’, giúp quản lý thành phố một cách thông minh, an toàn hơn(Link)
EO Media Group: Tăng mức độ tương tác trang web với tính năng Search mạnh mẽ (Link)

Trường hợp sử dụng:

Xử lý các đối tượng không có dữ liệu phức tạp, để nhanh chóng tìm kiếm hoặc lọc theo một số thuộc tính đối tượng.

Giải thích:

Mô hình này thì quá thông dụng trong NoSQL DBMS luôn. Vì nó document oriented, mà mỗi document thì không phải phụ thuộc vào bố con thằng nào, và flexible - document này có thể có những thuộc tính này mà document kia có thể không có, không bắt buộc, và cũng không có constraints luôn nên rất dễ thể hiện các object và khi insert update thì cũng chả check fail gì vì chả có ràng buộc gì cả.
Mô hình này cũng thông dụng với anh em rồi, nhưng lưu ý giùm mình dù mô hình này khá tương tự với row based của RDBMS nhưng lại khác biệt rất lớn nha. Trong RDBMS thì dữ liệu ít trùng lặp nhờ vào foreign key nhưng cũng vì đó có rắc rối. Ví dụ cập nhập dữ liệu của một row trong table này, nhưng database phải lock row đó lại, hoặc lock page, thậm chí là lock table( tuỳ theo cơ chế của database hiện tại và độ lớn, độ ảnh hưởng của sự thay đổi này) và lock luôn những data sẽ ảnh hưởng tới. Rồi, việc thay đổi schemas cũng khó khăn hơn so với NoSQL, mà nếu trong context distributed system thì sự thay đổi này sẽ kéo theo 1 đống anh em database thay đổi luôn (nếu chúng cũng xài RDBMS). Tuy nhiên cái gì cũng có mặt lợi và mặt hại của nó, schema-less, flexible nhưng phải kèm theo việc handle tốt. Thả rông thì cũng phải giữ cho săn chắc chứ không thì sệ có ngày đó anh em :smiling_imp:

Wide column store (Big table)

Định nghĩa:

Wide column store, hay còn được gọi là Big table, hay extensible record store, là mô hình dữ liệu để lưu trữ dữ liệu với khả năng chứa rất nhiều column(cột), và column ở đây là dynamic column. Tên column có thể thay đổi nên ta có thể tưởng tượng ra mô hình này như là key-value store 2 chiều. 1 pair có key là id đối tượng và tên column, còn value là thông tin của đối tượng.

Ví dụ:

DBMS: Cassandra, HBase,Microsoft Azure Cosmos DB.
Spotify dùng Cassandra để lưu trữ các user profile và metadata về các nghệ sĩ, bài hát, v.v để cá nhân hóa tốt hơn (Link).
Facebook: Tính năng "bạn bè gần đây" và lập chỉ mục tìm kiếm (Link).

Trường hợp sử dụng:

Làm việc tốt trong các distributed system. Khi ta có quá nhiều dữ liệu, đến mức mà nghĩ đến chuyện phải trải nó trên nhiều máy tính, thì nên xem xét một database kiểu Wide column store.

Giải thích:

Mô hình này cũng có những thứ tương tự Document oriented thôi, cũng schema-free, và vẫn tìm kiếm dựa trên field được, nhưng implement rất khác nhau, anh em có thể xem lại định nghĩa để hiểu rõ nhé.
alt text
Ngoài phân biệt với Document oriented, ta cũng cần tránh nhầm lẫn với column oriented storage của RDBMS. Đó là 1 dạng improve performance của RDBMS, focus theo column, lưu dữ liệu theo column thay vì row, câu query của chúng vẫn giống nhau nhưng truy cập vào đúng phần data mà mình muốn thay vì scan nguyên cả cái row và lấy luôn các data mình không cần trong query rồi sau đó là lọc ra column mình muốn, rất lợi cho việc analysis ha.

Graph store

Định nghĩa:

Mô hình được thiết kế cho dữ liệu có quan hệ được biểu diễn tốt dưới dạng biểu đồ và có các yếu tố được liên kết với nhau, với số lượng quan hệ không xác định giữa chúng.
alt text
Trong hình trên thì ô tròn là Node, còn mấy cái mũi tên là Edge, thông tin trong node là Properties nha.
Node: đại diện cho các thực thể như người, tài khoản,.. Chúng gần tương đương với bản ghi, quan hệ hoặc hàng trong cơ sở dữ liệu quan hệ hoặc document trong document store.
Edge(cạnh): còn được gọi là relationships, là các đường kết nối các node, đại diện cho mối quan hệ giữa chúng. Các edge có thể có hướng hoặc vô hướng. Trong một đồ thị vô hướng, một cạnh từ điểm này đến điểm khác có chung một ý nghĩa. Trong đồ thị có hướng, các cạnh nối hai điểm khác nhau có ý nghĩa khác nhau tùy thuộc vào hướng của chúng. Các cạnh là khái niệm chính trong cơ sở dữ liệu đồ thị, thể hiện sự trừu tượng không được triển khai trực tiếp trong mô hình quan hệ hoặc mô hình lưu trữ tài liệu. Anh em có thể ôn lại kiến thức về đồ thị vô hướng nếu muốn hiểu sâu về mô hình nha.
Properties: là thông tin liên quan đến các node.
Graph model chia ra 2 model nhỏ là: RDF và Labeled Property Graph Models.
Graph DBMS lại có nhiều kiểu như: Social graph, Intent graph, Consumption graph, Interest graph, Mobile graph.

Ví dụ:

DBMS: Neo4j, Titan.
Anh em có biết đến Medium không, chắc thân thuộc lắm nhỉ? Medium sử dụng Neo4j để xây dựng social graph. Nữa là Walmart sử dụng Neo4j để recommend cho khách hàng các khuyến nghị và khuyến mãi sản phẩm được cá nhân hóa, có liên quan.

Trường hợp sử dụng:

Các hệ thống yêu cầu dữ liệu với số lượng lớn các mối quan hệ linh hoạt, yêu cầu cấu trúc có thể mở rộng để thêm dữ liệu mới, yêu cầu truy vấn các mối quan hệ in real-time.

Giải thích:

Labeled Property Graph Models: model này sẽ hợp với các system ít trao đổi hoặc publish data mà chỉ chú trọng đến việc lưu trữ, lưu trữ hiệu quả sẽ cho phép truy vấn nhanh. Các node có ID duy nhất kèm theo một tập hợp key-value pair hoặc properties đặc trưng cho chúng. Và khi chúng ta biết được ID của node thì ta có thể xác định chắc chắn node đó và các giá trị kèm theo- thứ chúng ta cần. Ví dụ về mô hình này:
alt text
Tiếp theo là RDF( hay còn gọi là semantic graph database): model này liên quan nhiều hơn đến trao đổi dữ liệu. Cốt lõi của RDF là khái niệm triple, gồm ba yếu tố đại diện cho hai vertice(đỉnh) được kết nối bởi một edge(cạnh). 3 yếu tố này sẽ mang ý nghĩa: subject-predicate-object (chủ ngữ-vị ngữ- đối tượng). Subject và object là node. Predicate là một edge, đại diện cho mối quan hệ giữa chúng. Node ở đây có thể là literal value(dạng chữ) hoặc URI, khác với mô hình trước là các node và edge đều không có cấu trúc bên trong( chứa 1 tập hợp key-value pair).
alt text
Hơi dài dòng, nhưng anh em chỉ cần nhìn vào hình trên và "hiểu" là ok rồi. Nó đang thể hiện 1 đối tượng Me là một Person có tên Eric Miller, có mail là em@w3.org và có tiltle là Dr.
Mình đã giải thích đại khái về cấu trúc của model này, giờ sẽ sang tính chất nhé.!
Anh em nếu chỉ biết qua về Graph store thì sẽ dễ nhầm lẫn với RDBMS. Graph store được thiết kế cho dữ liệu có quan hệ, nhưng structure của nó với RDBMS khác hẳn nhau. RDBMS thì rất khắt khe, có constraints, và 1 row có thể chứa những foreign key tham chiếu đến các row và table khác, khi query để lấy data của chúng ta phải join tất cả các hàng trong những table đang retrieve data, rất là nặng về tính toán. Vì điểm này nên NoSQL dù sinh sau đẻ muộn nhưng lại được chào đón nhiệt tình vì tính đơn giản, flexible của nó, kèm theo high performance và highly scale-out. Nhưng, lại thiếu sót mất khả năng tạo mối quan hệ, mối liên kết giữa các data. Cuối cùng, mô hình Graph Store đã đáp ứng điều đó, mà vẫn giữ được performance tốt, tốt hơn RDBMS. Tại sao mô hình Graph Store lại có thể truy vấn real-time, nhanh hơn so với RDBMS? Là vì Graph Store lưu trữ mối quan hệ trên từng record riêng biệt. Nó coi mỗi node, mỗi edge có tầm quan trọng như nhau, được kết nối với nhau thành mô hình đơn giản, cho phép ta truy cập trực tiếp vào node mà ta muốn mà không phải thực thi theo kiểu join của RDBMS. Nhưng nói đi thì cũng phải nói lại, RDBMS sẽ tốt về lưu trữ trong trường hợp data có structure tương đối giống nhau, vì những column đã nằm trong table definition rồi, các row thêm vào thì chứa value thôi chứ không chứa thông tin của column nữa, còn Graph thì sẽ lợi hơn trong trường hợp structure giữa các record không cố định, tên column thay đổi.

Hết các loại của NoSQL DBMBS rồi nhỉ?

Ừ nãy nói có 4 loại thôi mà.
Giỡn thôi, còn nhé, ngoài 4 loại phía trên thì còn một vài loại có thể kể đến như Search Engine. Search Engine giờ cũng khá thông dụng, là một loại NoSQL DBMS chuyên dụng để tìm kiếm: tìm kiếm có query phức tạp, full-text search, ranking và gom nhóm kết quả tìm kiếm, geospatial search( vị trí địa lý), thậm chí là tìm kiếm không gian như GeoSeer, có thể kể đến các DBMS nổi tiếng implement nó như Elasticsearch, Splunk, Solr. Search Engine không nằm trong 1 trong 4 loại cơ bản của NoSQL DBMS mà nó nằm độc lập nha!
Hết rồi chứ nhỉ?

Lại giỡn đấy, còn 1 "loại" nữa, nó hơi đặc biệt xíu, thực chất thì không tính là một loại DB đâu, nhưng mình phải nói về nó vì có những lúc chọn DBMS anh em có thể đau đầu vì cùng lúc muốn lợi ích, tính năng của 2 3 mô hình kể trên chẳng hạn, thì anh em có thể lựa chọn một trong những DBMS bên dưới.
Multi-Model:
Amazon DynamoDB: sử dụng 2 mô hình là Document store và Key-value store.
OrientDB: sử dụng 3 mô hình là Document store, Key-value store, Graph store.
Microsoft Azure Cosmos DB: sử dụng cả 4 mô hình trên.

Mình cho cái hình để anh em xem có khớp với kiến thức nãy giờ không nha:
alt text

Kết bài:

Đây là part 1 của series Hiểu và chọn database trong NoSQL DBMS. Mình chỉ chia sẻ những kiến thức hạn hẹp mà mình hiểu, nhưng vẫn hy vọng bài đọc này sẽ giúp ích cho anh em. Nếu có gì bổ sung, góp ý thì anh em comment chỉ giúp mình nhé. Hẹn gặp lại anh em trong Part 2 - CAP theorem- Sự thật và ứng dụng. Chúc anh em một buổi tối tốt lành!

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

MasBeeju

4 bài viết.
63 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
29 1
Hẳn anh em ở đây không xa lạ gì với NoSQL DBMS lẫn thế mạnh của nó. Nhưng liệu chúng ta có thực sự hiểu nó? Trước tiên, ta cùng điểm qua những thế ...
MasBeeju viết 15 ngày trước
29 1
White
9 11
Chào anh em (Link) của Hiểu và chọn database trong NoSQL DBMS mình đã phân tích về các loại NoSQL DBMS, part 2 này mình sẽ đi đến CAP theorem(định ...
MasBeeju viết 1 tháng trước
9 11
White
7 10
Chào anh em web developer Hiện nay để một hệ thống web application có thể thành công, nổi tiếng thì sẽ trải qua rất nhiều gian nan. Hệ thống của c...
MasBeeju viết 23 ngày trước
7 10
Bài viết liên quan
White
0 1
1, Cài đặt MongoDB. Đầu tiên các bạn truy cập vào địa chỉ website https://www.mongodb.com//downloadcenter?jmp=nav Và làm theo hình ảnh dưới đây (l...
Thanh Tài viết 2 năm trước
0 1
White
37 10
Mình biết đến (Link) cách đây khoảng 2 năm, tại thời điểm mà giá bitcoin tăng khủng khiếp ấy. Khi đó không biết mọc ở đâu lắm thầy phán bitcoin qu...
nooptr viết 3 tháng trước
37 10
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
4 bài viết.
63 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!