Thiết kế cơ sở dữ liệu không quan hệ [đã đóng]

Tôi muốn biết về các chiến lược thiết kế mà bạn đã sử dụng với cơ sở dữ liệu "nosql" không quan hệ - nghĩa là, lớp lưu trữ dữ liệu (chủ yếu là mới) không sử dụng thiết kế quan hệ truyền thống hoặc SQL (chẳng hạn như Hypertable, CouchDB, SimpleDB, kho dữ liệu Google App Engine, Voldemort, Cassandra, Dịch vụ dữ liệu SQL, v.v.). Chúng cũng thường được gọi là "cửa hàng khóa / giá trị" và ở cơ sở chúng hoạt động giống như các bảng băm liên tục được phân phối khổng lồ.

Cụ thể, tôi muốn tìm hiểu về sự khác biệt trong thiết kế dữ liệu khái niệm với các cơ sở dữ liệu mới này. Điều gì dễ hơn, điều gì khó hơn, điều gì không thể làm được?

• Bạn đã nghĩ ra những thiết kế thay thế hoạt động tốt hơn nhiều trong thế giới phi quan hệ chưa?

• Bạn đã từng đập đầu vào bất cứ điều gì tưởng như không thể chưa?

• Bạn đã thu hẹp khoảng cách với bất kỳ mẫu thiết kế nào, ví dụ như dịch từ cái này sang cái kia chưa?

• Bạn thậm chí còn làm các mô hình dữ liệu rõ ràng bây giờ (ví dụ: trong UML) hay bạn đã hoàn toàn ủng hộ các khối dữ liệu bán cấu trúc / hướng tài liệu?

• Bạn có bỏ lỡ bất kỳ dịch vụ bổ sung chính nào mà RDBMSes cung cấp, như tính toàn vẹn quan hệ, hỗ trợ giao dịch phức tạp tùy ý, trình kích hoạt, v.v. không?

Tôi đến từ nền tảng DB quan hệ SQL, vì vậy việc chuẩn hóa đã nằm trong máu của tôi. Điều đó nói rằng, tôi nhận được những lợi thế của cơ sở dữ liệu không quan hệ về tính đơn giản và mở rộng, và ruột của tôi nói với tôi rằng phải có sự chồng chéo phong phú hơn về khả năng thiết kế. Bạn đã làm gì

FYI, đã có các cuộc thảo luận trên StackOverflow về các chủ đề tương tự ở đây:

• thế hệ cơ sở dữ liệu tiếp theo
• thay đổi lược đồ để hoạt động với Google App Engine
• chọn một cơ sở dữ liệu hướng tài liệu

Tôi nghĩ rằng bạn phải xem xét rằng DBMS không quan hệ khác nhau rất nhiều về mô hình dữ liệu của chúng và do đó thiết kế dữ liệu khái niệm cũng sẽ khác nhau rất nhiều. Trong chủ đề Thiết kế dữ liệu trong Cơ sở dữ liệu phi quan hệ của nhóm NOSQL Google , các mô hình khác nhau được phân loại như sau:

1. Các hệ thống giống như Bigtable (HBase, Hypertable, v.v.)
2. Cửa hàng giá trị chính (Tokyo, Voldemort, v.v.)
3. Cơ sở dữ liệu tài liệu (CouchDB, MongoDB, v.v.)
4. Cơ sở dữ liệu đồ thị (AllegroGraph, Neo4j, Sesame, v.v.)

Tôi chủ yếu quan tâm đến cơ sở dữ liệu đồ thị và sự sang trọng của thiết kế dữ liệu bằng cách sử dụng mô hình này là điều đã đưa tôi đến đó, mệt mỏi vì những thiếu sót của RDBMS . Tôi đã đưa một vài ví dụ về thiết kế dữ liệu bằng cách sử dụng cơ sở dữ liệu đồ thị trên trang wiki này và có một ví dụ về cách lập mô hình dữ liệu phim / diễn viên / vai diễn IMDB cơ bản .

