🥇Điều gì đang xảy ra với kho lưu trữ RDF?

Web ngữ nghĩa và dữ liệu liên kết giống như không gian bên ngoài: không có sự sống ở đó. Để đến đó trong một khoảng thời gian ít nhiều dài... Tôi không biết khi còn nhỏ họ đã nói gì với bạn khi đáp lại câu "Tôi muốn trở thành phi hành gia". Nhưng bạn có thể quan sát những gì đang xảy ra khi ở trên Trái đất; Việc trở thành một nhà thiên văn nghiệp dư hoặc thậm chí là một nhà thiên văn học chuyên nghiệp sẽ dễ dàng hơn nhiều.

Bài viết sẽ tập trung vào các xu hướng gần đây, không quá vài tháng, từ thế giới lưu trữ RDF. Phép ẩn dụ trong đoạn đầu tiên được lấy cảm hứng từ hình ảnh quảng cáo có kích thước hoành tráng dưới phần cắt.

Bức tranh sử thi

I. GraphQL để truy cập RDF

Họ nóiGraphQL hướng tới mục tiêu trở thành ngôn ngữ truy cập cơ sở dữ liệu phổ quát. Còn khả năng truy cập RDF bằng GraphQL thì sao?

Cơ hội này được cung cấp bởi:

Con chó sao (Blog, документация);
Sản phẩm TopQuadrant (hội thảo trên web, документация).

Nếu kho lưu trữ không cung cấp cơ hội như vậy, thì nó có thể được triển khai độc lập bằng cách viết một “trình giải quyết” thích hợp. Đây là những gì họ đã làm, ví dụ, trong dự án của Pháp Dữ liệuDu lịch. Hoặc bạn không thể viết bất cứ điều gì nữa mà chỉ cần lấy HyperGraphQL.

Từ quan điểm của một người tuân thủ chính thống của Web ngữ nghĩa và Dữ liệu được liên kết, tất nhiên, tất cả điều này thật đáng buồn, vì nó dường như được thiết kế để tích hợp được xây dựng xung quanh silo dữ liệu tiếp theo và không phải là nền tảng phù hợp (tất nhiên là các cửa hàng RDF) .

Số lần hiển thị khi so sánh GraphQL với SPARQL là gấp đôi.

Một mặt, GraphQL trông giống như họ hàng xa của SPARQL: nó giải quyết các vấn đề về lấy mẫu lại và nhiều truy vấn điển hình cho REST - nếu không có điều đó, có lẽ sẽ không thể xem xét được ngôn ngữ truy vấn, ít nhất là đối với web;
Mặt khác, lược đồ cứng nhắc của GraphQL lại gây thất vọng. Theo đó, tính “nội tâm” của nó dường như rất hạn chế so với tính phản ánh hoàn toàn của RDF. Và không có đường dẫn thuộc tính tương tự nào, vì vậy thậm chí không rõ tại sao nó lại là “Graph-”.

II. Bộ điều hợp cho MongoDB

Một xu hướng bổ sung cho xu hướng trước đó.

Trong Stardog bây giờ có lẽ - đặc biệt, tất cả trên cùng một GraphQL - định cấu hình ánh xạ dữ liệu MongoDB thành các biểu đồ RDF ảo;
Ontotext GraphDB gần đây đã cho phép chèn các đoạn vào SPARQL trên Truy vấn MongoDB.

Nếu chúng ta nói rộng hơn về các bộ điều hợp cho các nguồn JSON, cho phép ít nhiều “nhanh chóng” biểu thị JSON được lưu trữ trong các nguồn này dưới dạng RDF, chúng ta có thể nhớ lại thuật toán khá lâu đời. Tạo SPARQL, có thể điều chỉnh được ví dụ, tới Apache Jena.

