2011-08-01 39 views
7

Mục tiêu của tôi là viết một thuật toán đường ngắn nhất cho mạng lưới đường.Cơ sở dữ liệu đồ thị có tốt hơn cho các thuật toán đường đi ngắn nhất không?

Hiện tại kiến ​​trúc của tôi giống như vậy: Tôi lưu trữ tất cả dữ liệu trong cơ sở dữ liệu PostgreSQL được kích hoạt PostGIS. Tôi thực hiện một SELECT * FROM ways, mất ít hơn 3 giây trên một bảng với 100.000 cạnh (cách) và sau đó tôi sẽ áp dụng thuật toán đường ngắn nhất (Java, Ruby hoặc bất kỳ thứ gì) cho biểu đồ đã nằm trong bộ nhớ. Thao tác thứ hai có thể mất khoảng 1,5 giây trên biểu đồ có 100.000 cạnh.

Vì vậy, phải mất:

  • 2-3 giây để tải tất cả các cách từ cơ sở dữ liệu vào bộ nhớ và tạo ra một biểu đồ (nút được lưu trữ trong một bảng với cách (cạnh));
  • 1-1,5 giây để tính đường đi ngắn nhất trên biểu đồ đã có trong bộ nhớ.

này rất giống với những gì pgRouting làm (theo tôi biết nó sử dụng C Boost để lưu trữ các đồ thị trong bộ nhớ), ngoại trừ pgRouting mất khoảng 2 giây trong tổng số để tính toán một con đường ngắn nhất trên cùng một tập dữ liệu (có , nó nhanh, nhưng nó là một hộp đen cho tôi, vì vậy tôi cần của riêng tôi).

Nhưng gần đây tôi đã tìm thấy về Cơ sở dữ liệu đồ thị và về Neo4j. Trên trang web của họ, họ tuyên bố rằng "Vẫn có thể thực hiện các tính toán này ở tốc độ thứ hai trên đồ thị của hàng triệu con đường và điểm tham chiếu trong nhiều trường hợp để từ bỏ phương pháp tiếp cận bình thường của các chỉ mục precomputing với các cửa hàng K/V và có thể đặt định tuyến vào con đường quan trọng với khả năng thích nghi với điều kiện sống và xây dựng các dịch vụ không gian cá nhân và năng động cao.

Câu hỏi đặt ra là: Cơ sở dữ liệu đồ thị có nhanh hơn với vấn đề cụ thể của tôi không?

Vấn đề có các thuộc tính sau:

  • cơ sở dữ liệu bao gồm một bảng (cách);
  • truy vấn duy nhất vào cơ sở dữ liệu là lấy tất cả các cách vào bộ nhớ (để tạo biểu đồ);
  • Tôi không cần khả năng mở rộng, tức là có khả năng biểu đồ sẽ không phát triển.

Trả lời

1

Tôi không có kinh nghiệm về cơ sở dữ liệu "đồ thị" nhưng đánh giá bởi câu hỏi của bạn tôi có một vài điều cần lưu ý.

Trước hết, câu trả lời đơn giản sẽ là "Tạo cơ sở dữ liệu biểu đồ như vậy và so sánh hiệu suất với giải pháp của bạn". Bạn có thể đo lường mức sử dụng bộ nhớ, thời gian thực hiện (tốc độ), sử dụng CPU và/hoặc các số liệu có thể khác. Điều đó sẽ cung cấp cho bạn đủ dữ liệu để đưa ra quyết định của bạn.

Lời khuyên khác của tôi là sửa đổi phương pháp của bạn. Ba thuộc tính vấn đề mà bạn mô tả (một bảng, tải tất cả đường dẫn & không cần khả năng mở rộng) áp dụng trong miền hiện tại của bạn nhưng không áp dụng trong cơ sở dữ liệu biểu đồ. Đó là một mô hình lập trình hoàn toàn khác và bạn có thể phải điều chỉnh và điều chỉnh phương pháp của mình để phù hợp với miền của những loại cơ sở dữ liệu đặc biệt đó. Việc thực hiện hoặc so sánh bất kỳ loại so sánh nào khác là không hợp lý nếu bạn đang áp dụng phương pháp tiếp cận chuẩn của mình trong môi trường không chuẩn (như cơ sở dữ liệu biểu đồ).

Tóm tắt: Dịch vấn đề của bạn theo các điều khoản của cơ sở dữ liệu biểu đồ và lập mô hình cho phù hợp.Sau khi thực hiện điều đó, hãy so sánh hiệu suất giữa hai giải pháp.

Đặt cược của tôi là, giả sử rằng bạn đã dịch & đã mô hình hóa vấn đề của bạn một cách phù hợp cho cơ sở dữ liệu biểu đồ, nó sẽ cấp cho bạn hiệu suất tốt hơn. Cách tiếp cận cổ điển của bạn về "lưu trữ-đọc-sắp xếp" là đơn giản nhưng không hiệu quả trừ khi được tối ưu hóa tích cực.

0

Cơ sở dữ liệu đồ thị có thể sẽ không tải tất cả dữ liệu của bạn vào bộ nhớ ban đầu, nhưng theo thời gian, vì những dữ liệu tốt được thiết kế để xử lý các tập dữ liệu cực lớn. Tuy nhiên, một khi dữ liệu ở đó, cơ sở dữ liệu đồ thị phải làm ít công việc hơn là cơ sở dữ liệu quan hệ để đi qua các liên kết. Điều này là bởi vì nó có thể trực tiếp truy cập các đối tượng liên quan bằng cách sử dụng danh tính của chúng, thay vì phải sử dụng các chỉ mục B-tree và (có thể) một bảng nối, vì vậy nó sẽ nhanh hơn khi các nút và các cạnh được lưu trữ.

2

Bạn chắc chắn không phải phát minh lại bánh xe nếu bạn đang sử dụng bất kỳ cơ sở dữ liệu biểu đồ nào, như Neo4j. Nhiều thuật toán đường dẫn ngắn nhất được tích hợp vào điều này và được thiết kế để xử lý độ phức tạp trong trường hợp bạn phải xem xét giới hạn tốc độ trong bất kỳ con đường cụ thể nào, đường một chiều, điểm số của đường, v.v. lần, hoặc, 100 lần. Xem xét tổng thời gian tính toán của bạn 3 giây cho 100.000 cách, nó có thể là trong vài phút cho 1M cách và trong Neo4j, phản hồi sẽ được tính bằng mili giây.

1

Bước đột phá với cơ sở dữ liệu đồ thị là không chỉ biểu diễn, nó thêm về khái niệm: định tuyến các thuật toán thỏa thuận của bạn với đồ thị quan hệ đơn (có nghĩa là đồ thị được liên kết là tất cả cùng loại) trong khi với graphdatabases bạn có một đa đồ thị có liên quan.

Điều này cho phép bạn tính toán đường đi ngắn nhất giữa các nút chỉ lấy một loại cạnh cụ thể hoặc tránh loại khác.

Để biết thêm thông tin bạn nên đọc về the algebra behind graph db và khái niệm về đường ống.

Tôi thực sự khuyên bạn nên thinkerpop dự án để bắt đầu với cơ sở dữ liệu biểu đồ.

Các vấn đề liên quan