Hiểu và chọn database trong NoSQL DBMS [Part2] - CAP theorem - sự thật và ứng dụng
CAP theorem
1
Database
33
NoSQL
6
White

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

Chào anh em! Part 1 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 lý CAP) - định lý mà người ta hay nhắc tới khi nói về NoSQL DBMS.
Sự thật là định lý CAP gắn liền với các distributed system (hệ thống phân tán), distributed data store(lưu trữ dữ liệu phân tán).
:flushed: Ủa mình hay nghe NoSQL DBMS gắn liền với định lý này mà, liên quan gì đến distributed system ở đây?
Lý do là: NoSQL DBMS xây dựng theo chiều ngang, nghĩa là database sẽ chứa các replica và bản thân database cũng dàn trải ra nhiều mảnh (horizontal partition), tương tự như distributed system. Mình sẽ có một bài nói về cấu trúc của NoSQL DBMS để anh em hiểu rõ hơn. Quay trở lại bài này, trước tiên, anh em nên biết 1 xíu về replication cũng như distributed system ở đây để dễ dàng hiểu được phần mình sắp nói nha!
alt text

3 guarantee

Consistency

Còn có thể coi là linearizability.
Là trạng thái mà mọi data trên các node đều đồng nhất với nhau. Mỗi node ở đây anh em hiểu là 1 slave nhé. Ví dụ như hình dưới.
alt text
Ở một thời điểm, trận bóng đá giữa Germany và Argentina đã kết thúc với tỉ số 1-0 nghiêng về Germany. Khi này Referee thực hiện một câu lệnh insert kết quả trận bóng này vào databse. Sau khi đã insert thành công vào Master thì các slave cũng thay đổi theo. Nhưng các slave không phải cập nhật thành công tại một thời điểm mà sẽ chênh nhau một thời gian. Việc này tuỳ vào latency của network, bandwith của network và data transfer, số lượng message trên queue, hoặc số lượng thread, lẫn các cấu hình khác của các slave.
Dẫn đến tại một thời điểm Slave 1 đã cập nhật được data rồi, nhưng Slave 2 thì chưa. Vô tình Alice và Bob request đến 2 slave này và nhận được kết quả khác nhau. Hậu quả thì tuỳ hệ thống và business, trong trường hợp này sẽ không nghiêm trọng lắm, delay một chút cũng không sao. Trước mình coi trực tiếp bóng đá trong phòng, Công Phượng mới rê bóng lên giữa sân mà đã nghe tiếng hò reo hú hú từ quán nhậu vọng vào mới đau kìa, chênh 30s chứ chả chơi (quả này đi ngủ chứ bóng banh gì nữa :unamused:).
Nhưng, thử tưởng tượng 1 trường hợp thú vị xíu:
Alice và Bob là bạn của nhau :laughing: thì Alice sẽ thông báo ngay cho Bod là "Germany thắng rồi ku ơi", Bob kiểm tra (lúc này balancer điều hướng request vào Slave 2- bấy giờ chưa có data mới) thì thấy trận đấu chưa kết thúc vì server sẽ nói là chưa có final score. 2 anh bạn này sẽ có thắc mắc ngay! Nếu bạn là Bob thì sẽ làm gì? Lặng lẽ check lại thêm lần nữa và thấy đúng là Germany thắng thật, rồi kết luận "Chắc nãy mạng của mình bị gì đấy!:confused:" (cũng may là Bob nghĩ do mạng, chứ nói do hệ thống của mình thì méo mồm:anger:)

Ta có: Tại thời điểm mà 2 database đưa ra 2 kết quả khác nhau, không đồng nhất với nhau thì hệ thống không thoả mãn tính consistency (C) trong định lý CAP.

Availability

Mỗi client đều nhận được phản hồi, bất kể có một số node nào đó trong hệ thống có vấn đề.
Ví dụ như hệ thống mình có 3 replica mà 1 replica có vấn đề thì khi 1 client gửi request tới server thì vẫn có phản hồi , vì vẫn còn các replica database khác handle cho mình. Đây cũng là một trong những mục tiêu, lợi ích lớn nhất của replication.