Các slide trình bày (chia sẻ slide) Cơ sở dữ liệu đồ thị và tương lai của quản lý tri thức quy mô lớn của Marko Rodriguez có phần giới thiệu rất hay về thiết kế dữ liệu bằng cách sử dụng cơ sở dữ liệu đồ thị.

Trả lời các câu hỏi cụ thể theo quan điểm graphdb:

Thiết kế thay thế: thêm mối quan hệ giữa nhiều loại thực thể khác nhau mà không cần lo lắng hoặc cần xác định trước thực thể nào có thể được kết nối.

Thu hẹp khoảng cách: Tôi có xu hướng làm điều này khác nhau cho mọi trường hợp, dựa trên chính tên miền, vì tôi không muốn có "biểu đồ hướng bảng" và những thứ tương tự. Tuy nhiên, đây là một số thông tin về dịch tự động từ RDBMS sang graphdb.

Mô hình dữ liệu rõ ràng: Tôi luôn làm những điều này (kiểu bảng trắng), và sau đó sử dụng mô hình như trong DB.

Bỏ lỡ từ thế giới RDBMS: cách dễ dàng để tạo báo cáo. Cập nhật: có lẽ nó không phải là khó khăn để tạo ra các báo cáo từ một cơ sở dữ liệu đồ thị, xem Tạo một Báo cáo cho một cơ sở dữ liệu Neo4J mẫu .

Tôi chỉ mới bắt đầu với DB không quan hệ và tôi vẫn đang cố gắng nghiên cứu nó và tìm ra mô hình tốt nhất sẽ là gì. Và tôi chỉ có thể nói cho CouchDB.

Tuy nhiên, tôi có một số kết luận sơ bộ:

Bạn đã nghĩ ra những thiết kế thay thế hoạt động tốt hơn nhiều trong thế giới phi quan hệ chưa?

Trọng tâm thiết kế thay đổi: Thiết kế của mô hình tài liệu (tương ứng với các bảng DB) trở nên gần như không liên quan, trong khi mọi thứ xoay quanh việc thiết kế các khung nhìn (tương ứng với các truy vấn).

Loại DB tài liệu hoán đổi sự phức tạp: SQL có dữ liệu không linh hoạt và các truy vấn linh hoạt, DB tài liệu thì ngược lại.

Mô hình CouchDB là một tập hợp các "tài liệu JSON" (về cơ bản là các bảng băm lồng nhau). Mỗi tài liệu có một ID duy nhất và có thể được truy xuất bằng ID. Đối với bất kỳ truy vấn nào khác, bạn viết "khung nhìn", được đặt tên là tập hợp các hàm ánh xạ / thu gọn. Các khung nhìn trả về một tập hợp kết quả dưới dạng danh sách các cặp khóa / giá trị.

Bí quyết là bạn không truy vấn cơ sở dữ liệu theo nghĩa bạn truy vấn cơ sở dữ liệu SQL: Kết quả của việc chạy các hàm dạng xem được lưu trữ trong một chỉ mục và chỉ chỉ mục mới có thể được truy vấn. (Như "lấy mọi thứ", "lấy khóa" hoặc "nhận phạm vi khóa".)

Tương tự gần nhất trong thế giới SQL sẽ là nếu bạn chỉ có thể truy vấn DB bằng các thủ tục được lưu trữ - mọi truy vấn bạn muốn hỗ trợ phải được xác định trước.

Thiết kế của các tài liệu rất linh hoạt. Tôi chỉ tìm thấy hai hạn chế:

• Giữ các dữ liệu liên quan cùng nhau trong cùng một tài liệu, vì không có gì tương ứng với một phép nối.
• Đừng làm cho các tài liệu quá lớn để chúng được cập nhật quá thường xuyên (như đặt tất cả doanh số bán hàng của công ty trong năm vào cùng một tài liệu), vì mọi bản cập nhật tài liệu đều kích hoạt lập chỉ mục lại.

Nhưng mọi thứ đều xoay quanh việc thiết kế các khung nhìn.

