标签: graph

我目前正在努力升级到 SQL Server 2019，以便利用其中可用的图形功能。我们的数据库存储文件及其子文件的记录，图形特征使我们能够快速找到文件在任一方向的所有关系。我们当前的开发环境在 Linux 服务器上使用 SQL Server 2019 Standard (15.0.4023.6)。

我在运行图形查询时注意到一个令人担忧的问题。服务器的“内部”资源池在图形查询后似乎没有释放所有资源。如果不选中，这会填满资源池。在重新启动 SQL Server 进程之前，较大的查询将失败。根据服务器负载，这可能会在短短 1-2 小时内发生。这也会填满 tempdb 并威胁填满存储驱动器。在服务器重新启动之前，tempdb 的文件也不能显着缩小/截断。在配置中，'memory.memorylimitmb'没有设置，所以当资源池开始使用默认80%的系统内存（12.8GB，16GB系统内存）中的大部分时，就会出现这个问题

要在演示数据库中设置表：

CREATE TABLE FileNode (ID BIGINT NOT NULL CONSTRAINT PK_FileNode PRIMARY KEY) AS NODE

GO

CREATE TABLE FileNodeArchiveEdge AS EDGE

GO

CREATE INDEX [IX_FileNodeArchiveEdge_ChildFile] ON [dbo].[FileNodeArchiveEdge] ($from_id)

GO

CREATE INDEX [IX_FileNodeArchiveEdge_ParentFile] ON [dbo].[FileNodeArchiveEdge] ($to_id)

GO

填充演示数据库表：

INSERT INTO [FileNode] (ID) VALUES
            (1),(2),(3),(4),(5),
            (6),(7),(8),(9),(10),
            (11),(12),(13),(14),(15)

-- Convenient intermediate table
DECLARE @bridge TABLE (f BIGINT, t BIGINT)
INSERT INTO @bridge (f, t) …

我正在考虑使用图形数据库管理系统（简称 DBMS）作为我的单用户桌面应用程序的应用程序文件格式。

是否有基于单文件的图形 DBMS（图形 DBMS的 SQLite 的“等价物”）？

目标：用户提交他们的通讯录，然后应用程序根据他们的电话号码查找用户之间的联系。类似于“6次握手”的想法（https://en.wikipedia.org/wiki/Six_degrees_of_separation）。

问题：使这个查询性能接近实时。当用户提交他的电话号码并获得其他电话的完整列表时，他可能知道。普通列表 - 没有连接（图形顶点等），但完整，没有分页（这里要求是因为原始目标更复杂）。

问题：是否有可能使用纯关系数据库实现接近实时的性能，而无需图形数据库（Neo4j 等）、图形扩展（bitnine agensgraph）或工作流重新设计？任何非规范化都是可能的，但据我所知，它无济于事。

鉴于：

test=# select * from connections;
 user_phone | friend_phone
------------+--------------
          1 |            2
          1 |            3
          1 |            4
          2 |            6
          2 |            7
          2 |            8
          8 |           10
          8 |           11
          8 |           12
         20 |           30
         40 |           50
         60 |           70

我希望使用电话 === 1 的用户收到以下连接：

 friend_phone
--------------
            2
            3
            4
            6
            7
            8
           10
           11
           12
(9 rows)

估计真实世界的连接数真的很困难。但我至少在测试：

• 10,000 个用户（电话号码）
• 每个用户被随机分配了 50-1000 个与其他用户的伪随机 …

我有一些体现有向无环图的关系，其中包括类似于以下内容的模式：

我正在寻找一种有效的方法来遍历此图形数据。下面是计算节点 0 的后代的看似简单任务的示例：

数据库<>小提琴

DROP TABLE IF EXISTS #edges;
CREATE TABLE #edges(tail int, head int);
INSERT INTO #edges(tail,head) VALUES
    (0,1), (5, 6),  (10,11), (15,16),
    (0,2), (5, 7),  (10,12), (15,17),
    (1,2), (6, 7),  (11,12), (16,17),
    (1,3), (7, 8),  (11,13), (17,18),
    (2,3), (7, 9),  (12,13), (17,19),
    (2,4), (8, 9),  (12,14), (18,19),
    (3,4), (8,10),  (13,14),
    (3,5), (9,10),  (13,15),
    (4,5), (9,11),  (14,15),
    (4,6),          (14,16);
WITH descendents(node)
AS(
    SELECT 0 as node
    UNION ALL
    SELECT head as node FROM descendents as prior
    JOIN #edges …

我有一种感觉，大多数数据库系统起源于 80 年代，并且刻板地实现了表、ACID 事务和约束。它们的构建考虑到了内存、磁盘和处理能力的稀缺性。

我想知道是否有任何存储系统（不需要通过 SQL 访问）能够处理以下内容：

• 图（查询 la SPARQL）。
• 矩阵（n 维）也稀疏。支持平凡矩阵算法，如 SVD、聚类。
• 有效管理不会连续变化的大（TB 级）数据；通过每天的批次正在发生变化。
• 使用大型磁盘系统（14TB 的 RAID5 现在不到 1500 美元）。这意味着有更多空间用于索引、预先计算的结果等。
• 利用 GPU/多核/处理器/节点进行大型查询和索引。

我知道大多数项目都在某处实现（Apache Cassandra、SPARQL、Netezza、Exadata），但我不知道任何可能实现所有项目的产品。

是否有任何程序、源代码或 API 将采用 MySQL 或 PostgreSQL 模式并吐出 UML 或其他图形可视化？

我想使用 Apache Cassandra 根据属性图模型存储大量图数据。该模型包含以下实体：

• Vertices：包含键/值对（属性）的映射。一些键应该被索引以进行查询（见下文）。
• 边：在给定方向上将两个顶点相互连接。包含一个标签和可能的一些边缘数据。边缘数据是键/值对的映射，其中一些键也应该被索引以进行查询。

#A vertex
{node_type:'module',pk: 1,...}
#Another vertex
{node_type:'function',pk: 2,...}

#An edge
{incoming_vertex: 1,outgoing_vertex: 2,label: 'body',data : {}}