幕后花絮:世界上最大的分布式图数据库是怎样炼成的?

使用LDBC SNB测试neo4j性能 用到的东西 LDBC SNB datagen 0.3.2 hadoop2.9.2 maven3.6.3 LDBC SNB implementations0.0.1 neo4j-enterprise-3.5.4 1.安装ldbc_snb_datagen ldbc_snb_datagen用来生成测试数据 git地址是https://github.com/ldbc/ldbc_snb_datagen... 阅读详情

本文基于该文章内容整理、补充得到:https://neo4j.com/developer-blog/behind-the-scenes-worlds-biggest-graph-database/

 

在2021年6月17日的Neo4j NODES 2021全球图技术峰会上,Neo4j的工程师展示了迄今为止部署成功的最大的图数据库集群:

 
  • 1129个Neo4j数据库实例,其中:
    • 1128个论坛数据分片
    • 1个用户分片
  • 3个Neo4j Fabric服务实例提供跨分片的查询
  • 每个论坛分片包含 9 亿个关系和 1.82 亿个节点,共2千亿节点
  • 每个用户分片包含 30 亿个用户和他们之间的 160 亿个关系,超过1万亿条边
  • 数据总规模超过 280 TB
  • 从开始部署到得到最终结果用了 3 周
  • 运行的成本约为 400 美元/小时(亚马逊云)

 

这次测试的主要目的是验证Neo4j的可扩展性,以及在分布式部署下、Fabric联邦式查询引擎是否能够维持线性的查询相应延迟增长。

实验从1台Neo4j服务器开始,增加到10台、然后100台、最终1129台,数据量也从开始的数百GB到1TB到280TB。使用的数据集是LDBC。

 

 

动机


在Neo4j 4.0推出 Fabric 时,当时我们做了个验证基准,并在FOSDEM展示给大家。结果表明,对于 1TB 的数据库,吞吐量和延迟会随着其分布的分片数量呈线性增长。更多的分片、更好的总体性能。结果看起来不错,这证实了我们对扩展图数据库的方法有很好的理解。Fabric 的开发继续使其成为 Neo4j 的一个组成部分。随后的产品更新中,新技术被创建和改进(服务器端路由是一个很好的例子),它们对非Fabric和分布式结构设置也很有用。

但是,我们一直惦记着来自 FOSDEM 的 1TB 数据集。1TB 并不大,至少对于 Neo4j 而言。我们通常有 10TB 或更多的生产数据,尽管它们在相当大的机器上运行,但 Neo4j 垂直扩展得很好。我们还没有真的遇到需要分片/分布的存储解决方案的场景。但是,为了适应真正大型数据库的解决方案,我们创建了 Fabric,但我们还没有发现它的真正极限。

那么什么样的规模是大规模?一年前,我们构建了 40 台机器的集群,它们运行得非常好。使用 100 台机器似乎也不会有多大的挑战。也许有数十亿个节点?嗯,数十亿个节点仅相当于几 TB 的数据。重要的是,图模式的丰富性来自节点之间的关系,而不是节点本身。我们想的是测试一下可以将 Neo4j 伸展多远,而不仅仅是让自己感觉或看起来不错。

时不时有这样的声音出现,“Neo4j不支持水平扩展”。很明显我们需要一个证明它错误的机会,一直以来我们都在等待这一机会的到来。现在,它终于来了。这个机会是NODES 2021。

 

规模


我们决定需要一个足够大的规模时,一个还没有其他人做到过的规模。我们需要向世界展示的不仅仅是Neo4j可以存储那样大规模的数据,当水平扩展时还能提高总体性能。

我们将需要更大的数据量,而且不仅仅是数百台机器或数十亿个节点。

一万亿。

一万亿关系应该够大了,对吧?

您甚至在哪里找到具有万亿关系的数据库?使用生产数据会带来物流的问题——数据传输本身会很复杂,更不用说脱密数据以使其适合公众查看。我们只能根据已知模型自己生成它。从数据模型开始,决定需要提供机器的数量和大小、运行的查询以及创建的测试。简而言之,从数据模型开始,了解它需要付出的努力。

