2010-12-11 37 views
5

Tôi sẵn sàng lưu trữ Biểu đồ bất động sản vào HBase. Biểu đồ thuộc tính là một nút biểu đồ và cạnh có thuộc tính và nhiều cạnh có thể liên kết cùng một bộ nút miễn là các cạnh thuộc về các loại khác nhau.Datamodel cho Biểu đồ bất động sản trên HBase/Cassandra

Mẫu truy vấn của tôi sẽ yêu cầu thuộc tính và vùng lân cận hoặc duyệt qua biểu đồ. Một ví dụ là: Vertex [name = claudio] => OutgoingEdge [biết] => Vertex [gender = female], sẽ cho tôi tất cả những người phụ nữ mà claudio thích.

Tôi biết rằng cơ sở dữ liệu biểu đồ chỉ thực hiện việc này, nhưng chúng thường không mở rộng trên nhiều nút trong trường hợp một tập dữ liệu khổng lồ. Vì vậy, tôi sẵn sàng để thực hiện điều này trên một NoSQL ColumnStore (HBase, Cassandra ...)

Datamodel của tôi tuân theo.

Vertices Bảng:
chính: vertexid (uuid)
Gia đình "Properties:": < tên thuộc tính > => < giá trị tài sản > ...
Gia đình "OutgoingEdges:": < cạnh chủ chốt > => < khác vertexid > ...
gia đình "IncomingEdges:": tương tự như các cạnh đi ...

bảng này cho phép tôi để lấy nhanh chóng các thuộc tính của một đỉnh và danh sách kề của nó. Tôi không thể sử dụng vertexid làm điểm cuối khác vì nhiều cạnh (với các loại khác nhau) có thể kết nối hai đỉnh giống nhau.

Edges Bảng:
chính: chìa khóa cạnh (composite (< nguồn vertexid >, < điểm đến vertexid >, < cạnh typename >)) (tức là vertexid1_vertexid2_knows)
Gia đình "Properties:": tên < bất động sản > => < giá trị thuộc tính >, ...

Bảng này cho phép tôi tìm nạp nhanh các thuộc tính của cạnh.

Edges loại:
chính: composite (< nguồn vertexid >, "ra | trong", < cạnh typename >) (tức là vertexid1_out_knows)
Gia đình "Hàng xóm:": < điểm đến vertexid > => null, ...

Bảng này cho phép tôi tìm kiếm/quét các cạnh có hoặc là hoặc đi từ đỉnh và thuộc loại cụ thể và sẽ là lõi của traversin g khả năng của API (vì vậy tôi muốn nó nhanh như có thể cả về mặt mạng I/O (RPC), đĩa I/O (tìm kiếm)). Nó cũng nên "tỷ lệ" trên kích thước của biểu đồ, có nghĩa là với sự tăng trưởng của biểu đồ chi phí của loại hoạt động này phụ thuộc vào số cạnh ra khỏi đỉnh chứ không phải trên tổng số của đỉnh và cạnh. Ví dụ trên tôi muốn xem xét vertexid1 đỉnh nguồn với tên thuộc tính: claudio tôi muốn quét vertexid1_out_knows và nhận danh sách các đỉnh được kết nối. Sau đó tôi có thể quét trên cột "Thuộc tính: giới tính" trên các đỉnh này và tìm những người có giá trị "nữ" .

Câu hỏi:

1) chung: Bạn có nhìn thấy một mô hình dữ liệu tốt hơn cho các hoạt động của tôi?
2) Tôi có thể phù hợp với mọi thứ trong một bảng cho một số khóa nhất định không. Một số gia đình sẽ trống (nghĩa là gia đình "OutgoingEdges:" sẽ không làm cho ý nghĩa của các cạnh đó) là ? Tôi muốn rằng vì bạn có thể thấy tất cả các phím được tạo thành bởi tiền tố uuid đỉnh, vì vậy chúng sẽ rất nhỏ gọn và phù hợp chủ yếu trên cùng một máy chủ vùng.
3) Tôi đoán rằng đối với quá trình quét, tôi sẽ sử dụng rộng rãi các Bộ lọc. Tôi đoán regexp Lọc sẽ là bạn của tôi. Bạn có lo ngại về hiệu suất của các bộ lọc được áp dụng cho mô hình dữ liệu này không?

Trả lời

2

Loại mô hình này trông giống như điểm khởi đầu hợp lý cho Cassandra (không biết nhiều về HBase) - nhưng đối với bất kỳ cửa hàng phân phối nào, bạn sẽ gặp phải vấn đề khi đi ngang, bởi vì traversals sẽ vượt qua nhiều nút.

Đây là lý do tại sao các cơ sở dữ liệu đồ thị chuyên dụng như Neo4J sử dụng thiết kế một nút và cố gắng giữ tất cả dữ liệu trong RAM.

Tìm kiếm các thuộc tính của các nút hoặc cạnh cụ thể sẽ hoạt động tốt và mở rộng theo chiều ngang - FlockDB của Twitter (hiện bị bỏ qua) là một ví dụ đáng chú ý về điều này.

Bạn cũng cần cân nhắc xem bạn có cần tìm kiếm khác ngoài ID (tức là bạn cần bất kỳ chỉ mục nào) không?

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