Tại sao cơ sở dữ liệu noQuery có khả năng mở rộng hơn SQL?

Gần đây tôi đọc rất nhiều về DBMS noQuery. Tôi hiểu định lý CAP , quy tắc ACID , quy tắc BASE và lý thuyết cơ bản. Nhưng không tìm thấy bất kỳ tài nguyên nào về lý do tại sao noQuery có thể mở rộng dễ dàng hơn RDBMS (ví dụ trong trường hợp hệ thống yêu cầu nhiều máy chủ DB)?

Tôi đoán rằng việc giữ các ràng buộc và khóa ngoại chi phí tài nguyên và khi một DBMS được phân phối, nó phức tạp hơn rất nhiều. Nhưng tôi hy vọng có nhiều hơn thế.

Ai đó có thể vui lòng giải thích làm thế nào noQuery / SQL ảnh hưởng đến khả năng mở rộng?

cơ sở dữ liệu noQuery cung cấp một lượng lớn chức năng mà cơ sở dữ liệu SQL cung cấp cho bạn bởi bản chất của nó.

Những thứ như thực thi tự động tính toàn vẹn tham chiếu, giao dịch, v.v ... Đây là tất cả những thứ rất tiện lợi cho một số vấn đề và đòi hỏi một số kỹ thuật thú vị để mở rộng ra bên ngoài một máy chủ (nghĩ về những gì xảy ra nếu bạn cần khóa hai các bảng cho một giao dịch nguyên tử và chúng ở trên các máy chủ khác nhau!).

cơ sở dữ liệu noQuery không có tất cả điều đó. Nếu bạn cần những thứ đó, bạn cần phải tự làm, nhưng nếu bạn không cần nó (và có rất nhiều ứng dụng không có), thì bạn sẽ gặp may mắn. DB không phải thực hiện tất cả các hoạt động phức tạp này và khóa phần lớn tập dữ liệu, vì vậy thật dễ dàng phân vùng thứ trên nhiều máy chủ / đĩa / bất cứ thứ gì và nó hoạt động rất nhanh.

Đó không phải là về NoQuery vs SQL, mà là về BASE vs ACID.

Khả năng mở rộng phải được chia thành các thành phần của nó:

• Đọc tỷ lệ = xử lý khối lượng hoạt động đọc cao hơn
• Viết tỷ lệ = xử lý khối lượng cao hơn của hoạt động ghi

Cơ sở dữ liệu tuân thủ ACID (như RDBMS truyền thống) có thể mở rộng quy mô đọc. Chúng không thực sự kém hiệu quả hơn cơ sở dữ liệu NoQuery vì các tắc nghẽn về hiệu năng (có thể) được giới thiệu bởi những thứ mà NoQuery (đôi khi) thiếu (như tham gia và nơi hạn chế) mà bạn có thể chọn không sử dụng. Các cụm RDBMS của SQL có thể chia tỷ lệ đọc bằng cách giới thiệu các nút bổ sung trong cụm. Có những hạn chế đối với các thao tác đọc có thể được thu nhỏ bao xa, nhưng chúng bị áp đặt bởi khó khăn trong việc mở rộng ghi khi bạn giới thiệu nhiều nút hơn vào cụm.

Viết tỷ lệ là nơi mọi thứ có được lông. Có nhiều ràng buộc khác nhau được áp đặt bởi nguyên tắc ACID mà bạn không thấy trong các kiến ​​trúc (BASE) nhất quán cuối cùng:

• Nguyên tử có nghĩa là các giao dịch phải hoàn thành hoặc thất bại toàn bộ, vì vậy rất nhiều kế toán phải được thực hiện phía sau hậu trường để đảm bảo điều này.
• Các ràng buộc nhất quán có nghĩa là tất cả các nút trong cụm phải giống hệt nhau. Nếu bạn ghi vào một nút, ghi này phải được sao chép sang tất cả các nút khác trước khi trả lại phản hồi cho máy khách. Điều này làm cho một cụm RDBMS truyền thống khó mở rộng.
• Các ràng buộc về độ bền có nghĩa là để không bao giờ bị mất ghi, bạn phải đảm bảo rằng trước khi phản hồi được trả về máy khách, ghi đã được xóa vào đĩa.

Để mở rộng quy mô ghi hoạt động hoặc số lượng nút trong một cụm vượt quá một điểm nhất định, bạn phải có khả năng thư giãn một số yêu cầu ACID:

• Thả nguyên tử cho phép bạn rút ngắn thời gian mà các bảng (bộ dữ liệu) bị khóa. Ví dụ: MongoDB, CouchDB.
• Giảm tính nhất quán cho phép bạn mở rộng quy mô ghi trên các nút cụm. Ví dụ: riak, cassandra.
• Giảm độ bền cho phép bạn trả lời để viết lệnh mà không cần xả vào đĩa. Ví dụ: memcache, redis.

Cơ sở dữ liệu NoQuery thường theo mô hình BASE thay vì mô hình ACID. Họ từ bỏ các yêu cầu A, C và / hoặc D, và đổi lại họ cải thiện khả năng mở rộng. Một số, như Cassandra, cho phép bạn chọn tham gia bảo đảm của ACID khi bạn cần chúng. Tuy nhiên, không phải tất cả các cơ sở dữ liệu NoQuery đều có khả năng mở rộng hơn mọi lúc.

API SQL thiếu một cơ chế để mô tả các truy vấn trong đó các yêu cầu của ACID được nới lỏng. Đây là lý do tại sao các cơ sở dữ liệu BASE đều là NoQuery.

Lưu ý cá nhân: một điểm cuối cùng tôi muốn đưa ra là hầu hết các trường hợp hiện tại NoQuery đang được sử dụng để cải thiện hiệu năng, một giải pháp có thể có trên RDBMS thích hợp bằng cách sử dụng lược đồ chuẩn hóa chính xác với các chỉ mục thích hợp. Như được chứng minh bởi chính trang web này (được cung cấp bởi MS SQL Server) RDBMS có thể mở rộng quy mô công việc lớn, nếu bạn sử dụng chúng một cách thích hợp. Những người không hiểu cách tối ưu hóa RDBMS nên tránh xa NoQuery, vì họ không hiểu những rủi ro mà họ đang gặp phải với dữ liệu của họ.

Cập nhật (2019-09-17):

Cảnh quan của cơ sở dữ liệu đã phát triển kể từ khi đăng câu trả lời này. Mặc dù vẫn còn sự phân đôi giữa thế giới RDBMS ACID và thế giới NoQuery BASE, dòng này đã trở nên mờ nhạt hơn. Các cơ sở dữ liệu NoQuery đã được thêm các tính năng từ thế giới RDBMS như hỗ trợ giao dịch và API của SQL. Hiện tại thậm chí có các cơ sở dữ liệu hứa hẹn SQL, ACID và ghi tỷ lệ, như Google Cloud Spanner, YugabyteDB hoặc CockroachDB. Thông thường, ma quỷ nằm trong các chi tiết, nhưng đối với hầu hết các mục đích thì đây là "đủ ACID". Để tìm hiểu sâu hơn về công nghệ cơ sở dữ liệu và cách thức phát triển, bạn có thể xem qua bản trình chiếu này (các ghi chú slide có phần giải thích kèm theo).

Đúng là các cơ sở dữ liệu NoQuery (MongoDB, Redis, Riak, Memcached, v.v.) không duy trì các ràng buộc khóa ngoài và các hoạt động nguyên tử phải được chỉ định rõ ràng hơn. Cũng đúng là các cơ sở dữ liệu SQL (SQL Server, Oracle, PostgreSQL, v.v.) có thể được thu nhỏ để xử lý các yêu cầu hiệu suất rất lớn của các DBA dày dạn.

Cơ sở dữ liệu NoQuery cho phép các lập trình viên dày dạn, những người hiểu rõ về điều kiện chủng tộc và hoạt động nguyên tử, từ bỏ một lượng lớn xử lý chỉ cần trong một tỷ lệ nhỏ mã ứng dụng web ngày nay. Cơ sở dữ liệu NoQuery chắc chắn có các hoạt động nguyên tử và hầu hết tất cả các yêu cầu giao dịch có trong cơ sở dữ liệu SQL cũng có thể được lấy cơ sở dữ liệu NoQuery. Sự khác biệt là mức độ trừu tượng. Cơ sở dữ liệu NoQuery loại bỏ mức độ trừu tượng cao hơn và trao khả năng đó cho lập trình viên ứng dụng, do đó dẫn đến mã tổng thể nhanh hơn với xác suất tham nhũng dữ liệu tăng lên bởi các lập trình viên không hợp lệ.