LDBC是一个很好的选择。它是一个包含人员、论坛和帖子的社交网络。它很容易理解和解释,大家应该对它也非常熟悉。我们创建了有 30 亿用户的数据集,并对其进行数据分区。这已经超过了地球上最大的社交网络的用户数。根据社交连接的程度,用户分区占用850GB,每个论坛分区有 250GB,每个分区大约有 9 亿个关系。为了达到 1 万亿关系的目标,我们建立了约1110 个论坛分区,每个分区运行在独立的服务器上。

下图是LDBC的数据模型。

 

 

下图是我们对数据进行分区的策略:

 

除了实际存储数据的分区,我们还增加了3个Neo4j Fabric服务实例,用来实现跨区的查询。

实际的测试如下:

1)在10个分区上运行LDBC查询,平均延迟12ms

2)在100个分区上执行查询的平均延迟是18ms。

3)在1000个分区上运行查询,平均延迟是69ms。

 

在实际的测试中,由于这样大规模的集群是亚马逊云上不曾部署过的,我们还解决了若干技术问题。如有兴趣深入了解,欢迎随时联系我们。

 

总结

本篇重点介绍了基于 Neo4j 的高级分片技术,以及 Fabric联邦式查询引擎。这是经过验证的、无与伦比的图数据扩展性能。

 

所有演示数据集和配置的详细信息均可在 Github 上公开获得。

HarmonyOS 分布式深度:跨端迁移、数据对象与多设备协同 本文深入解析鸿蒙分布式能力实战,聚焦跨端迁移、协同与共享三大形态,详解权限配置、设备发现、onContinue状态管理及分布式数据对象、KV同步机制。强调“先分清场景”“前置条件必全”“数据需重验”,揭示迁移失败、同步失效等七大常见坑,指导开发者规避陷阱,实现真实可用的多设备协同。 阅读详情

相关推荐

lumerical中DEVICE和MODE模块的交互使用(真的很干货!!可以自信的说网上绝对找不到比我更详细的步骤了)

几个脚本文件很重要! Lumerical仿真流程: 一、DEVICE: (1).建模并且运行完之后,在脚本提示符下键入以下脚本行以运行plotDopingProfile.lsf如图1(文件名如果索引不到的话就可以把文件直接用notepad++打开,然后把代码直接输入到device中script脚本中 如图2)脚本文件并生成下图 如图3: (图2) (图1) (图3) (2).仿真...

1万+

Neo4j 图数据库(Graph Database),“大模型 + 知识图谱” 的前奏!

Cypher 是 Neo4j 图数据库专用的查询语言,其语法直观清晰,设计风格与 SQL 类似,专门用于高效处理图数据。它通过高度可读的声明式语法,简化了图数据的创建、查询、更新与删除(CRUD)操作,尤其擅长表达复杂的图模式匹配。除了基础操作,Cypher 还支持子查询、聚合计算、条件过滤以及集合操作等高级功能,是图数据库领域最核心的查询工具之一。在图数据库中,为了保持数据的一致性和完整性,我们可以为图中的节点或关系设置约束条件(Constraint)。属性唯一性约束属性存在约束(社区版不支持)

竹林幽深 648

这可是全网网工数通方向学习路线最完整,最详细的版本,没有之一

文章篇幅较长,耐心看完你一定有所收获。

最铁头的网工博客 2万+

AI分布式Token中转站网关底层实现-东方仙盟

在终端优先同步架构下,所有终端智能体请求不再直连上游 MaaS 平台(千帆、百炼、DeepSeek 等),全部经由分布式 Token 中转站网关统一中继。网关承担虚拟客户密钥签发、上游子账号路由、前置内容安全审计、事务路由调度、可控网络震荡多上游链路容灾、SSE 流式透传、用量记账、封禁熔断、原始 IP 封包签名溯源等核心职责。本文基于 Go 实现分布式网关核心底座,复用架构原有无状态 Token 穿透、事务 ID 幂等、链路探活、多节点中继能力;区分两层密钥体系:面向终端客户的虚拟 Key。

cybersnow精通 28 门计算机语言,凭借其超凡的技术能力,成功开发过上万个应用,广泛涉及政府、商业、个人等众多领域,甚至在检察院、环保局、公安局等专业场景中也大放异彩。不仅熟练掌握单片机和物联网开发,在软件架构设计方面更是独树一帜,自创了跨平台软件 228

PCB阻焊工艺全解析:从油墨选择到显影测试的完整指南