Partition tolerance

Hệ thống vẫn tiếp tục hoạt động (read/ write), ngay cả khi một số node trong hệ thống có vấn đề.
Ví dụ như hệ thống mình có 3 replica. Có 1 replica bị lỗi đường truyền network, không thể giao tiếp với replica khác, nhưng nó vẫn có thể read/write bình thường và các replica còn lại cũng vậy. Còn trường hợp node này có lỗi, có thể là database server bị sập hoặc đang reset, bị vấn đề về hardware, bug của application, dính virus hay có thể hết dung lượng disk thì node này ngừng hoạt động, nhưng các node khác vẫn hoạt động và toàn bộ hệ thống cũng vẫn hoạt động.

Chỉ sở hữu 2 trên 3 guarantee

Hẳn là anh em cũng biết là với nguyên lý CAP theorem mình chỉ có được 2 trên 3 tính chất. Nhưng không có cách nào có cả 3 hả? Để xem!

  • Đầu tiên giả sử ta chọn P đi. Vậy là hệ thống của ta có nhiều node, khi một node không giao tiếp được thì node khác vẫn xài được nên hệ thống vẫn hoạt động được.
  • Tiếp theo chọn A đi! OK, khi một node có vấn đề, thì hệ thống mình vẫn response data cho client được mà, đúng chứ? Vậy giờ ta có AP.
  • Tiếp, muốn có C! Khi một node có vấn đề như không giao tiếp được với các node khác, nhưng vẫn hoạt động read/write bình thường, thì data giữa các node không consistent. Làm sao mà consistent được khi mà không giao tiếp với nhau được chứ, có truyền nhận data mới của nhau đâu! Vậy là ta không có được CAP.
  • Trở lại, ta có C, tiếp theo ta chọn A hoặc P:
    • Chọn P: khi một node không giao tiếp được với node khác, nhưng ta vẫn muốn data trên tất cả các node consistent để thoả mãn C thì chỉ có cách là tạm ngưng read/write trên toàn hệ thống thôi. Chứ giờ mà ghi data mới vào thì sẽ không consistent ngay! Vậy ta có được CP, nhưng nếu làm vậy thì hệ thống sẽ không available (A). Vậy ta chỉ có CP.
    • Còn nếu vẫn muốn C thì hệ thống của chúng ta chỉ có 1 node thôi. Lúc này tính availablity (A) sẽ thể hiện! Nhưng lúc này, hệ thống của chúng ta chỉ có 1 node, lại không thoả mãn P. Vậy ta chỉ có CA.

Vậy là ta không thể có thoả mãn cả 3 tính chất của CAP theorem trên 1 hệ thống. Trừ khi CAP theorem thay đổi, hoặc ta hiểu CAP theorem theo một cách khác :laughing:.

Discuss về CAP theorem

1. Consistency

a) So sánh với Consistentcy trong ACID properties

Consistency trong CAP theorem có giống consistency trong ACID properties không? Không, hoàn toàn không. Trong CAP theorem thì mọi node phải đảm bảo data consistent, còn trong ACID properties thì khi một transaction hoàn thành, data trong hệ thống phải nhất quán so với trạng thái trước khi transaction này thực thi, giữ được tính chính xác.

b) Consistency trong CAP theorem có phải là 100% thời gian, lúc nào các node cũng phải consistent không?

Không, thay vào đó, ta ngầm hiểu là Eventual consistency.
Anh em có thể kiểm tra lại, CAP theorem không có một từ nào nói về độ trễ.
Cũng vì vậy, các CAP-availibility system có thể response chậm tùy ý và vẫn có thể được gọi là availability. Tuy nhiên, đó là nguyên lý, còn chúng ta khi vào 1 trang web mà 1 2 phút để tải trang thì chúng ta có gọi là "available" không nhỉ :relieved:

2. CAP theorem và ACID properties

Nhắc đến 2 khái niệm này thì nhiều người sẽ nói ngay:

NoSQL DBMS gắn liền với CAP theorem, còn RDBMS gắn liền với ACID properties.

