Cơ sở dữ liệu tài liệu so với cơ sở dữ liệu quan hệ: làm thế nào để chọn?

Tôi là một người SQL, nhưng tôi biết Không chỉ có cơ sở dữ liệu SQL - chủ yếu là cơ sở dữ liệu. Như với hầu hết các công nghệ, có pro và nhược điểm cho mỗi công nghệ.

Tôi đã đọc một số bài báo, nhưng chúng quá lý thuyết. Những gì tôi muốn là hai trường hợp thực tế:

1. khi một sự chuyển đổi từ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu đã cải thiện
2. khi chuyển đổi từ tài liệu sang cơ sở dữ liệu quan hệ đã cải thiện

Cải thiện là bất cứ điều gì làm cho các chương trình tốt hơn - ít thời gian phát triển hơn, khả năng mở rộng, hiệu suất, bất cứ điều gì có liên quan đến lập trình. Có một cảnh báo cho 2 .: những câu chuyện như "quay trở lại cơ sở dữ liệu quan hệ vì mọi người đều biết SQL" là không tốt

Lý do chính để chọn cơ sở dữ liệu NoQuery trong những năm qua là Tính khả dụng . Đối với các công ty như Amazon, Google và Facebook một giờ ngừng hoạt động hoặc không thể chấp nhận được. Để đạt được tính sẵn sàng cao, bạn cần giảm một điểm lỗi, điều đó có nghĩa là bạn cần sử dụng một hệ thống phân tán có nhiều máy tính trong trường hợp máy tính gặp sự cố, dịch vụ vẫn khả dụng.

Cơ sở dữ liệu Relatione truyền thống không tốt lắm trong thiết lập đa chủ phân tán. Đó là lý do tại sao NoQuery đã rất phổ biến gần đây. Vì vậy, nếu bạn cần tính sẵn sàng cao, bạn có thể chọn cơ sở dữ liệu NoQuery như Riak, Cassandra, HBase, S3 hoặc BigTable.

Có một bài đăng blog hay về Động lực học của Amazon, đó là một giới thiệu tốt về cơ sở dữ liệu NoQuery phân tán.

Bây giờ, thuật ngữ NoQuery rất rộng nên có nhiều cơ sở dữ liệu NoQuery không được phân phối. Nhưng họ giải quyết các vấn đề khác. Ví dụ Neo4j - cơ sở dữ liệu đồ thị tốt cho một loại truy vấn mà RDBMS truyền thống không được tối ưu hóa. Hoặc như trong trường hợp của bạn là cơ sở dữ liệu tài liệu, trong đó bạn không phải thay đổi lược đồ nếu bạn muốn thêm một số trường cho một số tài liệu. Nói cách khác, cơ sở dữ liệu tài liệu là tốt khi hầu hết các bài đăng (tài liệu) có các trường khác nhau nên một bảng quan hệ với các cột được xác định trước không thể sử dụng được.

Tuy nhiên, hầu hết các cơ sở dữ liệu NoQuery không linh hoạt như cơ sở dữ liệu RDBMS truyền thống, vì vậy, nên sử dụng cơ sở dữ liệu RDBMS truyền thống cho đến khi nó không thể giải quyết vấn đề của bạn nữa.

Tôi có một cách tiếp cận đơn giản để xác định cơ sở dữ liệu phù hợp nhất với dữ liệu.

Tôi chỉ tự hỏi: Giả sử tôi không có cơ sở dữ liệu, tôi sẽ lưu phần lớn nhất và dữ liệu quan trọng dưới dạng tài liệu hay tôi sẽ lưu trữ chúng trong bảng tính.

Khi câu trả lời là "Bảng tính", đây là một dấu hiệu rõ ràng cho thấy mô hình quan hệ và RDBMS truyền thống phù hợp nhất với hầu hết các nhiệm vụ. Nếu dữ liệu thực sự đơn giản, như chỉ các cặp giá trị chính hoặc các bảng đơn giản và tính toàn vẹn tham chiếu không phải là một chủ đề, thì cơ sở dữ liệu NoQuery có lẽ phù hợp nhất cho nhiệm vụ và có thể tăng hiệu suất khá nhiều!

Ngoài ra, khi bạn hoàn toàn không thể tìm thấy một cấu trúc chung, cơ sở dữ liệu NoQuery phù hợp nhất cho nhiệm vụ.

Khi dữ liệu giống tài liệu hơn, ví dụ dữ liệu văn bản có cấu trúc phân cấp mà không có quan hệ rõ ràng, thì tôi mới nghĩ đến Cơ sở dữ liệu XML, dễ dàng cho phép bạn lưu trữ các tài liệu có cấu trúc phân cấp. Tuy nhiên, đôi khi tốt nhất là sử dụng phần mềm quản lý tài liệu.

Vì vậy, để đưa ra một câu trả lời cụ thể và đơn giản cho cả hai câu hỏi của bạn: Nó phụ thuộc vào dữ liệu.

khi một sự chuyển đổi từ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu đã cải thiện

Khi bạn cần duy trì dữ liệu văn bản có cấu trúc phân cấp, Cơ sở dữ liệu Xml có thể là một cải tiến lớn về khả năng bảo trì và có thể cả khả năng mở rộng.

khi chuyển đổi từ tài liệu sang cơ sở dữ liệu quan hệ đã cải thiện

Chà, ví dụ khi dữ liệu chủ yếu ở dạng giống như bảng có quan hệ rõ ràng và bạn cần đảm bảo tính toàn vẹn.

Chúng tôi đã phải từ bỏ mô hình quan hệ vì dữ liệu chúng tôi nhận được không có lược đồ tĩnh đơn giản, rõ ràng, cố định.

Người dùng - và câu chuyện của người dùng - không có lược đồ tĩnh cố định.

Chúng tôi đã cố gắng áp đặt một lược đồ RDBMS cố định, tĩnh, nhưng đó là một sai lầm.

Mỗi lần phân phối dữ liệu của bên thứ 3 (từ khách hàng và từ nhà cung cấp) là tương tự nhau, nhưng không giống nhau. Chúng tôi đã thử ánh xạ nó tới một lược đồ quan hệ cố định, nhưng tính biến thiên là quá lớn. Chúng tôi hoặc phải thêm các trường với mỗi tệp (vài tuần mỗi tuần) hoặc chúng tôi phải rời khỏi lược đồ quan hệ tĩnh, cố định.

Nếu chúng tôi xem mỗi bản ghi là một "tài liệu" với một tập hợp con các phần tử chung và một bộ sưu tập các phần tử dữ liệu bổ sung (cũng như không xác định) duy nhất, chúng tôi sẽ hạnh phúc hơn nhiều.

Bộ sưu tập các yếu tố dữ liệu không xác định là những gì người dùng thực sự cần cho các trường hợp sử dụng của họ.

Lược đồ tĩnh cố định của mô hình quan hệ không phù hợp với các trường hợp sử dụng của chúng tôi.