Các trường hợp sử dụng Cơ sở dữ liệu dựa trên đồ thị (http://neo4j.org/) là gì? [đóng cửa]

Tôi đã sử dụng DB quan hệ rất nhiều và quyết định mạo hiểm với các loại khác có sẵn.

Sản phẩm đặc biệt này có vẻ tốt và đầy hứa hẹn: http://neo4j.org/

Có ai đã sử dụng cơ sở dữ liệu dựa trên đồ thị? Những ưu và nhược điểm từ một quan điểm khả năng sử dụng là gì?

Bạn đã sử dụng chúng trong một môi trường sản xuất? Yêu cầu khiến bạn sử dụng chúng là gì?

Tôi đã sử dụng một cơ sở dữ liệu đồ thị trong một công việc trước đây. Chúng tôi không sử dụng neo4j, đó là một thứ trong nhà được xây dựng trên đỉnh Berkeley DB, nhưng nó cũng tương tự. Nó đã được sử dụng trong sản xuất (nó vẫn còn).

Lý do chúng tôi sử dụng cơ sở dữ liệu đồ thị là dữ liệu được lưu trữ bởi hệ thống và các hoạt động mà hệ thống đang thực hiện với dữ liệu chính xác là điểm yếu của cơ sở dữ liệu quan hệ và chính xác là điểm mạnh của cơ sở dữ liệu đồ thị. Hệ thống cần thiết để lưu trữ các bộ sưu tập các đối tượng thiếu lược đồ cố định và được liên kết với nhau bằng các mối quan hệ. Để giải thích về dữ liệu, hệ thống cần thực hiện nhiều thao tác có thể là một vài giao dịch trong cơ sở dữ liệu đồ thị, nhưng đó sẽ là các truy vấn khá phức tạp trong SQL.

Ưu điểm chính của mô hình đồ thị là thời gian phát triển nhanh và tính linh hoạt. Chúng tôi có thể nhanh chóng thêm chức năng mới mà không ảnh hưởng đến việc triển khai hiện có. Nếu một khách hàng tiềm năng muốn nhập một số dữ liệu của riêng họ và ghép nó lên trên mô hình của chúng tôi, thì nó thường có thể được thực hiện trên trang web bởi đại diện bán hàng. Tính linh hoạt cũng giúp ích khi chúng tôi thiết kế một tính năng mới, giúp chúng tôi không phải cố gắng ép dữ liệu mới vào một mô hình dữ liệu cứng nhắc.

Có một cơ sở dữ liệu kỳ lạ cho phép chúng tôi xây dựng rất nhiều công nghệ kỳ lạ khác, cho chúng tôi nhiều nước sốt bí mật để phân biệt sản phẩm của chúng tôi với các đối thủ cạnh tranh.

Nhược điểm chính là chúng tôi không sử dụng công nghệ cơ sở dữ liệu quan hệ tiêu chuẩn, đây có thể là một vấn đề khi khách hàng của bạn là khách hàng tiềm năng. Khách hàng của chúng tôi sẽ hỏi tại sao chúng tôi không thể lưu trữ dữ liệu của chúng tôi trên các cụm Oracle khổng lồ của họ (khách hàng của chúng tôi thường có các trung tâm dữ liệu lớn). Một trong nhóm thực sự viết lại lớp cơ sở dữ liệu để sử dụng Oracle (hoặc PostgreSQL hoặc MySQL), nhưng nó chậm hơn một chút so với ban đầu. Ít nhất một doanh nghiệp lớn thậm chí có chính sách chỉ dành cho Oracle, nhưng may mắn thay, Oracle đã mua Berkeley DB. Chúng tôi cũng đã phải viết rất nhiều công cụ bổ sung - chúng tôi không thể chỉ sử dụng Báo cáo Pha lê chẳng hạn.

Nhược điểm khác của cơ sở dữ liệu đồ thị của chúng tôi là chúng tôi tự xây dựng nó, điều đó có nghĩa là khi chúng tôi gặp sự cố (thường là với khả năng mở rộng), chúng tôi phải tự giải quyết. Nếu chúng tôi đã sử dụng một cơ sở dữ liệu quan hệ, nhà cung cấp đã giải quyết vấn đề mười năm trước.

Nếu bạn đang xây dựng một sản phẩm cho khách hàng yêu thích và dữ liệu của bạn phù hợp với mô hình quan hệ, hãy sử dụng cơ sở dữ liệu quan hệ nếu bạn có thể. Nếu ứng dụng của bạn không phù hợp với mô hình quan hệ nhưng nó phù hợp với mô hình đồ thị, hãy sử dụng cơ sở dữ liệu đồ thị. Nếu nó chỉ phù hợp với một cái gì đó khác, sử dụng đó.

Nếu ứng dụng của bạn không cần phải phù hợp với kiến ​​trúc blub hiện tại, hãy sử dụng cơ sở dữ liệu đồ thị hoặc CouchDB hoặc BigTable hoặc bất cứ thứ gì phù hợp với ứng dụng của bạn và bạn nghĩ là tuyệt vời. Nó có thể cung cấp cho bạn một lợi thế và thú vị để thử những điều mới.

Dù bạn chọn gì, hãy cố gắng không tự xây dựng công cụ cơ sở dữ liệu trừ khi bạn thực sự thích xây dựng công cụ cơ sở dữ liệu.

Chúng tôi đã làm việc với nhóm Neo hơn một năm nay và đã rất hạnh phúc. Chúng tôi mô hình các tạo phẩm học thuật và các mối quan hệ của chúng, được phát hiện trên một biểu đồ db và chạy các thuật toán đề xuất qua mạng.

Nếu bạn đã làm việc với Java, tôi nghĩ rằng việc lập mô hình bằng Neo4j rất đơn giản và nó có hiệu suất nhanh nhất / nhanh nhất cho R / W của bất kỳ giải pháp nào khác mà chúng tôi đã thử.

Thành thật mà nói, tôi có một thời gian khó khăn khi không nghĩ về Biểu đồ / Mạng vì nó dễ dàng hơn nhiều so với việc thiết kế các cấu trúc bảng phức tạp để giữ các thuộc tính và mối quan hệ của đối tượng.

Điều đó đang được nói, chúng tôi lưu trữ một số thông tin trong MySQL đơn giản vì phía Doanh nghiệp dễ dàng chạy các truy vấn SQL nhanh hơn. Để thực hiện các chức năng tương tự với Neo, chúng ta sẽ cần viết mã mà đơn giản là chúng ta không có băng thông ngay bây giờ. Ngay sau khi chúng tôi làm, tôi sẽ chuyển tất cả dữ liệu đó sang Neo!

Chúc may mắn.

Hai điểm:

Đầu tiên, về dữ liệu tôi đã làm việc với 5 năm qua trong SQL Server, gần đây tôi đã gặp phải vấn đề về khả năng mở rộng với SQL cho loại truy vấn chúng tôi cần chạy (lồng nhau relationhsips ... bạn biết ... biểu đồ ). Tôi đã chơi xung quanh với neo4j và thời gian tra cứu của tôi nhanh hơn nhiều lần khi tôi cần loại tra cứu này.

Thứ hai, đến mức cơ sở dữ liệu đồ thị đã lỗi thời. À, không. Ban đầu, khi mọi người đang cố gắng tìm ra cách lưu trữ và tra cứu dữ liệu hiệu quả, họ đã tạo và chơi với các mô hình cơ sở dữ liệu kiểu đồ thị và mạng. Chúng được thiết kế sao cho mô hình vật lý phản ánh mô hình logic, vì vậy hiệu quả của chúng không lớn. Kiểu cấu trúc dữ liệu này tốt cho dữ liệu bán cấu trúc, nhưng không tốt cho dữ liệu dày đặc có cấu trúc. Vì vậy, anh chàng IBM tên Codd này đã nghiên cứu các cách hiệu quả để sắp xếp và lưu trữ dữ liệu có cấu trúc và đưa ra ý tưởng cho mô hình cơ sở dữ liệu quan hệ. Và nó là tốt, và mọi người đã hạnh phúc.

Chúng ta có gì ở đây? Hai công cụ cho hai mục đích khác nhau. Các mô hình cơ sở dữ liệu đồ thị rất tốt để biểu diễn dữ liệu bán cấu trúc và các mối quan hệ giữa các thực thể (có thể tồn tại hoặc không tồn tại). Cơ sở dữ liệu quan hệ tốt cho dữ liệu có cấu trúc có lược đồ rất tĩnh và nơi độ sâu nối không đi sâu. Một loại tốt cho một loại dữ liệu, loại kia tốt cho các loại dữ liệu khác.

Để đồng xu cụm từ, không có Silver Bullet. Rất ngắn gọn để nói rằng các mô hình cơ sở dữ liệu đồ thị đã lỗi thời và để sử dụng một mô hình cho ra 40 năm tiến bộ. Điều đó giống như nói rằng sử dụng C đang từ bỏ tất cả các tiến bộ công nghệ mà chúng tôi đã trải qua để có được những thứ như Java và C #. Điều đó không đúng mặc dù. C là một công cụ cần thiết cho một số nhiệm vụ nhất định. Và Java là một công cụ cho các nhiệm vụ khác.

Tôi đã sử dụng MySQL trong nhiều năm để quản lý dữ liệu kỹ thuật và nó hoạt động tốt, nhưng một trong những vấn đề chúng tôi gặp phải (nhưng không nhận ra chúng tôi có) là chúng tôi luôn phải lên kế hoạch cho sơ đồ. Một vấn đề khác mà chúng tôi biết là chúng tôi đã ánh xạ dữ liệu lên các đối tượng miền và ngược lại.

Bây giờ chúng tôi mới bắt đầu dùng thử neo4j và có vẻ như nó đang giải quyết cả hai vấn đề cho chúng tôi. Khả năng thêm các thuộc tính khác nhau cho mỗi nút (và quan hệ) đã cho phép chúng tôi suy nghĩ lại toàn bộ cách tiếp cận dữ liệu của chúng tôi. Nó giống như ngôn ngữ động so với ngôn ngữ tĩnh (Ruby so với Java), nhưng đối với cơ sở dữ liệu. Xây dựng mô hình dữ liệu trong cơ sở dữ liệu có thể được thực hiện theo cách linh hoạt và linh hoạt hơn nhiều, và điều đó đơn giản hóa đáng kể mã của chúng tôi.

Và vì mô hình đối tượng trong mã nói chung là một cấu trúc biểu đồ, ánh xạ từ cơ sở dữ liệu cũng đơn giản hơn, với ít mã hơn và do đó ít lỗi hơn.

Và như một phần thưởng bổ sung, mã nguyên mẫu ban đầu của chúng tôi để tải dữ liệu của chúng tôi vào neo4j thực sự hoạt động nhanh hơn phiên bản MySQL trước đó. Tôi không có số liệu chắc chắn về điều này (chưa), nhưng đó là một tính năng bổ sung tốt đẹp.

Nhưng vào cuối ngày, sự lựa chọn có lẽ nên dựa chủ yếu vào bản chất của mô hình miền của bạn. Nó ánh xạ tốt hơn đến các bảng hoặc biểu đồ? Quyết định bằng cách thực hiện một số nguyên mẫu, tải dữ liệu và chơi với nó. Sử dụng neoclipse để xem các chế độ xem khác nhau của dữ liệu. Một khi bạn đã làm điều đó, hy vọng bạn biết nếu bạn đang làm một điều tốt hay không.

Tôi đang xây dựng một mạng nội bộ tại công ty của tôi.

Tôi muốn tìm hiểu cách tải dữ liệu được lưu trữ trong các bảng (Oracle, MySQL, SQL Server, Excel, Access, các danh sách ngẫu nhiên khác nhau) và tải nó vào Neo4J hoặc một số cơ sở dữ liệu đồ thị khác. Cụ thể, điều gì xảy ra khi dữ liệu phổ biến chồng lấp dữ liệu hiện có trong hệ thống.

Vâng, tôi biết một số dữ liệu được mô hình hóa tốt nhất trong RDBMS, nhưng tôi có ý tưởng này làm tôi khó chịu, rằng khi bạn cần chồng lên một số bảng riêng biệt, mô hình biểu đồ tốt hơn cấu trúc bảng.

Chẳng hạn, tôi làm việc trong môi trường sản xuất. Có một dự án lớn mà chúng tôi đang thực hiện và vì sự phức tạp, mỗi bộ phận đã tạo ra một bảng tính Excel riêng biệt có phân cấp BOM (Bill Of Vật liệu) trong một cột bên trái và sau đó một số cột ghi chú và kiểm tra được thực hiện bởi các cá nhân người đã làm những tờ này.

Vì vậy, một trong những vấn đề là hợp nhất tất cả các ghi chú này lại với nhau thành một "khung nhìn" để ai đó có thể thấy tất cả các vấn đề cần được giải quyết trong bất kỳ phần cụ thể nào.

Vấn đề thứ hai là một bảng tính Excel không thể hiện được BOM phân cấp khi một thành phần phổ biến được sử dụng trong nhiều lần phân chia. Có nghĩa là, nếu ai đó viết một ghi chú về rơle P34 trong bộ phận đánh lửa, thì cùng một nhận xét nên được liên kết với rơle P34 được sử dụng trong bộ phụ của trình điều khiển động cơ. Điều này sẽ không xảy ra trong bảng tính excel.

Đối với mạng nội bộ của công ty, tôi muốn có thể tìm kiếm mọi thứ một cách dễ dàng. Chẳng hạn như dữ liệu liên quan đến số phần, cấu trúc BOM, số điện thoại, địa chỉ email, chính sách của công ty hoặc thủ tục. Tôi thậm chí muốn mở rộng điều này để quản lý tài sản phần cứng máy tính và cài đặt phần mềm.

Tôi hình dung rằng một khi mạng thông tin bắt đầu được phổ biến, bạn có thể bắt đầu thực hiện các giao dịch thú vị như "Tôi muốn viết email cho mọi người làm việc trong dự án XYZ". Mọi người sẽ được liên kết với dự án vì họ sẽ được gắn thẻ là tạo và sửa đổi dữ liệu trong dự án XYZ. Vì vậy, bằng cách sử dụng dự án XYZ làm khóa tìm kiếm, một bộ lớn với mọi thứ liên quan đến dự án XYZ sẽ được tạo. Bao gồm các liên kết đến những người đã xây dựng dự án XYZ. Các liên kết mọi người sẽ kết nối với địa chỉ email của họ. Vì vậy, bằng cách tham gia vào dự án XYZ, chúng sẽ được đưa vào email của tôi. Điều này trái ngược hoàn toàn với một số thư ký đang cố gắng duy trì một danh sách những người làm việc trong dự án. Chúng tôi tạo ra rất nhiều danh sách. Chúng tôi dành nhiều thời gian để duy trì danh sách và đảm bảo chúng được cập nhật.

Một phiên bản thú vị khác có thể báo cáo tất cả các máy tính có cài đặt một phần mềm nhất định theo phiên bản. Báo cáo đó có thể được sử dụng để tạo các tác vụ để loại bỏ các bản sao bổ sung của phần mềm cũ và cập nhật những người cần có bản sao mới nhất. Nó cũng sẽ hữu ích cho việc theo dõi giấy phép.

Đây là một bài viết hay nói về các nhu cầu mà cơ sở dữ liệu không liên quan đáp ứng: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Nó làm rất tốt khi chỉ ra (ngoài cái tên) rằng cơ sở dữ liệu quan hệ không có lỗi hoặc sai, chỉ là ngày nay mọi người bắt đầu xử lý ngày càng nhiều dữ liệu trong phần mềm và trang web chính thống, và cơ sở dữ liệu quan hệ đó sẽ không mở rộng cho những nhu cầu này

có thể hơi muộn, nhưng ngày càng có nhiều dự án sử dụng Neo4j, những dự án được biết đến nhiều hơn được liệt kê tại Neo4j . Ngoài ra NeoT Technology, công ty đằng sau Neo4j, có một số tài liệu tham khảo tại trang khách hàng của họ

_{Lưu ý: Tôi là thành viên của nhóm Neo4j}