Tóm tắt hai xu hướng đầu tiên, chúng ta có thể nói rằng các kho lưu trữ RDF thể hiện sự sẵn sàng hoàn toàn để tích hợp và vận hành trong điều kiện “kiên trì đa ngôn ngữ”. Tuy nhiên, người ta biết rằng cái sau này đã lỗi thời từ lâu và đang được thay thế bằng đang tới đa mô hình. Thế còn đa mô hình hóa trong thế giới lưu trữ RDF thì sao?

Tóm lại là không thể nào. Tôi muốn dành một bài viết riêng cho chủ đề DBMS đa mô hình, nhưng hiện tại có thể lưu ý rằng hiện tại không có DBMS đa mô hình nào “dựa trên” mô hình đồ thị (RDF có thể được coi là một loại của nó) . Một số mô hình đa mô hình nhỏ - hỗ trợ lưu trữ RDF cho mô hình đồ thị LPG thay thế - sẽ được thảo luận trong phần V.

III. OLTP vs. OLAP

Tuy nhiên, cùng Gartner пишетrằng đa mô hình là một điều kiện thiết yếu chủ yếu cho phòng mổ DBMS. Điều này có thể hiểu được: trong tình huống “lưu trữ đa biến”, các vấn đề chính nảy sinh với tính giao dịch.

Nhưng kho lưu trữ RDF nằm ở đâu trên thang đo OLTP-OLAP? Tôi sẽ trả lời thế này: không ở đó cũng không ở đây. Để chỉ ra mục đích của chúng, cần có chữ viết tắt thứ ba. Là một lựa chọn tôi sẽ đề nghị OLIP — Xử lý trí tuệ trực tuyến.

Tuy nhiên vẫn:

cơ chế tích hợp với MongoDB được triển khai trong GraphDB là không kém phần quan trọng dự định để giải quyết các vấn đề về hiệu suất ghi;
Stardog thậm chí còn tiến xa hơn và trọn vẹn hơn viết lại động cơ, một lần nữa với mục tiêu cải thiện hiệu suất ghi.

Bây giờ hãy để tôi giới thiệu một người chơi mới ra thị trường. Từ những người tạo ra IBM Netezza và Amazon Redshift - AnzoGraph™. Một hình ảnh quảng cáo cho một sản phẩm dựa trên nó đã được đăng ở đầu bài viết. AnzoGraph tự định vị mình là một giải pháp GOLAP. Bạn thích SPARQL với các chức năng của cửa sổ như thế nào? —

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. đáDB

Đã cao hơn rồi đã có một liên kết đến thông báo về Stardog 7 Beta, trong đó nói rằng Stardog sẽ sử dụng RocksDB làm hệ thống lưu trữ cơ bản - một kho lưu trữ khóa-giá trị, một nhánh Facebook của LevelDB của Google. Tại sao nó đáng nói về một xu hướng nhất định?

Thứ nhất, xét theo bài viết Wikipedia, không chỉ kho lưu trữ RDF được “cấy ghép” sang RocksDB. Có những dự án sử dụng RocksDB làm công cụ lưu trữ trong ArangoDB, MongoDB, MySQL và MariaDB, Cassandra.

Thứ hai, các dự án (nghĩa là không phải sản phẩm) về các chủ đề liên quan được tạo trên RocksDB.

Ví dụ: eBay sử dụng RocksDB trong nền tảng cho “biểu đồ tri thức” của bạn. Nhân tiện, đọc thấy buồn cười: ngôn ngữ truy vấn ban đầu là một định dạng được phát triển tại nhà, nhưng gần đây nó đã chuyển sang giống SPARQL hơn nhiều. Như trong câu nói đùa: cho dù chúng ta có tạo ra bao nhiêu biểu đồ tri thức thì cuối cùng chúng ta vẫn có RDF.

