3.1. Thuộc tính ACID yếu

Trong một thời gian dài, tính nhất quán của dữ liệu đã là điều thiêng liêng đối với các kiến ​​trúc sư và nhà phát triển. Tất cả các cơ sở dữ liệu quan hệ đều cung cấp một số mức độ cô lập, thông qua khóa cập nhật và chặn đọc hoặc thông qua nhật ký hoàn tác. Với sự ra đời của một lượng lớn thông tin và các hệ thống phân tán, rõ ràng là không thể vừa đảm bảo một bộ hoạt động giao dịch cho chúng, vừa có được tính sẵn sàng cao và thời gian phản hồi nhanh, mặt khác.

Ngoài ra, ngay cả việc cập nhật một bản ghi cũng không đảm bảo rằng bất kỳ người dùng nào khác sẽ thấy ngay các thay đổi trong hệ thống, vì thay đổi có thể xảy ra, chẳng hạn như trong nút chính và bản sao được sao chép không đồng bộ sang nút phụ mà người dùng khác làm. Trong trường hợp này, anh ta sẽ thấy kết quả sau một khoảng thời gian nhất định. Đây được gọi là tính nhất quán cuối cùng và đây là điều mà tất cả các công ty Internet lớn nhất trên thế giới hiện đang hướng tới, bao gồm cả Facebook và Amazon. Cái sau tự hào tuyên bố rằng khoảng thời gian tối đa mà người dùng có thể thấy dữ liệu không nhất quán là không quá một giây. Một ví dụ về tình huống như vậy được thể hiện trong hình:

Câu hỏi hợp lý đặt ra trong tình huống như vậy là phải làm gì với các hệ thống theo kiểu cổ điển đặt ra yêu cầu cao về tính nguyên tử - tính nhất quán của hoạt động, đồng thời cần các cụm phân tán nhanh - tài chính, cửa hàng trực tuyến, v.v.? Thực tiễn cho thấy những yêu cầu này không còn phù hợp nữa: đây là điều mà một nhà thiết kế hệ thống ngân hàng tài chính đã nói: “Nếu chúng ta thực sự chờ đợi mỗi giao dịch được hoàn thành trong mạng lưới máy ATM (ATM) toàn cầu, các giao dịch sẽ mất nhiều thời gian đến nỗi khách hàng sẽ bỏ chạy trong cơn thịnh nộ. Điều gì xảy ra nếu bạn và đối tác của mình rút tiền cùng lúc và vượt quá giới hạn? “Cả hai người sẽ nhận được tiền, và chúng ta sẽ sửa nó sau.”

Một ví dụ khác là đặt phòng khách sạn được hiển thị trong hình. Các cửa hàng trực tuyến có chính sách dữ liệu giả định tính nhất quán cuối cùng được yêu cầu cung cấp các biện pháp trong trường hợp như vậy (giải quyết xung đột tự động, khôi phục hoạt động, cập nhật dữ liệu khác). Trên thực tế, các khách sạn luôn cố gắng giữ một “nhóm” phòng trống trong trường hợp khẩn cấp và đây có thể là một giải pháp cho một tình huống gây tranh cãi.

Trên thực tế, tính chất ACID yếu không có nghĩa là hoàn toàn không tồn tại. Trong hầu hết các trường hợp, ứng dụng làm việc với cơ sở dữ liệu quan hệ sử dụng giao dịch để thay đổi các đối tượng liên quan về mặt logic (thứ tự - các mục thứ tự), điều này là cần thiết vì đây là các bảng khác nhau. Với thiết kế chính xác của mô hình dữ liệu trong cơ sở dữ liệu NoSQL (tổng hợp là một đơn đặt hàng cùng với danh sách các mục đơn hàng), bạn có thể đạt được mức độ tách biệt tương tự khi thay đổi một bản ghi như trong cơ sở dữ liệu quan hệ.

3.2. Hệ thống phân tán, không chia sẻ tài nguyên (share nothing)

Một lần nữa, điều này không áp dụng cho các biểu đồ cơ sở dữ liệu, theo định nghĩa, cấu trúc của chúng không lan truyền tốt trên các nút từ xa.

Đây có lẽ là chủ đề chính của sự phát triển cơ sở dữ liệu NoSQL. Với sự phát triển dữ dội của thông tin trên thế giới và nhu cầu xử lý nó trong thời gian hợp lý, vấn đề về khả năng mở rộng theo chiều dọc đã nảy sinh - tốc độ tăng trưởng của bộ xử lý dừng lại ở mức 3,5 GHz, tốc độ đọc từ đĩa cũng đang tăng lên. tốc độ chậm, cộng với giá của một máy chủ mạnh luôn cao hơn tổng giá của một số máy chủ đơn giản. Trong tình huống này, cơ sở dữ liệu quan hệ thông thường, thậm chí được nhóm trên một mảng đĩa, không thể giải quyết vấn đề về tốc độ, khả năng mở rộng và thông lượng.