Anh em có thể thấy những so sánh như vậy có rất nhiều trên mạng. Nhưng cần phải biết, thực ra, CAP theorem đi liền với distributed system, còn ACID properties gắn với transaction. NoSQL DBMS có structure như distributed system nên mới gắn liền CAP theorem. Còn RDBMS thì rất mạnh về transaction, mọi RDBMS đều có support transaction nên RDBMS mới gắn liền với ACID proerties như vậy. Nên nhớ, ACID properties là dành cho database transaction, không phải dành cho RDBMS!

Vậy NoSQL DBMS có thể có ACID properties không? Một câu hỏi nghe hơi ngớ ngẩn. Nhưng ta có thể trả lời là: với những NoSQL DBMS nào có hỗ trợ transaction. Ví dụ như Neo4j, MongoDB..

3. Sự đánh đổi

Anh em nhìn lại hình CAP phía trên nhé! Như đã biết ta chỉ có thể chọn 2 trên 3 sự guarantee trong CAP theorem. Partition tolerance thì ta sẽ chọn, như phân tích hồi nãy của mình, nếu không chọn Partition tolerance thì hệ thống của ta chẳng còn là distributed system nữa, mà gần như là anh em đang chọn RDBMS rồi còn gì:joy:. Phải xem xét hệ thống của chúng ta cần Availablity hơn Consistency hay là Consistency hơn Availability. Và kèm theo đó, khi rơi vào trường hợp rủi ro, ta sẽ có cách handle như nào để hạn chế tác hại.
Ngay cả Google, Facebook , hay Amazon cũng chỉ có thể chọn 2/3 mà thôi.
Spanner của Google chọn hướng CP. Thời gian ngừng hoạt động là 5,26 phút mỗi năm.
HBase của Facebook chọn CP. Thời gian ngừng hoạt động lớn hơn một chút so với Google.
Google và Facebook chọn Consistency trên Availibility, theo quan điểm "Dù có theo trường phái Avaibility thì cũng không available 100% thời gian được, nên theo Consistency luôn!"
DynamoDB của Amazon chọn AP. Amazon muốn sở hữu Availibility, nên chấp nhận Consistency bị yếu, ấy mà Amazon vẫn nói DynamoDB của họ là strong consistency. Vì họ đã handle một số cách để làm giải quyết bớt vấn đề này như vector clock và calling application.

4. Sự thật về CAP

Có lúc nào anh em nhìn vào định nghĩa của CAP theorem và rồi cứ nhầm lẫn giữa Avaibility và Partition tolerance không? Thực tế, Availibility và Partition tolerance không thực sự tách biệt 100%, mà dẫm chân lên nhau. Trước giờ cũng đã có nhiều sự tranh luận về CAP theorem, cho rằng nó không đúng. Thậm chí một số cho rằng nên thay bằng PIE theorem.
Rốt cuộc, không nên tập trung quá nhiều vào định lý CAP. Nó vẫn đúng, nhưng định lý thì cũng chỉ là định lý mà thôi. Ta cứ chăm chăm vào định lý này mà dẫn đến việc bỏ qua các vấn đề quan trọng khác thì sẽ fail ngay. Nên xem xét rộng ra để có những đánh đổi và giải pháp phù hợp.

You shouldn’t really care about the CAP theorem.

Câu này của 1 bác kỹ sư Google. Mình thì không chủ ý như vậy đâu, bỏ thì không bỏ hoàn toàn, nhưng đừng tập trung quá, sẽ bị lỗi lầm mà mình đã phân tích ở trên.

Tổng kết về series