本文深入解析PCB阻焊工艺全流程,从材料科学角度对比液态光成像(LPI)油墨、干膜阻焊等核心材料特性,系统阐述前处理、涂覆、预烤曝光、显影固化等关键步骤的工艺要点与参数控制。重点探讨了如何通过优化油墨选择与工艺参数,解决常见缺陷,提升PCB的可靠性、美观度及可制造性,为工程师提供从理论到产线实战的完整指南。

s3t4u的博客 553

从零开始:如何用STM32和MAX30100打造你的第一台智能心率监测设备

本文详细介绍了如何使用STM32微控制器和MAX30100传感器从零开始构建智能心率监测设备。涵盖硬件选择、电路设计、软件开发到心率算法实现的全过程,特别适合嵌入式开发新手和创客。通过OLED显示和蓝牙串口传输数据,打造低成本、高精度的心率检测仪,为健康监测项目提供实用解决方案。

7z8x2c4v6b9的博客 191

集中式与分布式怎么选:从订单读写看 KingbaseES 的架构边界

以订单系统为例,一笔付款会扣账户余额、写一条流水、更新订单状态;月末报表则可能按日期统计所有租户的订单。前者要求几项变更一起提交,后者关心查询会覆盖多大范围。讨论集中式与分布式,先把读写请求分开,比先数数据库节点更容易看清问题。KingbaseES 核心数据库是集中式关系数据库。KES RAC 和 KES TDC 也都可以部署为多节点形态,但它们的数据组织方式并不相同。

todoitbo的博客 1万+

YOLO26涨点改进 | 全网独家复现、小目标检测改进篇 | TGRS 2025 | YOLO26引入MFAE-YOLO中的GFFP、FCPS 和 C3k2-FPEU创新点,涨点起飞,直接发论文

🔥本文给大家介绍在YOLO26中引入MFAE-YOLO中的 GFFP(全局特征融合处理)、FCPS(特征通道像素注意力) 和 C3k2-FPEU(特征池提取单元) 二次创新改进模块,能显著提升对小目标的检测性能。GFFP通过多尺度特征融合增强全局上下文感知能力,有效提升小目标在复杂背景下的可辨性;FCPS融合通道、像素和空间注意力机制,增强了模型对关键细节和小区域特征的关注,提升检测精度;C2F-FPEU利用多种池化方式挖掘细节特征,优化浅层特征表示能力。三者协同提升了YOLO26在小目标检测中的鲁棒性。

Ai缝合怪、助力小伙伴高效发论文 305

编队系列(二)|固定翼如何依靠邻居信息保持队形?一致性控制、通信拓扑与分布式仿真实现,附仿真代码

一致性编队将通信关系写入邻接矩阵和拉普拉斯矩阵,各机根据本机与邻居的协同变量误差生成局部修正量。普通位置一致性会使成员趋向同一点;固定翼编队需要对带槽位偏置的虚拟参考点、航迹角、速度或路径参数执行一致性,再由路径跟踪和单机制导层生成可飞参考。本文例程对二维虚拟参考点坐标进行一致性,并将路径速度、路径收敛速度和一致性速度组合为期望运动,再复用 LQR 与姿态控制接口。该结构适合验证静态环形拓扑下的多机编队,但其收敛与安全性仍受消息有效性、通信时延、拓扑变化、速度饱和、转弯曲率和机间避碰约束影响。

2302_80148937的博客 287

YOLOv9改进策略【注意力机制篇】| 添加SE、CBAM、ECA、CA、Swin Transformer等注意力和多头注意力机制

这篇文章带来一个经典注意力模块的汇总,虽然有些模块已经发布很久了,但后续的注意力模块也都是在此基础之上进行改进的,对于初学者来说还是有必要去学习了解一下,以加深对模块,模型的理解。

Limiiiing的博客 2891

番外篇 | 复现HIC-YOLOv5,助力小目标物体的检测

在本文中提出了一种改进的YOLOv5算法:HIC-YOLOv5,用于小目标检测,具有更好的性能和较低的计算成本。🌈

小哥谈 1129

分布式设备列表拿到了,数据通道选错照样传不过去