Một ví dụ khác - một ví dụ đã xuất hiện vài tháng trước Dịch vụ truy vấn lịch sử Wikidata. Trước khi được giới thiệu, thông tin lịch sử Wikidata phải được truy cập thông qua MWAPI vào API Mediawiki tiêu chuẩn. Bây giờ có thể thực hiện được rất nhiều điều với SPARQL thuần túy. “Dưới mui xe” còn có RocksDB. Nhân tiện, có vẻ như WDHQS được tạo ra bởi người đã nhập Freebase vào Sơ đồ tri thức của Google.

V. Hỗ trợ LPG

Hãy để tôi nhắc bạn về sự khác biệt chính giữa đồ thị LPG và đồ thị RDF.

Trong LPG, các thuộc tính vô hướng có thể được gán cho các thể hiện cạnh, trong khi trong RDF, chúng chỉ có thể được gán cho các “loại” cạnh (không chỉ các thuộc tính vô hướng mà còn cả các kết nối thông thường). Hạn chế này của RDF so với LPG vượt qua một hoặc một kỹ thuật mô hình hóa khác. Những hạn chế của LPG so với RDF khó khắc phục hơn, nhưng đồ thị LPG giống hình ảnh trong sách giáo khoa Harari hơn là đồ thị RDF, đó là lý do tại sao mọi người muốn chúng.

Rõ ràng, nhiệm vụ “hỗ trợ LPG” chia làm hai phần:

thực hiện các thay đổi đối với mô hình RDF để có thể mô phỏng các cấu trúc LPG trong đó;
thực hiện các thay đổi đối với ngôn ngữ truy vấn RDF để có thể truy cập dữ liệu trong mô hình đã sửa đổi này hoặc triển khai khả năng thực hiện truy vấn đối với mô hình này bằng các ngôn ngữ truy vấn LPG phổ biến.

V.1. Mô hình dữ liệu

Có một số cách tiếp cận có thể ở đây.

V.1.1. Tài sản Singleton

Cách tiếp cận theo nghĩa đen nhất để hài hòa RDF và LPG có lẽ là tài sản đơn lẻ:

Ví dụ, thay vì vị ngữ :isMarriedTo vị ngữ được sử dụng :isMarriedTo1, :isMarriedTo2 d và t..
Những vị từ này sau đó trở thành chủ ngữ của bộ ba mới: :isMarriedTo1 :since "2013-09-13"^^xsd:date vv
Sự kết nối của các trường hợp vị ngữ này với một vị ngữ chung được thiết lập bằng các bộ ba có dạng :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
Rõ ràng, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, nhưng hãy nghĩ xem tại sao bạn không nên chỉ viết :isMarriedTo1 rdf:type :isMarriedTo.

Vấn đề “hỗ trợ LPG” được giải quyết ở đây ở cấp RDFS. Một quyết định như vậy đòi hỏi phải đưa vào Стандарт. Một số thay đổi có thể được yêu cầu đối với các cửa hàng RDF hỗ trợ việc đính kèm các hậu quả, nhưng hiện tại, Singleton Property có thể được coi chỉ là một kỹ thuật lập mô hình khác.

V.1.2. Quá trình thống nhất đã hoàn thành đúng

Các cách tiếp cận ít ngây thơ hơn xuất phát từ việc nhận ra rằng các thể hiện thuộc tính hoàn toàn có thể được thực hiện bởi các bộ ba. Bằng cách có thể nói điều gì đó về bộ ba, chúng ta sẽ có thể nói về các trường hợp thuộc tính.

Cách tiếp cận mạnh mẽ nhất trong số này là RDF*, hay còn gọi là RDR, sinh ra ở độ sâu của Blazegraph. Đó là ngay từ đầu bầu cho chính bạn và AnzoGraph. Tính vững chắc của phương pháp này được xác định bởi thực tế là trong khuôn khổ của nó ngỏ ý những thay đổi tương ứng trong Ngữ nghĩa RDF. Tuy nhiên, vấn đề lại cực kỳ đơn giản. Trong quá trình tuần tự hóa RDF của Turtle, bây giờ bạn có thể viết một cái gì đó như thế này:

<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .

