Neo4j thay vì cơ sở dữ liệu quan hệ

Question

Tôi đang triển khai cổng web dựa trên sinatra/rails mà cuối cùng có thể có rất ít: nhiều mối quan hệ giữa các bảng/mô hình. Đây là một đội một người đàn ông và bán thời gian nhưng ứng dụng thế giới thực.

Tôi đã thảo luận thực thể của mình với một người nào đó và được khuyên nên thử neo4j. Đến từ thế giới doanh nghiệp 'không gợi cảm' thực sự, khuynh hướng của tôi là sử dụng db quan hệ cho đến khi nó ngừng mở rộng hoặc trở thành cơn ác mộng vì sharding vv và sau đó nghĩ về bất cứ điều gì khác.

TUY NHIÊN,

• Tôi đang sử dụng postgres cho lần đầu tiên trong dự án này cùng với DataMapper và nó đưa tôi thời gian để bắt đầu rất nhanh
• Tôi chỉ cố gắng ra vài điều và xây dựng sử dụng hơn các trường hợp vì vậy tôi liên tục phải cập nhật lược đồ của mình (ý tưởng tạo mẫu và phản hồi từ bản beta). Tôi sẽ không phải làm điều này trong neo4j (ngoại trừ việc thay đổi các truy vấn của tôi)
• Dường như nó rất dễ dàng để thiết lập tìm kiếm bằng cách sử dụng neo4j. Nhưng Postgres cũng có thể thực hiện tìm kiếm toàn văn.
• Postgres gần đây đã công bố hỗ trợ cho json và javascript. Tự hỏi nếu tôi chỉ nên gắn bó với PG và đầu tư thêm thời gian học PG (trong đó có một cộng đồng tốt) thay vì neo4j.

Tìm kiếm các giai đoạn nơi neo4j tốt hơn, đặc biệt là ở giai đoạn protyping/ban đầu của dự án. Tôi hiểu rằng nếu trang web phát triển, tôi có thể có nhiều công nghệ liên tục như s3, quan hệ (PG), mongo, v.v.

Ngoài ra, bạn cũng nên biết cách hoạt động với hệ sinh thái Rails/Ruby.

---

Update1:

tôi nhận được rất nhiều câu trả lời tốt và có vẻ như là điều phải làm là gắn bó với Postgres cho bây giờ (đặc biệt là kể từ khi tôi triển khai đến Heroku)

Tuy nhiên, ý tưởng về là giản đồ ít hấp dẫn hơn. Về cơ bản, tôi đang nghĩ đến cách tiếp cận mà bạn không định nghĩa một datamodel cho đến khi bạn nói 100-150 người dùng và bạn đã tìm ra một lược đồ tốt (trường hợp sử dụng nghiệp vụ) cho sản phẩm của mình, trong khi bạn chỉ giới thiệu khái niệm và nhận phản hồi với các đăng ký giới hạn. Sau đó, người ta có thể quyết định một lược đồ và bắt đầu với quan hệ.

Sẽ được tốt đẹp để biết nếu có dễ sử dụng schema/tùy chọn bền bỉ ít (dựa trên một cách dễ dàng để sử dụng/cài đặt cho người dùng mới) mà có thể từ bỏ nói rộng, vv

Answer 1

cơ sở dữ liệu đồ thị nên được xem xét nếu bạn có một mô hình dữ liệu thực sự hỗn loạn. Họ cần phải thể hiện mối quan hệ phức tạp giữa các thực thể. Để làm điều đó, chúng lưu trữ các mối quan hệ ở cấp dữ liệu trong khi RDBMS sử dụng một cách tiếp cận khai báo. Lưu trữ các mối quan hệ chỉ có ý nghĩa nếu các mối quan hệ này rất khác nhau, nếu không bạn sẽ chỉ kết thúc sao chép dữ liệu nhiều lần, chiếm nhiều không gian cho không có gì. Để yêu cầu sự đa dạng như vậy trong các mối quan hệ bạn phải xử lý lượng dữ liệu khổng lồ. Đây là nơi các cơ sở dữ liệu đồ thị tỏa sáng bởi vì instand làm hàng tấn gia nhập, họ chỉ chọn một bản ghi và theo dõi các mối quan hệ của mình. Để hỗ trợ tuyên bố của tôi: bạn sẽ nhận thấy rằng mọi use cases trên trang web của Neo4j đều đang xử lý dữ liệu rất phức tạp.

Tóm lại, nếu bạn không cảm thấy lo lắng về những gì tôi đã nói ở trên, tôi nghĩ bạn nên sử dụng một công nghệ khác.Nếu đây chỉ là về việc mở rộng quy mô, sơ đồ hoặc bắt đầu nhanh một dự án, sau đó xem xét các giải pháp NoSQL khác (cụ thể hơn, hoặc là cột hoặc cơ sở dữ liệu định hướng tài liệu). Nếu không, bạn nên gắn bó với PostgreSQL. Bạn cũng có thể, như bạn đã nói, hãy xem xét polyglot persistence,