Cách duy nhất để thoát khỏi tình huống này là chia tỷ lệ theo chiều ngang, khi một số máy chủ độc lập được kết nối bằng mạng nhanh và mỗi máy chủ chỉ sở hữu / xử lý một phần dữ liệu và / hoặc chỉ một phần yêu cầu đọc-cập nhật. Trong kiến ​​trúc này, để tăng khả năng lưu trữ (dung lượng, thời gian phản hồi, thông lượng), bạn chỉ cần thêm một máy chủ mới vào cụm - và thế là xong. Sharding, nhân rộng, khả năng chịu lỗi (kết quả sẽ nhận được ngay cả khi một hoặc nhiều máy chủ ngừng phản hồi), phân phối lại dữ liệu trong trường hợp thêm nút do chính cơ sở dữ liệu NoQuery xử lý.

Tôi sẽ trình bày ngắn gọn các thuộc tính chính của cơ sở dữ liệu NoSQL phân tán:

Sao chép - sao chép dữ liệu sang các nút khác khi cập nhật. Cho phép cả hai đạt được khả năng mở rộng lớn hơn và tăng tính khả dụng và an toàn của dữ liệu. Người ta thường chia thành hai loại:

master-slave : peer-to-peer :

Loại đầu tiên giả định khả năng mở rộng tốt để đọc (có thể xảy ra từ bất kỳ nút nào), nhưng ghi không thể mở rộng (chỉ đối với nút chính). Ngoài ra còn có sự tinh tế trong việc đảm bảo tính khả dụng liên tục (trong trường hợp xảy ra sự cố chính, một trong các nút còn lại được gán theo cách thủ công hoặc tự động cho vị trí của nó). Loại sao chép thứ hai giả định rằng tất cả các nút đều bằng nhau và có thể phục vụ cả yêu cầu đọc và ghi.

Sharding là sự phân chia dữ liệu theo các nút:

Sharding thường được sử dụng như một “cái nạng” cho cơ sở dữ liệu quan hệ để tăng tốc độ và thông lượng: ứng dụng người dùng phân vùng dữ liệu trên một số cơ sở dữ liệu độc lập và khi người dùng yêu cầu dữ liệu tương ứng, họ sẽ truy cập vào một cơ sở dữ liệu cụ thể. Trong cơ sở dữ liệu NoSQL, sharding, giống như sao chép, được thực hiện tự động bởi chính cơ sở dữ liệu và ứng dụng người dùng tách biệt với các cơ chế phức tạp này.

3.3. Cơ sở dữ liệu NoSQL chủ yếu là mã nguồn mở và được tạo ra trong thế kỷ 21

Trên cơ sở thứ hai, Sadalaj và Fowler đã không phân loại cơ sở dữ liệu đối tượng là NoSQL (mặc dù http://nosql-database.org/ đưa chúng vào danh sách chung), vì chúng được tạo ra từ những năm 90 và chưa bao giờ trở nên phổ biến . .

Phong trào NoSQL đang trở nên phổ biến với tốc độ chóng mặt. Tuy nhiên, điều này không có nghĩa là cơ sở dữ liệu quan hệ đang trở thành di tích hoặc một cái gì đó cổ xưa. Nhiều khả năng chúng sẽ được sử dụng và sử dụng tích cực như trước đây, nhưng ngày càng có nhiều cơ sở dữ liệu NoSQL sẽ hoạt động cộng sinh với chúng. Chúng ta đang bước vào kỷ nguyên của sự bền bỉ đa ngôn ngữ, kỷ nguyên mà các kho lưu trữ dữ liệu khác nhau được sử dụng cho các nhu cầu khác nhau. Bây giờ không có sự độc quyền của cơ sở dữ liệu quan hệ như một nguồn dữ liệu không thể kiểm chứng. Càng ngày, các kiến ​​​​trúc sư càng chọn lưu trữ dựa trên bản chất của dữ liệu và cách chúng tôi muốn thao tác với nó, khối lượng thông tin được mong đợi. Và vì vậy mọi thứ chỉ trở nên thú vị hơn.

Dưới đây chúng tôi sẽ cố gắng hiểu hoạt động của cơ sở dữ liệu phân tán bằng cách sử dụng NoQuery Cassandra DBMS làm ví dụ ...