Cơ sở dữ liệu NoQuery có thể gây mất dữ liệu không thường xuyên?

Tôi hiện đang đánh giá cơ sở dữ liệu để sử dụng cho một dự án mới, sẽ yêu cầu chèn và truy vấn một lượng lớn dữ liệu giao dịch. Nhóm của chúng tôi đang nghiêng về Cassandra, nhưng sau đó tôi đọc bài viết này dường như đề xuất sử dụng cơ sở dữ liệu không tuân thủ ACID có thể dẫn đến mất dữ liệu không thường xuyên:

http://www.dbms2.com/2010/09/21/acid-compliant-transaction-integrity/

Tôi không thể tìm thấy bất kỳ thông tin nào khác về điều này trên web và không thể hiểu làm thế nào việc tuân thủ không phải ACID có nghĩa là mất dữ liệu có thể xảy ra. Bất cứ ai có thể làm sáng tỏ?

ACID có nghĩa là

• Nguyên tử
• Tính nhất quán
• Sự cách ly
• Độ bền

Điều này có nghĩa với bạn là "mọi hành động ghi sẽ chỉ được thực hiện một lần (không có bản ghi trùng lặp) nhưng sẽ được lưu trữ hoàn toàn trong cơ sở dữ liệu khi hành động được thực hiện" và mỗi khi bạn đọc, bạn sẽ nhận được dữ liệu bạn muốn .

Vấn đề của cơ sở dữ liệu NoQuery là chúng thường được phân phối (đó là những gì mọi người muốn, các hệ thống có thể mở rộng giá rẻ), điều đó có nghĩa là cần có thời gian để sao chép dữ liệu vào tất cả các nút. Đôi khi có thể đọc trong khi viết và kết thúc với dữ liệu cũ trong khi dữ liệu mới sắp ra.

Bạn đang hy sinh sự thuần khiết cho tốc độ.

Đây là phiên bản ngắn của câu trả lời của tôi và tôi không chắc mình cần giải thích gì thêm. Đặt câu hỏi cho tôi!

Mặc dù đây là câu hỏi cũ ...

Nói tóm lại, bạn có thể hiểu ACID là đảm bảo tính toàn vẹn / an toàn dữ liệu trong mọi trường hợp dự kiến . Giống như trong lập trình chung, tất cả các vấn đề đau đầu đến từ đa luồng.

Vấn đề lớn nhất trên NoQuery chủ yếu là ACI. D (urility) thường là một vấn đề riêng biệt.

Nếu DB của bạn là một luồng đơn - vì vậy chỉ một người dùng có thể truy cập cùng một lúc -, đó thực sự là tuân thủ ACI. Nhưng tôi chắc chắn rằng hầu như không có máy chủ nào có thể có sự sang trọng này.

Nếu DB của bạn cần đa luồng - phục vụ đồng thời nhiều người dùng / khách hàng - bạn phải cần giao dịch tuân thủ ACI. Hoặc bạn sẽ nhận được tham nhũng dữ liệu im lặng thay vì mất dữ liệu đơn giản. Mà còn kinh khủng hơn nhiều. Đơn giản, điều này hoàn toàn giống với lập trình đa luồng chung. Nếu bạn không có cơ chế phù hợp như khóa, bạn sẽ nhận được dữ liệu không xác định. Và cơ chế trong DB gọi là tuân thủ ACID hoàn toàn .

Nhiều cơ sở dữ liệu YesQuery / NoQuery tự quảng cáo ACID-tuân thủ, nhưng thực tế, rất ít trong số chúng thực sự làm được.

• Không tuân thủ ACID = Bạn sẽ luôn nhận được kết quả không xác định trong môi trường nhiều người dùng (máy khách). Tôi thậm chí không nghĩ loại DB nào làm điều này.

• Hàng đơn / khóa tuân thủ ACID = Bạn sẽ nhận được kết quả được bảo đảm nếu bạn chỉ sửa đổi một giá trị duy nhất. Nhưng kết quả không xác định (= hỏng dữ liệu im lặng) để cập nhật đồng thời nhiều hàng / khóa. Hầu hết các DB NoQuery phổ biến hiện nay bao gồm Cassandra, MongoDB, CouchDB, Hoài Các loại DB này chỉ an toàn cho giao dịch một hàng. Vì vậy, bạn cần đảm bảo logic DB của mình sẽ không chạm vào nhiều hàng trong một giao dịch.