分布式协作的设计顺序应该是:先确定数据的一致性语义(状态最终一致 vs 操作恰好一次),再选通道(DDO / KV / RPC / 文件),最后把标识和内容分开。离线期间手机加了三个附件,平板重连后 DDO 会把最终的字段列表对齐,中间某一条“附件关联”的副作用如果涉及独立写入,不会因为 DDO 对齐而自动补执行。的 RPC 通道,这四条路解决的是不同的问题。的场景(扣库存、审批、附件关联),DDO 只能承载最终状态,操作序列需要应用层自己的 outbox 和确认水位来兜底。

2602_97267507的博客 357

SAP CPI 之使用国密算法实现SM系列算法加解密

System.out.println("SM2-私钥:" + privateKey);System.out.println("SM2-公钥:" + publicKey);System.out.println("SM2-密文:" + encrypts);System.out.println("SM2-明文:" + data2);新建groovy,通过import之后,调用jar包中的方法。在CP中导入jar包,选择Upload,选中导入的jar包。的密钥和向量值,不安全!的公钥和私钥,不安全!

u012830826的博客 1334

分布式详解

分布式系统由多台独立节点通过网络协作,对外提供统一服务。其核心挑战在于部分失败、无全局时钟与网络不可靠。为应对这些难题,系统需在不可靠环境中保证协同正确性。分布式主要解决高吞吐、高可用、业务拆分与数据扩展问题。根据CAP定理,系统需在一致性(C)、可用性(A)与分区容错(P)中取舍,多数互联网应用选择AP,遵循BASE理论:基本可用、软状态、最终一致。分布式ID常用雪花算法,兼顾有序性与唯一性。

m0_50953782的博客 114

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

OpenWiFi与LibreNMS集成实践:构建分布式异构网络管理体系

面向多厂商园区网络,详解 OpenWiFi 与 LibreNMS 的集成架构:SNMP 自动发现、MIB 指纹识别、边缘轮询与统一告警。破解数据孤岛,构建统一运维视图。

asterfusion的博客 303

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

智能家居全国交付中随需配套的分布式节点架构设计与实现:需求驱动下的交付半径扩展

平台在目标城市筛选交付工程师,按技能标签、交付质量、准时率、配合度、主体状态进行认证。需求驱动的分布式节点架构把交付半径与业务半径同步扩展:B端客户业务覆盖到何处,平台在何处按统一标准筛选认证节点,规则先行,节点可替换,平台兜底。平台不定义产品,不创造流量,不直接服务C端使用端,只做全国交付基础设施。平台在目标城市筛选交付工程师,按技能标签、交付质量、准时率、配合度、主体状态进行认证。质量指标可观测:业务覆盖映射准确率、节点认证通过率、分级分布、一次交付成功率、返工率、异常闭环时长、节点替换响应时长。

weixin_43432501的博客 427

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

集中式与分布式怎么选:一次选型复盘,附金仓数据库建表与增删改查实践

本文以真实项目为背景,剖析集中式与分布式架构的适用场景。作者指出,盲目追求“分布式”不仅增加成本与复杂度,更可能因事务延迟、运维难度上升等问题导致系统性能下降。通过对比两类架构在事务、SQL自由度、运维与扩容等方面的差异,强调应基于业务实际需求选择方案——“不是哪个先进,而是哪个解题”。文中还拆解“伪分布式”等常见误区,并以金仓数据库实践为例,展示如何在集中式架构下高效实现订单系统设计,最终倡导“按需选型,不被概念绑架”的务实技术观。

小相探索IT世界 4605

vpls over srv6配置分布式网关

本文是《华为VPLS over SRV6》的续篇,在原有VPLS over SRv6基础上引入分布式网关和IP前缀路由,实现三层互通。文章依次给出新建三层VPN实例、配置VBD接口与Anycast网关、发布IRB路由、在BGP中发布VPN实例以及模拟三层地址段的具体配置,并通过ping测试、vrf2路由表以及EVPN的Type2(MAC路由)和Type5(IP前缀路由)表项验证主机路由与网段路由的正确学习与转发。接着上篇文章。

176

分布式 KV 跨端数据冲突的合并策略

在开发跨设备协作文档应用时,最大的噩梦不是网络断开,而是两台设备分别在离线状态下修改了同一份文档。等它们重新联网同步时,后同步的数据直接覆盖了前面的数据,导致用户的修改凭空消失。此时必须触发预设的业务合并算法(比如把两段文本拼接,或者提示用户手动选择保留哪一份),合并完成后,将本地版本号加一,再重新推送到 KVStore。同时联网后,用你写的版本号合并逻辑去拦截默认的覆盖行为,看看两边最终的数据是否都能保留下来。为了掌控数据的主权,我们必须放弃默认的时间戳策略,在业务层引入版本号机制。