V.1.3. Cách tiếp cận khác

Bạn không thể bận tâm đến ngữ nghĩa hình thức mà chỉ cần giả định rằng các bộ ba có một số mã định danh nhất định, tất nhiên là các URI và tạo các bộ ba mới với các URI này. Tất cả những gì còn lại là cấp quyền truy cập vào các URI này trong SPARQL. Vì thế đến Stardog.

Trong Allegrograph đi một cách trung gian. Được biết, bộ định danh bộ ba trong Allegrograph có, nhưng khi triển khai thuộc tính ba thì chúng không nổi bật. Tuy nhiên, nó vẫn còn rất xa so với ngữ nghĩa hình thức. Đáng chú ý là các thuộc tính bộ ba không phải là URI và giá trị của các thuộc tính này cũng chỉ có thể là chữ. Những người ủng hộ LPG có được chính xác những gì họ muốn. Trong định dạng NQX được phát minh đặc biệt, một ví dụ tương tự như ví dụ trên cho RDF* trông như thế này:

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. Ngôn ngữ truy vấn

Đã hỗ trợ LPG theo cách này hay cách khác ở cấp độ mô hình, bạn cần có thể thực hiện các truy vấn về dữ liệu trong mô hình đó.

Hỗ trợ Blazegraph cho các truy vấn RDF* SPARQL* и Gremlin. Một truy vấn SPARQL* trông như thế này:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

Anzograph cũng hỗ trợ SPARQL* và sẽ hỗ trợ Cypher, một ngôn ngữ truy vấn trong Neo4j.
Stardog hỗ trợ riêng của mình mở rộng SPARQL và một lần nữa Gremlin. Bạn có thể lấy URI bộ ba và “thông tin meta” trong SPARQL bằng cách sử dụng những thứ như thế này:

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

Allegrograph cũng hỗ trợ riêng của nó mở rộng SPARQL:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

Nhân tiện, GraphDB đã từng hỗ trợ Tinkerpop/Gremlin mà không hỗ trợ LPG, nhưng điều này đã dừng ở phiên bản 8.0 hoặc 8.1.

VI. Siết chặt giấy phép

Gần đây không có sự bổ sung nào cho sự giao thoa của bộ “bộ ba lựa chọn” và “bộ ba nguồn mở”. Các cửa hàng RDF nguồn mở mới còn lâu mới trở thành một lựa chọn tốt cho việc sử dụng hàng ngày và ba cửa hàng mới mà tôi muốn sử dụng (như AnzoGraph) là nguồn đóng. Đúng hơn, chúng ta có thể nói về sự giảm...

Tất nhiên, nguồn mở chưa bị đóng cửa trong quá khứ, nhưng một số kho nguồn mở đang dần không còn được coi là đáng để lựa chọn. Theo tôi, Virtuoso, phiên bản có mã nguồn mở, đang chìm trong lỗi. Blazegraph được AWS mua lại và hình thành nên nền tảng của Amazon Neptune; bây giờ vẫn chưa rõ liệu sẽ có ít nhất một bản phát hành nữa hay không. Chỉ còn lại Jena...

Nếu mã nguồn mở không quan trọng lắm mà bạn chỉ muốn dùng thử thì mọi thứ cũng kém màu hồng hơn trước. Ví dụ:

sao chó chấm dứt phân phối phiên bản miễn phí (tuy nhiên, thời gian dùng thử của phiên bản thông thường đã tăng gấp đôi);
в Đám mây GraphDB, nơi trước đây bạn có thể chọn gói cơ bản miễn phí, việc đăng ký người dùng mới đã bị tạm dừng.

Nhìn chung, đối với những người làm CNTT bình thường, không gian ngày càng trở nên khó tiếp cận và sự phát triển của nó đang trở thành nhu cầu của các tập đoàn.

Nguồn: www.habr.com

Điều gì đang xảy ra với việc lưu trữ RDF bây giờ?