Về bản cập nhật của bạn, bạn có thể xem xét hStore. Tôi nghĩ nó phù hợp với yêu cầu của bạn. Đó là một mô-đun PostgreSQL cũng hoạt động trên Heroku.

Answer 2

Tôi không nghĩ rằng tôi đồng ý rằng bạn chỉ nên sử dụng cơ sở dữ liệu biểu đồ khi mô hình dữ liệu của bạn rất phức tạp. Tôi chắc rằng họ cũng có thể xử lý một mối quan hệ/mô hình dữ liệu đơn giản.

Nếu bạn không có kinh nghiệm trước đó với Neo4j hoặc Postgres, thì rất có thể cả hai đều mất khá nhiều thời gian để học tốt.

Một số điều cần lưu ý khi chọn:

1. Nó không phải chỉ là về phát triển chống lại một công nghệ cơ sở dữ liệu. Bạn cũng nên xem xét triển khai. Việc triển khai và quy mô Postgres/Neo4j dễ dàng như thế nào?

2. Cân nhắc cộng đồng và công cụ xung quanh từng công nghệ. Có một trình ánh xạ dữ liệu cho Neo4j như có cho Postgres không?

3. Hãy xem xét các mô hình dữ liệu là đáng kể khác nhau giữa hai loại. Nếu bạn đã có thể suy nghĩ về mặt quan hệ, thì tôi có lẽ sẽ gắn bó với Postgres. Nếu bạn đi với Neo4j bạn sẽ làm cho rất nhiều sai lầm trong vài tháng với các mô hình dữ liệu của bạn.

4. Theo thời gian, tôi đã học cách giữ cho nó đơn giản khi có thể. Postgres có thể là sự lựa chọn nhàm chán so với Neo4j, nhưng nhàm chán không giữ bạn vào ban đêm. =)

Ngoài ra tôi chưa bao giờ thấy ai đề cập đến nó, nhưng bạn cũng nên xem Riak (http://basho.com/riak/). Đó là một cơ sở dữ liệu tài liệu cũng cung cấp các mối quan hệ (liên kết) giữa các đối tượng. Không trưởng thành như một cơ sở dữ liệu đồ thị, nhưng nó có thể kết nối một vài thực thể một cách nhanh chóng.

Answer 3

Lựa chọn phù hợp nhất phụ thuộc vào vấn đề bạn đang cố giải quyết.

Nếu bạn chỉ có một vài nhiều đến nhiều bảng, một cơ sở dữ liệu quan hệ có thể được sử dụng tốt. Nói chung, có hỗ trợ OR-mapper tốt hơn cho các cơ sở dữ liệu quan hệ, vì chúng lớn hơn nhiều và có một cấu trúc tiêu chuẩn và cấu trúc hàng-cột. Họ cũng đã được cải thiện trong một thời gian dài, vì vậy họ ổn định và tối ưu hóa cho những gì họ đang làm.

Cơ sở dữ liệu biểu đồ tốt hơn nếu ví dụ: vấn đề của bạn là nhiều hơn về các kết nối giữa các thực thể, đặc biệt nếu bạn cần các kết nối khoảng cách cao hơn, như "phát hiện chu kỳ (chiều dài không xác định)", một số "bạn bè của bạn bè" như thế nào. Những thứ như thế sẽ trở nên khó sử dụng khi bị giới hạn đối với các phép nối SQL. Một vấn đề cụ thể ngôn ngữ như cypher trong trường hợp Neo4j làm cho nhiều hơn nữa ngắn gọn. Mặt khác, có những người lập bản đồ giữa các đồ thị dbs và các đối tượng, nhưng không phải cho mọi khuôn khổ và ngôn ngữ dưới ánh mặt trời.

Gần đây tôi đã triển khai mẫu thử hệ thống bằng cách sử dụng neo4j và rất hữu ích để có thể nói về cấu trúc và kết nối dữ liệu của chúng tôi và có thể mô hình hóa dữ liệu đó. Ngoài ra, việc thêm các kết nối khác giữa các điểm dữ liệu thật dễ dàng, neo4j là một kho lưu trữ sơ đồ. Chúng tôi đã kết thúc việc chuyển sang mongodb do những rắc rối với việc thực hiện viết, nhưng tôi không nghĩ rằng chúng tôi có thể hoàn thành bản mẫu với điều đó cùng một lúc.

Kho dữ liệu NoSQL khác như dựa trên tài liệu, cột, khóa-giá trị cũng bao gồm các giai đoạn cụ thể. Polyglot persistence chắc chắn là một cái gì đó để xem xét, do đó, giữ cho sự lựa chọn của bạn phụ trợ hợp lý tách ra khỏi logic kinh doanh của bạn, để cho phép bạn thay đổi công nghệ của bạn sau này nếu bạn học được một cái gì đó mới.