Kết quả là chúng ta có nhiều khả năng thấy cơ sở dữ liệu NoQuery đang được sử dụng ngày càng nhiều trong không gian ứng dụng web, trong đó thời gian phát triển và hiệu suất là rất quan trọng. Phần mềm tài chính và doanh nghiệp có khả năng giữ lại di sản SQL vì hiệu suất phần cứng tương đối rẻ, họ đã có sẵn các DBA dày dạn và rủi ro gia tăng do các lập trình viên không hợp pháp gây ra là không thể chấp nhận được.

Từ IBM DB2 : Cung cấp khả năng mở rộng dữ liệu ở mức đám mây với cơ sở dữ liệu NoQuery

Khả năng mở rộng là hệ thống có thể hỗ trợ cơ sở dữ liệu rất lớn với tỷ lệ yêu cầu rất cao với độ trễ rất thấp.

Các hệ thống NoQuery có một số tính năng thiết kế chung:

• Khả năng mở rộng quy mô theo chiều ngang trên nhiều máy chủ.
• Giao diện hoặc giao thức mức gọi đơn giản (trái ngược với ràng buộc SQL).
• Hỗ trợ cho các mô hình nhất quán yếu hơn các giao dịch ACID trong hầu hết RDBMS truyền thống.
• Sử dụng hiệu quả các chỉ mục phân tán và RAM để lưu trữ dữ liệu.
• Khả năng tự động xác định các thuộc tính hoặc lược đồ dữ liệu mới.

Tại sao cơ sở dữ liệu quan hệ có thể không tối ưu cho Thu nhỏ

Nhìn chung, các hệ thống quản lý cơ sở dữ liệu quan hệ đã được coi là một "giải pháp phù hợp với tất cả các kích thước cho việc duy trì và truy xuất dữ liệu" trong nhiều thập kỷ. Họ đã trưởng thành sau những nỗ lực nghiên cứu và phát triển sâu rộng và rất thành công tạo ra một thị trường lớn và giải pháp trong các lĩnh vực kinh doanh khác nhau.

Nhu cầu ngày càng tăng về khả năng mở rộng và các yêu cầu ứng dụng mới đã tạo ra những thách thức mới cho RDBMS truyền thống, bao gồm cả sự không hài lòng với cách tiếp cận một kích cỡ phù hợp này trong một số ứng dụng quy mô web. Câu trả lời cho điều này là một thế hệ mới của phần mềm cơ sở dữ liệu hiệu năng cao, chi phí thấp được thiết kế để thách thức sự thống trị của các hệ thống quản lý cơ sở dữ liệu quan hệ. Một lý do lớn cho phong trào NoQuery là việc triển khai các ứng dụng web, doanh nghiệp và điện toán đám mây khác nhau có các yêu cầu khác nhau về cơ sở dữ liệu của họ - ví dụ, không phải mọi ứng dụng đều yêu cầu tính nhất quán dữ liệu cứng nhắc.

Một ví dụ khác: Đối với các trang web có số lượng lớn như eBay, Amazon, Twitter hoặc Facebook, khả năng mở rộng và tính sẵn sàng cao là những yêu cầu thiết yếu không thể bị xâm phạm. Đối với các ứng dụng này, ngay cả việc ngừng hoạt động nhỏ nhất cũng có thể gây ra hậu quả tài chính đáng kể và ảnh hưởng đến niềm tin của khách hàng.

Trên DBA.SE: Tỷ lệ ngang có nghĩa là gì?

Mở rộng theo chiều ngang về cơ bản là xây dựng thay vì lên. Bạn không đi và mua một máy chủ lớn hơn và chuyển tất cả tải của bạn lên nó, thay vào đó bạn mua hơn 1 máy chủ bổ sung và phân phối tải của bạn trên chúng.

Chia tỷ lệ ngang được sử dụng khi bạn có khả năng chạy nhiều phiên bản trên máy chủ cùng một lúc. Thông thường, việc đi từ 1 máy chủ đến 2 máy chủ sẽ khó khăn hơn nhiều, đó là đi từ 2 đến 5, 10, 50, v.v.

Khi bạn đã giải quyết các vấn đề về chạy các trường hợp song song, bạn có thể tận dụng các môi trường như Amazon EC2, Dịch vụ đám mây của Rackspace, GoGrid, v.v. bạn không sử dụng chỉ để trang trải cho những tải cao điểm đó.

Cơ sở dữ liệu quan hệ là một trong những mục khó khăn hơn để chạy song song đọc / ghi đầy đủ.