Có lý do gì để không sử dụng OrientDB không?

Question

Tôi đã thử nghiệm với nhiều cơ sở dữ liệu noSQL. Tôi chỉ 'vấp' trên OrientDB, mà rõ ràng là lai của lưu trữ tài liệu như MongoDB và cơ sở dữ liệu biểu đồ chẳng hạn như Neo4j.

Tôi đọc trong một số blog mà OrientDB thực hiện ít nhất là tốt, nếu không tốt hơn, hơn Neo4j, trong khi cũng cung cấp các loại phức tạp hơn như MongoDB sẽ.

là có lý do nào để lựa chọn một trong hai MongoDB hoặc Neo4j? Bắt là gì? Tôi đang thiếu gì? Làm thế nào để so sánh với việc sử dụng MongoDB để lưu trữ tài liệu cùng với Neo4j để lưu trữ đồ thị (ví dụ, dữ liệu người dùng trong MongoDB, các mối quan hệ trong Neo4j)?

Answer 1

Lý do chính: Lỗi, rất nhiều trong số đó.

Lý do phụ: Thiếu tài liệu thích hợp. Lần trước chúng tôi đã cố gắng sử dụng Phương Đông không thể sử dụng ở quy mô trong môi trường sản xuất. Tại sao? Đơn giản là vì chúng tôi không thể di chuyển ra ngoài chế độ phát triển. Chúng tôi thậm chí không thể di chuyển nó để thử nghiệm. Các lỗi đó là gì? Bạn có thể đọc các diễn đàn về tất cả những người hoặc chỉ google "lỗi" "orientdb". Có nói rằng, công nghệ này có vẻ hứa hẹn và chúng tôi có thể cung cấp cho nó một đi trong hai năm khi nó trưởng thành hơn.

Tại sao có quá nhiều lỗi?

Như ai đó đã nói, một db lai là một điều phức tạp để giải quyết, rất nhiều chỗ cho lỗi. Nó khó.

khía cạnh khác là Orient đã cố gắng để xây dựng quá nhiều tính năng thay vì ổn định và làm sạch những cái hiện có. Tại sao họ làm điều này? Tôi đoán đó là vấn đề định giá của công ty và thời gian ra thị trường.

Answer 2

(Disclaimer: Tôi là người sáng lập của dự án OrientDB)

Ngay cả khi khoảng 50% số người dùng đang sử dụng OrientDB OrientDB như một cơ sở dữ liệu đồ thị (một sự thay thế cho Neo4j), ý tưởng đằng sau OrientDB là xây dựng cơ sở dữ liệu Mô hình đa nguồn mở đầu tiên. 6 năm trước, từ "Multi-Model" không tồn tại, nhưng giờ đây các nhà cung cấp DBMS như DataStax (Cassandra), MongoDB và CouchBase đang trở thành Multi-Model hoặc họ đã công bố là Multi-Model trong tương lai sắp tới. Đây là, tất nhiên, một xác nhận của khái niệm đa mô hình OrientDB đã tạo ra một thời gian dài trước đây.

Điều đó nói rằng, ngay từ đầu, mục tiêu của OrientDB là không có "chỉ là" một cơ sở dữ liệu Graph siêu ổn định, nhưng thay vì thử nghiệm với khái niệm Multi-Mẫu. Vì vậy, một phần đúng là nhóm nghiên cứu tập trung vào việc thêm các mô hình mới (bạn có thể xem chúng như các tính năng) so với việc làm cho đá cứng OrientDB và siêu dễ sử dụng cho người mới bắt đầu.

Tuy nhiên, hàng ngàn công ty đã sản xuất với OrientDB. Hãy xem Success Stories và Press, chỉ để đặt tên cho một vài người trong số họ.

Bắt đầu từ phiên bản 2.2, đội ưu tiên OrientDB được thay đổi: bây giờ mà các khái niệm Multi-Model là ổn định, đã đến lúc phải làm OrientDB siêu đá rắn. Nếu bạn đã thử OrientDB trước 2.2, tôi khuyên bạn nên tạo cơ hội cho OrientDB v.2.2.x.Để giúp người dùng mới, documentation cũng đã được cải thiện để sử dụng cho người mới bắt đầu.

OrientDB có hoàn hảo không? Không có DBMS nào không có lỗi, nhưng OrientDB có một trong các lỗi thấp nhất so với các DBMS khác. Hãy xem Let's Talk about OrientDB Stability, Code Coverage and Bugs (bài đăng đó không được cập nhật: nó báo cáo 343 lỗi nhưng, hôm nay kiểm tra số lỗi mở cho dự án OrientDB là 254. Tôi không kiểm tra xem các DBMS khác là một phần của điểm chuẩn đã cải thiện số liệu của chúng chưa.)

Nếu bạn đã có kinh nghiệm với Neo4j, OrientDB nên khá dễ sử dụng. Nếu bạn sử dụng tiêu chuẩn TinkerPop/Gremlin, OrientDB là một sự thay thế thả, nếu không, nó đòi hỏi một số công việc, đặc biệt là dịch Cypher sang OrientDB SQL (sử dụng toán tử OrientDB MATCH!). Nhiều người dùng đã chuyển sang OrientDB từ Neo4j và họ báo cáo hiệu suất có thể so sánh hoặc thậm chí tốt hơn.

Đề xuất của tôi là: thử OrientDB v2.2.x. Nếu quá phức tạp hoặc không hoạt động tốt cho trường hợp sử dụng của bạn, vui lòng không thả ngay lập tức, nhưng hãy cố gắng yêu cầu trợ giúp trên StackOverflow hoặc trước tiên là Community Group.