Cơ sở dữ liệu hướng tài liệu có được phát triển để trở thành thế hệ cơ sở dữ liệu tiếp theo và về cơ bản thay thế hoàn toàn cơ sở dữ liệu quan hệ không?
Không. Cơ sở dữ liệu hướng tài liệu (như MongoDB) rất tốt trong loại tác vụ mà chúng ta thường thấy trong các trang web hiện đại (tra cứu nhanh các mục riêng lẻ hoặc nhóm mục nhỏ).
Nhưng họ thực hiện một số đánh đổi lớn với các hệ thống quan hệ. Nếu không có những thứ như tuân thủ ACID, chúng sẽ không thể thay thế một số RDBMS nhất định. Và nếu bạn nhìn vào các hệ thống như MongoDB, việc thiếu tuân thủ ACID là một lý do lớn khiến nó quá nhanh.
Có thể là các dự án sẽ tốt hơn khi sử dụng cả cơ sở dữ liệu hướng tài liệu và cơ sở dữ liệu quan hệ cạnh nhau cho các dữ liệu khác nhau phù hợp hơn cho cái này hay cái kia không?
Đúng. Trên thực tế, tôi đang điều hành một trang web sản xuất rất lớn sử dụng cả hai. Hệ thống đã được khởi động trong MySQL, nhưng chúng tôi đã chuyển một phần của nó sang MongoDB, b / c chúng tôi cần một kho lưu trữ Key-Value và MySQL không tốt lắm trong việc tìm kiếm một mục trong 150 triệu bản ghi.
Nếu cơ sở dữ liệu hướng tài liệu không nhằm thay thế cơ sở dữ liệu quan hệ, thì có ai có ví dụ về cấu trúc cơ sở dữ liệu sẽ tốt hơn trong cơ sở dữ liệu quan hệ (hoặc ngược lại) không?
Cơ sở dữ liệu hướng tài liệu là những dữ liệu lưu trữ tuyệt vời có thể dễ dàng chứa trong các mối quan hệ "khóa-giá trị" và đơn giản, tuyến tính "mẹ-con". Ví dụ đơn giản ở đây là những thứ như Blog và Wiki.
Tuy nhiên, cơ sở dữ liệu quan hệ vẫn có quan điểm vững chắc về những thứ như báo cáo, có xu hướng "dựa trên cơ sở".
Thành thật mà nói, tôi có thể thấy một thế giới nơi hầu hết dữ liệu được "xử lý" bởi Cơ sở dữ liệu hướng tài liệu, nhưng nơi báo cáo được thực hiện trong cơ sở dữ liệu quan hệ được cập nhật bởi Map-Reduce Jobs.