Các thiết kế thay thế mà tôi đã nhận thấy rằng các thứ tự công việc có quy mô tốt hơn với CouchDB so với bất kỳ cơ sở dữ liệu SQL nào là ở cấp hệ thống hơn là cấp lưu trữ. Nếu bạn có một số dữ liệu và muốn cung cấp chúng cho một trang web, độ phức tạp của toàn bộ hệ thống sẽ giảm ít nhất 50%:

• không thiết kế bảng DB (vấn đề nhỏ)
• không có lớp trung gian ODBC / JDBC, tất cả các truy vấn và giao dịch qua http (vấn đề vừa phải)
• ánh xạ DB-tới-đối tượng đơn giản từ JSON, điều này gần như không đáng kể so với ánh xạ tương tự trong SQL (quan trọng!)
• bạn có thể bỏ qua toàn bộ máy chủ ứng dụng, vì bạn có thể thiết kế tài liệu của mình để trình duyệt truy xuất trực tiếp bằng AJAX và thêm một chút đánh bóng JavaScript trước khi chúng được hiển thị dưới dạng HTML. (KHỔNG LỒ!!)

Đối với các ứng dụng web thông thường, DB dựa trên tài liệu / JSON là một chiến thắng lớn và nhược điểm của các truy vấn kém linh hoạt và một số mã bổ sung để xác thực dữ liệu có vẻ là một cái giá nhỏ phải trả.

Bạn đã từng đập đầu vào bất cứ điều gì tưởng như không thể chưa?

Chưa. Ánh xạ / thu nhỏ như một phương tiện truy vấn cơ sở dữ liệu không quen thuộc và đòi hỏi nhiều tư duy hơn so với viết SQL. Có một số lượng khá nhỏ các nguyên tắc ban đầu, vì vậy việc nhận được kết quả bạn cần chủ yếu là vấn đề sáng tạo với cách bạn chỉ định các khóa.

Có một hạn chế là các truy vấn không thể xem hai hoặc nhiều tài liệu cùng một lúc - không có liên kết hoặc các loại mối quan hệ đa tài liệu khác, nhưng cho đến nay không có gì là không thể vượt qua.

Như một giới hạn ví dụ, việc đếm và tổng rất dễ dàng nhưng không thể tính giá trị trung bình bằng chế độ xem / truy vấn CouchDB. Khắc phục: Trả lại tổng và đếm riêng và tính giá trị trung bình trên máy khách.

Bạn đã thu hẹp khoảng cách với bất kỳ mẫu thiết kế nào, ví dụ như dịch từ cái này sang cái kia chưa?

Tôi không chắc điều đó khả thi. Nó giống như một thiết kế lại hoàn chỉnh, giống như dịch một chương trình kiểu chức năng sang kiểu hướng đối tượng. Nói chung, có ít loại tài liệu hơn nhiều so với các bảng SQL và nhiều dữ liệu hơn trong mỗi tài liệu.

Một cách để nghĩ về nó là xem SQL của bạn để biết các chèn và các truy vấn phổ biến: Ví dụ: bảng và cột nào được cập nhật khi khách hàng đặt hàng? Và cái nào cho báo cáo bán hàng hàng tháng? Thông tin đó có lẽ nên đi trong cùng một tài liệu.

Đó là: Một tài liệu cho Đơn đặt hàng, chứa ID khách hàng và ID sản phẩm, với các trường được sao chép nếu cần để đơn giản hóa các truy vấn. Bất kỳ thứ gì trong tài liệu đều có thể được truy vấn dễ dàng, bất kỳ thứ gì yêu cầu tham chiếu chéo giữa Đơn đặt hàng và Khách hàng phải được thực hiện bởi khách hàng. Vì vậy, nếu bạn muốn có một báo cáo về doanh số bán hàng theo khu vực, có lẽ bạn nên đặt mã vùng vào đơn đặt hàng.

Bây giờ bạn có thực hiện các mô hình dữ liệu rõ ràng không (ví dụ: trong UML)?