Part 1 mình đã nói về cách hoạt động của các loại NoSQL DBMS, part 2 này mình nói về cách xử lý của các NoSQL DBMS dựa trên CAP theorem (có thể xem lại hình của CAP theorem ở đầu bài viết để thấy 1 DBMS mình quan tâm thuộc kiểu, sẽ biết được các trường hợp xử lý của DBMS đó nha). Hi vọng anh em có cái nhìn tổng quan về mọi NoSQL DBMS, cũng như có cái nhìn sâu sắc về hệ thống database mà anh em đang làm việc.
Xa hơn, nếu chọn database thì anh em phải xem xét nhiều vấn đề:

  • Business của cả hệ thống sẽ như thế nào? Sẽ có thể có những trường hợp "khó nhằn" nào xảy ra? Tuỳ business mà sẽ có những yêu cầu thiết yếu riêng, có khi thì đòi hỏi về consistency, có khi lại là availability, có khi lại là performance,.. thì ta sẽ dựa trên đó để chọn mô hình và kiểu CAP-A hay CAP-C cho phù hợp. Và cũng phải đặt câu hỏi là trong tương lai, hệ thống sẽ thay đổi theo những tình huống nào, thì DBMS của chúng ta có phù hợp không? Có nhiều khách hàng, nhiều data hơn, thì lúc đó DBMS mình sẽ support scaling ổn không?
  • Trên thực tế (là ở production) thì cái hệ thống của mình sẽ như thế nào? Server của chúng ta sẽ đòi hỏi cấu hình như thế nào lẫn budget bỏ ra? Hệ thống mình sẽ build ở đâu, trên toàn thế giới hay ở một địa phương, để tưởng tượng architecture của hệ thống. Tiếp theo, budget có cho phép chúng ta sở hữu những server có cấu hình mạnh mẽ không? Điều này lại ảnh hưởng đến DBMS mà chúng ta chọn.
  • DBMS là Open-source hay Proprietary? Điều này liên quan tới chi phí phải trả cho licenses lẫn mức độ tin cậy và mức độ support tận răng của DBMS.
  • DBMS yêu cầu Server OS như nào? Ví dụ như có một số DBMS chỉ xài được trên Windows chứ không xài được trên Linux, rồi một số lại đòi hỏi cài middleware hay platform riêng, thì ta phải để ý xem có conflict hay khó khăn khác không ha.
  • DBMS hỗ trợ những programming language nào? Ví dụ anh em làm dự án có ngôn ngữ C# mà cái DBMS anh em chọn chỉ support C++ và Go thì khó nhằn đấy. Vẫn có những library bind API giữa C# với C++ cho mình, nhưng cần phải xem xét kỹ lưỡng vì thường thì những library này là open-source, chưa biết nay mai có chuyện gì xảy ra, ví dụ có những API mà DBMS thay đổi hoặc thêm mới những chắc gì library đã hỗ trợ kịp thời?
  • Trang web nào để tham khảo? Trang DB Engine nha anh em, trang này cũng cho biết required server OS và các lisences cho phép... Rất trực quan và khá đầy đủ!

Còn nhiều nữa, nhưng tạm thời mình chỉ liệt kê những điều mà mình thấy đáng được quan tâm nhất ở trên đây. Trên hết, ta phải xác định hệ thống của chúng ta thực sự cần gì và điều kiện cho phép, để có thể quyết định, đưa ra những sự đánh đổi đúng đắn.

Kết bài

Mình dừng series này tại đây. Hi vọng series này sẽ giúp anh em hiểu sâu hơn và có những cái nhìn đa chiều về NoSQL DBMS! Có thiếu sót gì thì anh em comment để giúp mình hoàn thiện nó nhé! Thân ái, và hẹn gặp lại!

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.
72 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
67 2
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 4 tháng trước
67 2
White
27 6
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 mana...
MasBeeju viết 5 tháng trước
27 6
White
15 11
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 4 tháng trước
15 11
Bài viết liên quan
White
2 0
Kotlin giờ là một từ khóa làm điên đảo cả giới lập trình viên đặc biệt là lập trình viên android. Kotlin hiện nay rất phổ biến và cực kì mạnh mẽ, c...
Aragami1408 viết 1 năm trước
2 0
White
15 0
Chào các bạn, trong chuỗi nghiên cứu của mình về Blockchain, có một bài viết khá thú vị về Database mà mình nghĩ nên chia sẽ ở đây, mong nhận đc nh...
Phuoc-Thanh Do viết 8 tháng trước
15 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
4 bài viết.
72 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á!