• Tuân thủ ACID nhiều hàng / khóa = Bạn sẽ luôn nhận được kết quả được đảm bảo cho mọi hoạt động. Đây là yêu cầu tối thiểu như một RDBMS. Trong lĩnh vực NoQuery, rất ít trong số họ làm điều này. Spanner, MarkLogic, VoltDB, FoundationDB. Tôi thậm chí không chắc có nhiều giải pháp hơn. Các loại DB này thực sự mới mẻ và mới, vì vậy hầu như không biết gì về khả năng hoặc giới hạn của chúng.

Dù sao, đây là một so sánh ngoại trừ D (tính khả thi). Vì vậy, đừng quên kiểm tra thuộc tính độ bền. Thật khó để so sánh độ bền vì phạm vi trở nên quá rộng. Tôi không biết rõ chủ đề này

• Không có độ bền. Bạn sẽ mất dữ liệu bất cứ lúc nào.

• Lưu trữ an toàn trên đĩa. Khi bạn nhận được COMMIT OK, sau đó dữ liệu được đảm bảo trên đĩa. Bạn bị mất dữ liệu nếu đĩa bị hỏng.

Ngoài ra, có sự khác biệt ngay cả trên các DB tuân thủ ACID.

• Đôi khi tuân thủ ACID / bạn cần cấu hình / không có gì đó tự động .. / một số thành phần không tuân thủ ACID / rất nhanh nhưng bạn cần tắt một cái gì đó cho ... / Tuân thủ ACID nếu bạn sử dụng mô-đun cụ thể ... = chúng tôi sẽ không bó an toàn dữ liệu theo mặc định. Đó là một tiện ích bổ sung, tùy chọn hoặc được bán riêng. Đừng quên tải xuống, lắp ráp, thiết lập và ban hành lệnh thích hợp. Dù sao, an toàn dữ liệu có thể được bỏ qua âm thầm. Tự làm đi. Tự kiểm tra nó. Chúc may mắn không để xảy ra bất kỳ sai lầm. Mọi người trong nhóm của bạn phải là DBA hoàn hảo để sử dụng loại DB này một cách an toàn. MySQL.

• Luôn tuân thủ ACID = Chúng tôi không trao đổi an toàn dữ liệu với hiệu suất hoặc bất cứ điều gì. An toàn dữ liệu là gói bắt buộc với gói DB này. Hầu hết các RDBMS thương mại, PostgreSQL.

Trên đây là triển khai DB điển hình. Tuy nhiên, bất kỳ lỗi phần cứng nào khác có thể làm hỏng cơ sở dữ liệu. Chẳng hạn như lỗi bộ nhớ, lỗi kênh dữ liệu hoặc bất kỳ lỗi nào khác có thể xảy ra. Vì vậy, bạn cần dự phòng thêm, và DB chất lượng sản xuất thực sự phải cung cấp các tính năng chịu lỗi.

• Không dư thừa. Bạn mất tất cả dữ liệu nếu dữ liệu của bạn bị hỏng.

• Sao lưu. Bạn tạo bản sao chụp / khôi phục. Bạn mất dữ liệu sau lần sao lưu cuối cùng.

• Sao lưu trực tuyến. Bạn có thể thực hiện sao lưu ảnh chụp nhanh trong khi cơ sở dữ liệu đang chạy.

• Nhân rộng không đồng bộ. Sao lưu cho mỗi giây (hoặc khoảng thời gian được chỉ định). Nếu máy ngừng hoạt động, DB này đảm bảo lấy lại dữ liệu bằng cách khởi động lại. Bạn mất dữ liệu sau giây cuối cùng.

• Nhân rộng đồng bộ. Sao lưu ngay lập tức cho mỗi cập nhật dữ liệu. Bạn luôn có bản sao chính xác của dữ liệu gốc. Sử dụng bản sao nếu nguồn gốc bị phá vỡ.

Cho đến bây giờ, tôi thấy nhiều triển khai DB thiếu nhiều trong số này. Và tôi nghĩ rằng nếu họ thiếu ACID và hỗ trợ dự phòng thích hợp, người dùng cuối cùng sẽ mất dữ liệu.

"Nó phụ thuộc" là câu trả lời - có các tùy chọn cấu hình, được đề cập ở đây .

Nit nit nhỏ: cơ sở dữ liệu có thể bền nhưng không tuân thủ ACID, vì ACID là siêu bộ tính năng (ACID). Tôi không nghĩ rằng bất kỳ cơ sở dữ liệu NoQuery nào cũng có thể tuyên bố là hoàn toàn ACID, nhưng nhiều người trong số họ có thể yêu cầu vượt qua các yêu cầu phụ riêng lẻ, chẳng hạn như độ bền.