Xin lỗi, chưa bao giờ làm nhiều UML trước các DB tài liệu :)

Nhưng bạn cần một số loại mô hình cho biết trường nào thuộc tài liệu nào và chúng chứa những loại giá trị nào. Cả hai đều để bạn tham khảo sau này và để đảm bảo rằng mọi người sử dụng DB đều biết các quy ước. Ví dụ: vì bạn không còn gặp lỗi nếu bạn lưu trữ ngày trong trường văn bản và bất kỳ ai cũng có thể thêm hoặc xóa bất kỳ trường nào mà họ cảm thấy thích, nên bạn cần cả mã xác thực và quy ước để giải quyết vấn đề. Đặc biệt nếu bạn làm việc với các nguồn lực bên ngoài.

Bạn có bỏ lỡ bất kỳ dịch vụ bổ sung chính nào mà RDBMSes cung cấp không?

Không. Nhưng nền tảng của tôi là nhà phát triển ứng dụng web, chúng tôi chỉ xử lý cơ sở dữ liệu trong phạm vi mà chúng tôi phải :)

Một công ty mà tôi từng làm việc đã tạo ra một sản phẩm (ứng dụng web) được thiết kế để chạy trên cơ sở dữ liệu SQL từ nhiều nhà cung cấp và các "dịch vụ bổ sung" rất khác nhau giữa DB với DB đến nỗi chúng phải được triển khai riêng cho từng DB. Vì vậy, việc di chuyển chức năng ra khỏi RDBMS sẽ ít công việc hơn đối với chúng tôi. Điều này thậm chí còn mở rộng sang tìm kiếm toàn văn bản.

Vì vậy, bất cứ điều gì tôi đang từ bỏ là điều mà tôi chưa bao giờ thực sự có được ngay từ đầu. Rõ ràng, trải nghiệm của bạn có thể khác.

Lưu ý: Những gì tôi đang làm bây giờ là một ứng dụng web cho dữ liệu tài chính, báo giá cổ phiếu và những thứ tương tự. Đây là một kết hợp rất tốt cho một DB tài liệu, theo quan điểm của tôi, tôi nhận được tất cả những lợi ích của một DB (tính bền bỉ và truy vấn) mà không gặp bất kỳ rắc rối nào.

Nhưng các dữ liệu này khá độc lập với nhau, không có các truy vấn quan hệ phức tạp. Nhận báo giá mới nhất theo mã, nhận báo giá theo mã và phạm vi ngày, nhận thông tin meta của công ty, đó là tất cả. Một ví dụ khác mà tôi đã thấy là một ứng dụng blog và các blog cũng không được đặc trưng bởi các lược đồ cơ sở dữ liệu phức tạp.

Điều tôi đang cố gắng nói là tất cả các ứng dụng thành công của DB tài liệu mà tôi biết đều có dữ liệu không có nhiều mối liên hệ với nhau ngay từ đầu: Tài liệu (như trong tìm kiếm của Google), bài đăng trên blog, tin bài, dữ liệu tài chính .

Tôi hy vọng rằng có những bộ dữ liệu ánh xạ tốt hơn tới SQL hơn là mô hình tài liệu, vì vậy tôi tưởng tượng rằng SQL sẽ tồn tại.

Nhưng đối với những người trong chúng ta chỉ muốn một cách đơn giản để lưu trữ và truy xuất dữ liệu - và tôi nghi ngờ rằng có nhiều người trong chúng ta - cơ sở dữ liệu tài liệu (như trong CouchDB) là một món quà trời cho.

Tôi đang trả lời điều này với CouchDB trong tâm trí của mình, nhưng tôi cho rằng hầu hết sẽ đúng với các DB khác. Chúng tôi đã xem xét sử dụng CouchDB, nhưng cuối cùng quyết định chống lại nó vì quyền truy cập dữ liệu của chúng tôi không được biết trước và khả năng mở rộng không phải là vấn đề.

Khó hơn:

• Suy nghĩ lại về cấp độ khái niệm vì vậy nó 'khó hơn' vì nó chỉ khác nhau. Vì bạn phải biết trước các kiểu truy cập dữ liệu của mình nên không thể áp dụng dịch tự động. Bạn sẽ cần thêm ít nhất mẫu truy cập.
• Tính nhất quán không được xử lý bởi cơ sở dữ liệu mà phải được xử lý trong ứng dụng. Ít đảm bảo hơn đồng nghĩa với việc di chuyển dễ dàng hơn, vượt qua lỗi và khả năng mở rộng tốt hơn với chi phí của một ứng dụng phức tạp hơn. Một ứng dụng phải đối phó với những xung đột và mâu thuẫn.
• Các liên kết mà các tài liệu chéo (hoặc khóa / giá trị) cũng phải được xử lý ở cấp ứng dụng.
• Loại cơ sở dữ liệu SQL có IDE đã trưởng thành hơn nhiều. Bạn nhận được rất nhiều thư viện hỗ trợ (mặc dù việc phân lớp các thư viện đó khiến mọi thứ trở nên phức tạp hơn nhiều so với mức cần thiết cho SQL).

Dễ dàng hơn:

• Nhanh hơn nếu bạn biết các kiểu truy cập dữ liệu của mình.
• Cơ sở dữ liệu dễ dàng di chuyển / chuyển lỗi hơn vì không có lời hứa nào được thực hiện cho bạn với tư cách là một lập trình viên ứng dụng. Mặc dù bạn nhận được sự nhất quán cuối cùng. Có lẽ. Cuối cùng. Thỉnh thoảng.
• Một khóa / giá trị dễ hiểu hơn nhiều so với một hàng trong bảng. Tất cả các quan hệ (cây) đều đã có sẵn và các đối tượng hoàn chỉnh có thể được nhận dạng.

Mô hình phải giống nhau nhưng bạn phải cẩn thận về những gì bạn đưa vào một tài liệu: UML cũng có thể được sử dụng cho cả mô hình OO cũng như mô hình DB, vốn là hai con thú khác nhau.

Tôi muốn thấy một cơ sở dữ liệu OO mở tốt được tích hợp độc đáo với C # / Silverlight. Chỉ để làm cho sự lựa chọn thậm chí còn khó khăn hơn. :)

Các tệp phẳng từ lâu đã được coi là phức tạp và không thực tế đối với một tập dữ liệu có kích thước bất kỳ. Tuy nhiên, các máy tính nhanh hơn với nhiều bộ nhớ hơn giúp bạn có thể tải tệp vào bộ nhớ và sắp xếp tệp đó theo thời gian thực, ít nhất là đối với các ứng dụng đơn người dùng nhỏ và cục bộ.

Ví dụ: bạn thường có thể đọc một tệp gồm 10.000 bản ghi VÀ sắp xếp nó trên một trường trong vòng chưa đầy nửa giây, thời gian phản hồi có thể chấp nhận được.

Tất nhiên, có những lý do để sử dụng cơ sở dữ liệu thay vì tệp phẳng - các phép toán quan hệ, tính toàn vẹn dữ liệu, khả năng đa người dùng, truy cập từ xa, dung lượng lớn hơn, tiêu chuẩn hóa, v.v., nhưng tốc độ máy tính và dung lượng bộ nhớ tăng lên đã thực hiện thao tác trong bộ nhớ dữ liệu thực tế hơn trong một số trường hợp.

Các cơ sở dữ liệu quan hệ mà tôi thấy trong cuộc sống thực có xu hướng không được chuẩn hóa rất tốt, trái ngược với tuyên bố của bạn. Khi được hỏi, các nhà thiết kế nói với tôi rằng phần lớn là do hiệu suất. RDBM không tốt trong việc kết hợp, vì vậy các bảng có xu hướng quá rộng theo quan điểm bình thường hóa. Cơ sở dữ liệu hướng đối tượng có xu hướng tốt hơn nhiều.

Một điểm khác mà RDBM có vấn đề là xử lý lịch sử / khóa phụ thuộc thời gian.