2602_97267507的博客 144

集中式与分布式,KingbaseES 的四种形态共用一套内核

金仓数据库 KingbaseES 提供集中式(单机、ClusterWare、RWC、RAC)与分布式(TDC、Sharding、ADC)双架构,基于同一内核扩展。集中式形态零应用改造,RTO均小于1分钟,RPO为0;RAC共享存储实现多活,支持跨节点并发控制。分布式通过分片管理、分布式事务等模块构建,兼容原有运维体系,避免分库分表的外部耦合。选型核心考量:数据规模、并发量、团队经验,三者皆无则从集中式起步,后续按需扩展,成本可控。

笃行其道的博客 8216

集中式与分布式怎么选?我把手头11套系统重新过了一遍秤

先定架构,再选产品。架构选错了,后面所有的参数对比、POC 测试、迁移实施,都是白费

倔强的石头的博客 1万+

推理 INFRA 方法论(2):分布式推理:TP、DP、EP、CP 与 PP 的取舍

围绕权重、KV、激活和通信预算,分析 TP、DP、EP、CP 与 PP 的容量、通信及吞吐取舍,讨论注意力与 MoE 的并行组合,以及长上下文和流水线的额外约束。

sunny0660的博客 399

vLLM 前世今生:从 PagedAttention 到分布式推理引擎的演进之路

以显存效率为起点,以吞吐为目标,逐步长成一个通用的推理基础设施。诞生时,它用 PagedAttention 解决了 KV Cache 浪费这个最痛的问题;发展期,它不断扩展模型、量化、并行、硬件支持,从"快但窄"走向"全而稳";当下,V1 引擎、PD 分离、结构化输出、长上下文是社区最热的方向;未来,它想成为硬件无关、场景无关的推理标准层。对于使用者来说,理解 vLLM 的演进逻辑,比记住它的 API 更有价值——因为它的每一次取舍,背后都是对"推理系统到底在优化什么"这个问题的重新回答。

Maxwell_Newton的博客 342

工业网关 Quota 实战:从限流算法到分布式配额治理

工业网关通常不是单租户、单进程的简单程序:北向 API 会被多个应用调用,南向可能接入大量设备,本地还要承载数据缓存、历史导出、协议任务和云端上报。如果资源使用没有边界,一个异常应用、一个失控采集任务或一次历史导出,就可能挤占其他租户的连接、存储和上行带宽。Quota 的价值不是简单“把请求拒绝掉”,而是把资源使用显式化:谁能用、能用多少、在什么周期内用、超出后走什么策略。本文从Zenova EdgeOS工程梳理工业网关中的配额类型、限流算法、Redis 原子实现、数据模型、降级策略和监测体系。

ZenovaEdgeOS的博客 346

Cloudflare Durable Objects 支持自动重试:分布式调用如何避免重复执行?

在分布式系统中,远程调用失败可能导致操作状态不确定。Cloudflare 为 Durable Objects 引入自动重试机制,仅对可重试错误进行智能重试,并通过 retryable() 明确标记幂等操作,避免重复执行。该机制不保证全局精确一次,仍需业务层实现去重,如使用请求标识或幂等键。核心在于区分“未执行”与“已执行但响应丢失”,从而在保障可靠性的同时防止数据错乱。

weixin_47502228的博客 361

从零搭建一个 AI Infra 实验室㉑:llm-d——从单个 vLLM 走向分布式推理

本篇深入 llm-d 分布式推理架构,解析负载感知路由、前缀缓存感知、KV Cache 本地性与 Prefill/Decode 分离。基于单节点 Kubernetes 和 LLM Simulator,实测智能路由与多 Pod 请求分布,理解从单个 vLLM 走向分布式推理的关键设计与挑战。

mosespaul的博客 294
上一篇: Neo4j 图数据库高级应用系列 / 服务器扩展指南 APOC(6.7):将属性值转换成节点
下一篇: Neo4j的事务管理和锁行为
俞博士
俞博士 领域专家: 数据库技术领域 领域专家: 数据库技术领域 业界专家认证 业界专家认证
博客等级 码龄9年 2326粉丝 72原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值