2
Thực sự đã có FoundationDB tuân thủ axit. Bây giờ Apple đã chộp lấy nó
—
Người dùng không có mũ
Câu trả lời:
Tôi sẽ đăng bài này dưới dạng câu trả lời hoàn toàn để hỗ trợ cuộc trò chuyện - Tim Mahy , nawroth và CraigTP đã đề xuất cơ sở dữ liệu khả thi. CouchDB sẽ là ưu tiên của tôi do sử dụng Erlang , nhưng có những thứ khác ở ngoài đó.
Tôi muốn nói rằng ACID không mâu thuẫn hoặc phủ nhận khái niệm về NoQuery ... Mặc dù dường như có một xu hướng theo ý kiến của chim bồ câu , tôi sẽ cho rằng các khái niệm này là khác biệt.
Về cơ bản, NoQuery là về giá trị khóa đơn giản (ví dụ Redis) hoặc lược đồ kiểu tài liệu (các cặp giá trị khóa được thu thập trong mô hình "tài liệu", ví dụ MongoDB) như là một thay thế trực tiếp cho lược đồ rõ ràng trong các RDBMS cổ điển. Nó cho phép nhà phát triển xử lý mọi thứ một cách bất đối xứng, trong khi các công cụ truyền thống đã thực thi tính đồng nhất cứng nhắc trên mô hình dữ liệu. Lý do điều này rất thú vị là vì nó cung cấp một cách khác để đối phó với sự thay đổi và đối với các tập dữ liệu lớn hơn, nó cung cấp các cơ hội thú vị để xử lý khối lượng và hiệu suất.
ACID cung cấp các nguyên tắc chi phối cách thay đổi được áp dụng cho cơ sở dữ liệu. Theo một cách rất đơn giản, nó tuyên bố (phiên bản của riêng tôi):
Cuộc trò chuyện trở nên phấn khích hơn một chút khi nói đến ý tưởng tuyên truyền và ràng buộc . Một số công cụ RDBMS cung cấp khả năng thực thi các ràng buộc (ví dụ: khóa ngoại) có thể có các phần tử lan truyền (a la cascade ). Nói một cách đơn giản hơn, một "thứ" có thể có mối quan hệ với một "thứ" khác trong cơ sở dữ liệu và nếu bạn thay đổi một thuộc tính của một thứ thì nó có thể yêu cầu thay đổi khác (cập nhật, xóa, ... rất nhiều tùy chọn). Các cơ sở dữ liệu NoQuery , chủ yếu (hiện tại) tập trung vào khối lượng dữ liệu cao và lưu lượng truy cập cao, dường như đang giải quyết ý tưởng về các cập nhật phân tán diễn ra trong (theo quan điểm của người tiêu dùng) các khung thời gian tùy ý. Đây về cơ bản là một hình thức nhân rộng chuyên biệt được quản lý thông quagiao dịch - vì vậy tôi sẽ nói rằng nếu một cơ sở dữ liệu phân tán truyền thống có thể hỗ trợ ACID, thì cơ sở dữ liệu NoQuery cũng vậy.
Một số tài nguyên để đọc thêm:
CẬP NHẬT (27 tháng 7 năm 2012): Liên kết đến bài viết Wikipedia đã được cập nhật để phản ánh phiên bản của bài viết hiện tại khi câu trả lời này được đăng. Xin lưu ý rằng bài viết Wikipedia hiện tại đã được sửa đổi rộng rãi!
Chà, theo một phiên bản cũ hơn của một bài viết trên Wikipedia về NoQuery :
NoQuery là một phong trào thúc đẩy một lớp lưu trữ dữ liệu phi quan hệ được xác định một cách lỏng lẻo, phá vỡ một lịch sử lâu dài của cơ sở dữ liệu quan hệ và đảm bảo ACID.
và cũng:
Tên này là một nỗ lực để mô tả sự xuất hiện của một số lượng lớn các kho lưu trữ dữ liệu phân tán, không liên quan, thường không cố gắng cung cấp bảo đảm ACID.
và
Các hệ thống NoQuery thường cung cấp các đảm bảo tính nhất quán yếu như tính nhất quán cuối cùng và các giao dịch bị hạn chế đối với các mục dữ liệu đơn lẻ, mặc dù người ta có thể áp đặt các đảm bảo ACID đầy đủ bằng cách thêm một lớp phần mềm trung gian bổ sung.
Vì vậy, tóm lại, tôi muốn nói rằng một trong những lợi ích chính của kho lưu trữ dữ liệu "NoQuery" là thiếu các thuộc tính ACID khác biệt . Hơn nữa, IMHO, càng cố gắng thực hiện và thực thi các thuộc tính ACID , càng xa khỏi "tinh thần" của kho lưu trữ dữ liệu "NoQuery" mà bạn nhận được, và gần với RDBMS "thật" hơn (nói một cách tương đối, tất nhiên ).
Tuy nhiên, tất cả những gì đã nói, "NoQuery" là một thuật ngữ rất mơ hồ và mở ra cho các diễn giải riêng lẻ, và phụ thuộc rất nhiều vào quan điểm thuần túy của bạn. Ví dụ, hiện đại nhất ngày RDBMS hệ thống không thực sự tuân theo tất cả của Edgar F. Codd 's 12 quy tắc của mình mô hình mối quan hệ !
Theo một cách tiếp cận thực tế, có vẻ như CouchDB của Apache tiến gần nhất đến việc thể hiện cả hai tuân thủ ACID trong khi vẫn duy trì tâm lý "NoQuery" không liên quan, lỏng lẻo.
Vui lòng đảm bảo bạn đã đọc phần giới thiệu của Martin Fowler về cơ sở dữ liệu NoQuery . Và video tương ứng.
Trước hết, chúng ta có thể phân biệt hai loại cơ sở dữ liệu NoQuery:
Theo thiết kế, hầu hết các cơ sở dữ liệu hướng đồ thị là ACID !
Sau đó, những gì về các loại khác?
Trong cơ sở dữ liệu định hướng tổng hợp, chúng ta có thể đặt ba loại phụ:
Cái mà chúng ta gọi là Tổng hợp ở đây, là những gì Eric Evans đã định nghĩa trong Thiết kế hướng tên miền của nó như là một thực thể và các đối tượng giá trị tự cung cấp trong một bối cảnh bị ràng buộc nhất định.
Kết quả là, tổng hợp là một tập hợp dữ liệu mà chúng ta tương tác với tư cách là một đơn vị. Các uẩn tạo thành các ranh giới cho các hoạt động ACID với cơ sở dữ liệu. (Martin Fowler)
Vì vậy, ở cấp độ Tổng hợp, chúng tôi có thể nói rằng hầu hết các cơ sở dữ liệu NoQuery có thể an toàn như ACID RDBMS , với các cài đặt phù hợp. Về nguồn, nếu bạn điều chỉnh máy chủ của mình để có tốc độ tốt nhất, bạn có thể gặp phải điều gì đó không phải là ACID. Nhưng nhân rộng sẽ giúp.
Quan điểm chính của tôi là bạn phải sử dụng cơ sở dữ liệu NoQuery, chứ không phải là một thay thế (giá rẻ) cho RDBMS. Tôi đã thấy quá nhiều dự án lạm dụng quan hệ giữa các tài liệu. Điều này không thể là ACID. Nếu bạn ở cấp độ tài liệu, tức là ở ranh giới Tổng hợp, bạn không cần bất kỳ giao dịch nào. Và dữ liệu của bạn sẽ an toàn như với cơ sở dữ liệu ACID, ngay cả khi nó không thực sự là ACID, vì bạn không cần các giao dịch đó! Nếu bạn cần giao dịch và cập nhật nhiều "tài liệu" cùng một lúc, bạn không còn ở trong thế giới NoQuery nữa - vì vậy hãy sử dụng công cụ RDBMS thay thế!
Một số cập nhật 2019: Bắt đầu từ phiên bản 4.0, đối với các tình huống yêu cầu nguyên tử để cập nhật nhiều tài liệu hoặc tính nhất quán giữa các lần đọc cho nhiều tài liệu, MongoDB cung cấp các giao dịch đa tài liệu cho các bộ bản sao .
FoundationDB tuân thủ ACID:
Nó có các giao dịch phù hợp, vì vậy bạn có thể cập nhật nhiều mục dữ liệu khác nhau theo kiểu ACID. Điều này được sử dụng làm nền tảng để duy trì các chỉ mục ở một lớp cao hơn.
Trong câu hỏi này ai đó phải đề cập đến OrientDB : OrientDB là một cơ sở dữ liệu NoQuery, một trong số ít, hỗ trợ các giao dịch ACID đầy đủ. ACID không chỉ dành cho RDBMS vì nó không phải là một phần của đại số quan hệ. Vì vậy, có thể có cơ sở dữ liệu NoQuery hỗ trợ ACID.
Tính năng này là tính năng tôi nhớ nhất trong MongoDB
ACID và NoQuery hoàn toàn trực giao. Người này không ngụ ý người kia.
Tôi có một cuốn sổ trên bàn, tôi dùng nó để ghi chú những việc mà tôi vẫn phải làm. Sổ ghi chép này là một cơ sở dữ liệu NoQuery. Tôi truy vấn nó bằng cách sử dụng tìm kiếm tuyến tính với "bộ đệm trang" vì vậy tôi không phải luôn tìm kiếm mọi trang. Nó cũng tuân thủ ACID vì tôi đảm bảo rằng tôi chỉ viết một điều tại một thời điểm và không bao giờ trong khi tôi đang đọc nó.
NoQuery đơn giản có nghĩa là nó không phải là SQL. Nhiều người bị lẫn lộn và nghĩ rằng nó có nghĩa là lưu trữ rất nhanh-hoang-tây-siêu-nhanh. Nó không. Nó không có nghĩa là lưu trữ khóa-giá trị, hoặc tính nhất quán cuối cùng. Tất cả điều đó có nghĩa là "không phải SQL", có rất nhiều cơ sở dữ liệu trên hành tinh này và hầu hết chúng không phải là SQL [cần dẫn nguồn] .
Bạn có thể tìm thấy nhiều ví dụ trong các câu trả lời khác vì vậy tôi không cần liệt kê chúng ở đây, nhưng có các cơ sở dữ liệu không phải SQL có tuân thủ ACID cho các hoạt động khác nhau, một số chỉ là ACID cho ghi đối tượng duy nhất trong khi một số đảm bảo hơn nhiều. Mỗi cơ sở dữ liệu là khác nhau.
"NoQuery" không phải là một thuật ngữ được xác định rõ. Đó là một khái niệm rất mơ hồ. Như vậy, thậm chí không thể nói đâu là sản phẩm "NoQuery". Không phải gần như tất cả các sản phẩm có nhãn hiệu chính tả với nhãn là các cửa hàng khóa-giá trị.
Có, MarkLogic Server là một giải pháp NoQuery (cơ sở dữ liệu tài liệu tôi muốn gọi nó) hoạt động với các giao dịch ACID
Ông nội của NoQuery: ZODB tuân thủ ACID. http://www.zodb.org/
Tuy nhiên, đó chỉ là Python.
Là một trong những người khởi tạo NoQuery (Tôi là người đóng góp sớm cho Apache CouchDB và là diễn giả tại sự kiện NoQuery đầu tiên được tổ chức tại CBS Interactive / CNET năm 2009) Tôi rất vui khi thấy các thuật toán mới tạo ra các khả năng không tồn tại trước đó . Giao thức Calvin cung cấp một cách mới để nghĩ về các ràng buộc vật lý như CAP và PACELC .
Thay vì sao chép không đồng bộ chủ động / thụ động hoặc sao chép đồng bộ chủ động / chủ động, Calvin duy trì tính chính xác và tính sẵn có trong các lần sao chép bằng cách sử dụng giao thức giống RAFT để duy trì nhật ký giao dịch. Ngoài ra, các giao dịch được xử lý một cách xác định tại mỗi bản sao, loại bỏ khả năng bế tắc, do đó, thỏa thuận đạt được chỉ với một vòng đồng thuận duy nhất. Điều này làm cho nó nhanh chóng ngay cả trên các triển khai trên nhiều đám mây trên toàn thế giới.
FaunaDB là triển khai cơ sở dữ liệu duy nhất sử dụng giao thức Calvin, làm cho nó phù hợp nhất cho các khối lượng công việc đòi hỏi tính toàn vẹn dữ liệu giống như máy tính lớn với quy mô và tính linh hoạt của NoQuery.
Nếu bạn đang tìm kiếm một kho lưu trữ khóa / giá trị tuân thủ ACID, thì có Berkeley DB . Trong số các cơ sở dữ liệu đồ thị, ít nhất Neo4j và HyperGraphDB cung cấp các giao dịch ACID (HyperGraphDB thực sự sử dụng Berkeley DB để lưu trữ cấp thấp tại thời điểm này).
Khái niệm này những người đóng góp Wikipedia định nghĩa là:
[Vỉ] một lớp các hệ thống quản lý cơ sở dữ liệu quan hệ hiện đại tìm cách cung cấp hiệu năng có thể mở rộng tương tự của các hệ thống NoQuery để xử lý khối lượng công việc đọc-ghi giao dịch trực tuyến (OLTP) trong khi vẫn duy trì bảo đảm ACID của hệ thống cơ sở dữ liệu truyền thống.
[1][2][3]
[1]Nancy Lynch và Seth Gilbert, phỏng đoán của Bia Brewer và tính khả thi của các dịch vụ web phù hợp, sẵn có, phân vùng, phù hợp, Tin tức ACM SIGACT, Tập 33 Số 2 (2002), pg. 51-59.
[2] "Định lý CAP của nhà sản xuất bia" , julianbrowne.com, Truy cập ngày 02 tháng 3 năm 2010
[3] "Định lý CAP nhà sản xuất trên các hệ thống phân tán" , royans.net
MongoDB thông báo rằng phiên bản 4.0 của nó sẽ tuân thủ ACID cho các giao dịch đa tài liệu.
Phiên bản 4.2. được cho là để hỗ trợ nó theo các thiết lập sharded.
https://www.mongodb.com/blog/post/multi-document-transilities-in-mongodb
FoundationDB đã được đề cập và tại thời điểm đó nó không phải là nguồn mở. Nó đã được Apple mở nguồn từ hai ngày trước: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Tôi tin rằng nó là tuân thủ ACID.
Để thêm vào danh sách các lựa chọn thay thế, một cơ sở dữ liệu NoSQL phù hợp hoàn toàn ACID là GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (tính năng ACID) là độc quyền, nhưng Hyperdex là miễn phí.
db4o
Không giống như tính bền vững hoặc tuần tự hóa của chính bạn, db4o là giao dịch ACID an toàn và cho phép truy vấn, sao chép và thay đổi lược đồ trong thời gian chạy
Tarantool là một cơ sở dữ liệu ACID NoQuery đầy đủ. Bạn có thể ban hành các thao tác CRUD hoặc các thủ tục được lưu trữ, mọi thứ sẽ được chạy với sự tuân thủ nghiêm ngặt với thuộc tính ACID. Bạn cũng có thể đọc về điều đó tại đây: http://urdy.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic cũng tuân thủ ACID. Tôi nghĩ là một trong những người chơi lớn nhất bây giờ.
Chờ đã xong.
NoQuery DB tuân thủ ACID đã hết ----------- hãy xem citrusleaf
BergDB là một cơ sở dữ liệu NoQuery nhẹ, mã nguồn mở, được thiết kế từ đầu để chạy các giao dịch ACID. Trên thực tế, BergDB là "nhiều" ACID hơn hầu hết các cơ sở dữ liệu SQL theo nghĩa là cách duy nhất để thay đổi trạng thái của cơ sở dữ liệu là chạy các giao dịch ACID với mức cô lập cao nhất (thuật ngữ SQL: "tuần tự hóa"). Sẽ không bao giờ có bất kỳ vấn đề nào với việc đọc bẩn, đọc không lặp lại hoặc đọc ảo.
Theo tôi, cơ sở dữ liệu vẫn có hiệu suất cao; nhưng đừng tin tôi, tôi đã tạo ra phần mềm. Thay vào đó hãy thử nó.
Rất nhiều giải pháp NoQuery hiện đại không hỗ trợ các giao dịch ACID (cập nhật đa khóa cách ly nguyên tử), nhưng hầu hết chúng đều hỗ trợ các nguyên hàm cho phép bạn thực hiện các giao dịch ở cấp ứng dụng.
Nếu một cửa hàng dữ liệu hỗ trợ tính tuyến tính theo khóa và so sánh và thiết lập (tính nguyên tử ở cấp độ tài liệu) thì đủ để thực hiện các giao dịch phía khách hàng, hơn nữa bạn có nhiều tùy chọn để chọn:
Nếu bạn cần mức cô lập Nối tiếp thì bạn có thể theo cùng thuật toán mà Google sử dụng cho hệ thống Percolator hoặc Cockroach Labs cho CockroachDB . Tôi đã viết blog về nó và tạo ra một hình ảnh trực quan từng bước , tôi hy vọng nó sẽ giúp bạn hiểu được ý tưởng chính đằng sau thuật toán.
Nếu bạn mong đợi sự ganh đua cao nhưng sẽ tốt cho bạn khi bạn đã đọc mức độ cô lập Đã cam kết, vui lòng xem qua các giao dịch RAMP của Peter Bailis.
Cách tiếp cận thứ ba là sử dụng các giao dịch bù còn được gọi là mẫu saga. Nó được mô tả vào cuối những năm 80 trong bài báo Sagas nhưng trở nên thực tế hơn với sự phát triển của các hệ thống phân tán. Xin vui lòng xem bài nói chuyện Áp dụng mô hình Saga để lấy cảm hứng.
Danh sách các cửa hàng dữ liệu phù hợp cho các giao dịch phía khách hàng bao gồm Cassandra với các giao dịch nhẹ, Rịa với các nhóm nhất quán, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB và các giao dịch khác.
YugaByte DB hỗ trợ các txns phân phối tuân thủ ACID cũng như khả năng tương thích Redis và CQL API trên lớp truy vấn.
VoltDB là người đăng ký yêu cầu tuân thủ ACID và mặc dù vẫn sử dụng SQL, các mục tiêu của nó là giống nhau về khả năng mở rộng
Node levelUP là giao dịch và được xây dựng trên leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB là một cơ sở dữ liệu NoQuery và có các giao dịch ACID .
Không chỉ NoQuery không tuân thủ ACID theo thiết kế. Phong trào NoQuery nắm lấy BASE (Có sẵn về cơ bản, trạng thái Mềm, Tính nhất quán cuối cùng) được cho là trái ngược với ACID. Cơ sở dữ liệu NoQuery thường được gọi là cơ sở dữ liệu bao gồm cuối cùng. Để hiểu được sự khác biệt, bạn nên đi sâu vào định lý CAP (hay còn gọi là định lý của nhà sản xuất bia)
Truy cập http://www.julianbrowne.com/article/viewer/brewers-cap-theorem