重磅发布!!!蚂蚁图团队开源高性能原生图存储系统CStore

分布式和集群有什么区别 分布式和集群的区别 阅读详情

作者:唐浩栋

CStore是一款专门为图分析场景而设计的原生图存储引擎,它采用了Rust语言编写,使用基于图的存储结构,针对图分析场景进行特定优化。CStore可以存储包含千亿级点和万亿级边的图数据,在蚂蚁集团内部的多场景使用中,已经积累了多年的经验,存储容量达到了PB级别。

图存储系统

百艺通,不如一艺精

在设计数据存储引擎时,需要考虑众多因素。例如,所应用的具体场景,是联机分析处理(OLAP)还是联机事务处理(OLTP);再如,数据存储方式的选择,内存、本地硬盘或分布式存储;还有就是存储数据的格式,像是文档、JSON,宽表,对象,键值对等。图存储引擎是诸多数据存储引擎中的一种,它专门用于图数据的存储。从DB-Engines网站的统计来看,Graph DBMS的热度从2014后一直领先其他类型数据库。

DBMS热度趋势

根据图数据存储方式的不同,现有的图存储引擎主要分为下面几大类:

  1. 基于链表,例如Neo4j。
  2. 基于Hash+链表,例如ArangoDB。
  3. 基于Key-Value键值,例如Titan/JanusGraph/HugeGraph。
  4. 基于传统关系型数据库,例如AgensGraph。

CStore基于Array+链表的方式存储数据,支持实时读写能力。为了提供更好的图分析能力,CStore把图元数据和属性分离存储,单独对元数据构建多级索引。CStore在存储方式和索引设计上都充分考虑到图语义,有效地结合图数据访问的特点,充分利用计算机硬件的优势,在蚂蚁内部多个场景中得到验证,取得很好的业务效果。
接下来从建模、存储、索引三个方面来介绍CStore作为原生图存储引擎的特点。

原生图建模

图形数据非常适用于描述复杂的网络关系。与其他存储格式相比较,图形数据具有自身的独特之处。举例来说,在 NoSQL 数据库中,Key-Value 数据库只包含 Key 和 Value 这两种元素,用户更容易理解和操作,并且存储引擎的设计也可以遵循一定的规则。另外,对于 DBMS(数据库管理系统)来说,实体关系模型必须按照一定的规范来进行设计,通常情况下,要求业务表的设计至少要符合第三范式,以此来消除数据冗余现象。CStore基于属性图来建模,属性图是由点,边,以及点和边上的属性组成的图,点数据中记录了起始点ID和图元数据(标签,时间戳),边数据记录了起始点ID和图元数据(终点ID,方向,标签,时间戳),每个起始点ID唯一确定一组点边数据。

点边数据进入到CStore之后,把点边起始点ID转化为从0开始的ID,这个过程称之为ID化。由于用户定义的起始点ID格式不固定,蚂蚁内部使用的起始点通常大于20bytes,转化为4个bytes ID后,可以极大减少索引内存消耗;另外规范化ID之后,CStore使用array来做主键索引,array的index为ID,查询效率为O(1)。

ID字典

ID化之后,点边数据被序列化为PrimaryKey和GraphData,GraphData由SecondKey和Property组成。PrimaryKey记录点边ID,SecondKey记录图元数据,Property记录点边属性数据。

SecondKey编码格式如下,target id大小不固定,其他部分消耗20 bytes。write ts字段记录数据写入时间,被用于数据淘汰,sequence id记录了数据写入顺序,transaction和compaction都会用到。graph info记录是否是点,是否是入边,是否包含属性,标签,其他meta, 点边时间属性等信息。

图数据编码

这样编码有两点好处:

  1. 点边数据变成CStore内部具有固定格式的二进制数据,有效减少内存消耗,方便后续数据写入磁盘;
  2. 图元数据被压缩到8字节,这样可以把更多的图信息放到索引侧,能够提前在索引侧过滤掉用户不需要的数据。

许多图形数据库会选择将点边数据编码为键值对的形式存储。相比之下,CStore是一款针对图分析场景而设计的存储引擎,目的是提供更快的分析能力。为了实现这一点,CStore会对经过编码后的图形信息建立多级索引。在下面的内容里,我们将讨论如何存储数据以及构建多级索引。

友好图存储

蚂蚁内部图数据的访问有以下几个特点。

  1. 通常相同起始点ID的点边数据大概率一起被访问;
  2. 相同类型, 时间的数据通常被一起访问;
  3. 用户点边数据的属性非常大,而点边元数据信息为固定结构且数据量不大;
  4. 点数据查询频率大于边数据。

CStore在设计存储结构的时候,结合上述特点,对特定场景进行优化。针对第一个特点,CStore尽可能的把具有相同的起始点ID的点边数据存储到物理上连续的存储空间。点边数据被序列化之后,数据首先被写入GraphData Segment,它为内存数据结构,使用跳表来组成数据,维护了起始点ID到GraphData List的结构。
GraphData Segment主要有两个功能:

  1. 数据聚合。把相同的src_id的点边数据聚合到一起存储。
  2. 排序。按照用户指定顺序把相同src_id的点边数据排序,用于构建二级索引。

GraphData Segment数据结构

GraphData Segment到达阈值之后被刷入到磁盘,数据被刷入到磁盘之前,把具有相同类型,写入时间(通常以天为单位)的数据作为一个分区写入到连续的物理存储空间,每个分区之间数据互相独立。

GraphData Segment分区

再者根据点边数据属性大而元数据固定的特点,CStore采用了属性分离的架构,把图属性和图元数据分离存储到不同的物理存储空间。一方面对于图元数据单独加索引能够加速图查询性能,另外一方面属性分离也能够减少数据compaction的读写放大开销。

另外CStore还支持用户配置点边数据存储到不同的存储介质,点边数据在物理上隔离。点边数据的访问频率在不同的场景有所不同,分离存储能够进一步优化数据访问性能,提前过滤掉不需要的数据,减少数据读放大。

高效图索引

CStore具有高效的图数据检索能力,支持多维度索引,不仅提供针对图元数据的分区索引,主键索引和二级索引,还支持针对点边属性的全文索引,可以根据指定的条件快速定位和返回数据。

图索引架构

GraphData Segment写入到磁盘之前,把相同起始点ID的GraphData根据用户指定的顺序排序,然后把排序好的SecondKey构建索引,把排序好的Property直接写入到属性文件(记为vs文件)。

CStore的分区索引对应到磁盘中某个目录,不同的分区数据落在不同的目录。主键索引是稀疏索引,默认索引间隔为2048,目前仅支持以起始点ID构建主键,主键索引常驻内存。通过主键索引,可以快速定位到属性存储的文件id和offset。

主键索引

二级索引包括min max索引,bloom filter索引等,用于快速判断某个稀疏索引块是否包含某个主键。min max索引记录某个索引块的上界和下界,bloom filter记录索引块的主键。

对于热点数据,二级索引做了特殊支持,比如一个起始点ID对应了10亿条边,如果没有索引,需要把满足min max和bloom filter索引的所有边读到内存过滤一次,返回用户指定的数据。为了加速这种场景,CStore对点边类型,指向,写入时间加了二级索引。比如用户只想要读取label为student,dt为2023-10-1数据,通过二级索引,首先过滤掉所有label非student的数据,然后过滤掉dt非2023-10-1的数据,可以极大减少数据读开销,提升用户查询性能。

二级索引

构建完索引,数据写入到索引文件(记为is文件),is文件按照LSM-Tree结构组织,key为主键索引中的index,value为索引block压缩后的数据。is文件内部对于key有序,第0层单个文件内部对于key有序,其他层文件间对于key有序。

并发Compaction

为了加快 LSM-Tree compact的性能,CStore 支持单层的多线程compact。在示意图中,每一个单独的compactor都代表一个compact工作线程。不同的compactor线程和compact清理线程(负责清理被compact的文件)将会并行执行。

以下是单个compactor内部运作过程的示意图,其中包括四个关键步骤:

  1. 计算各层次得分并选择其中最高的;
  2. 收集需要compact的文件;
  3. 将上述收集到的文件进行compact并生成新的文件;
  4. 最后一步是将新的文件更新至 LSM-Tree及内存索引中。

Compaction管理

编译构建

单独编译CStore代码需要提前准备Rust和C++工具链。

# install rust.
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# install nightly toolchain.
rustup update && rustup toolchain install nightly && rustc --version

# install other dependencies. 
yum install make gcc gcc-c++ protobuf-devel protobuf clang

下载TuGraph Analytics代码后,执行以下命令编译CStore源代码:

git clone https://github.com/TuGraph-family/tugraph-analytics.git
cd tugraph-analytics/geaflow-cstore && make build

执行make help可以查看makefile提供的功能,当前版本的功能和对应描述如下:

geaflow-cstore 0.1.0
Usage: make <target>
Targets:
  build-dev                       Build the geaflow-cstore with dev version. Both <make build> and <make build-dev> work.
  build-release                   Build the geaflow-cstore with release version.
  fmt                             Format the code by rustfmt.toml.
  clippy                          Check statically code with clippy.
  test-all                        Run all integration tests and unit tests, include ignored tests.
  test                            Execute all the unit tests.
  test-fn                         Use "make test-fn mod=<func_name>" to specify which function of test to run.
  test-in                         Use "make test-in mod=<func_name>" to specify which target of integration tests to run.
  bench-all                       Run all benches.
  bench                           Use "make bench mod=<mod_name>" to specify which bench of mod to run.
  doc                             Generate the document of geaflow-cstore and open it in html.
  all                             Execute code style and static checks, release version compilation and tests in sequence.
  update                          Update all the dependences to the newest version, include rust analyzer.
  gen                             Generate the code described by proto.
  features                        Use "make features mod=<id>" {0->[default] 1->[hdfs]} to set the env in ~/.cstore_buildrc.
  clean                           Clean up the cargo cache.
  version                         Show the version of geaflow-cstore.
  help                            List optional commands.

未来规划

CStore已在蚂蚁集团内部具备多年大规模生产化经验,未来我们将不断迭代升级,提升系统性能。然而,在一些特定的情况下,我们认识到CStore还有进步的空间。在未来一至两年内,我们计划更加深入地探索优化图分析场景,支持图数据列式存储,图融合以及物化视图能力。同时,为了提高用户的体验度,我们也将引入remote compactor功能,以解决因compact而导致的资源竞争问题。

目前,CStore系统已全部开源到TuGraph Analytics仓库(geaflow-cstore模块),当前推送的代码涵盖了CStore的核心功能特性,仍有大量的增强功能还在整合中。TuGraph团队将持续投入图存储系统CStore的建设工作,也非常欢迎图计算和图存储的开发者一起参与进来,共同推进CStore的开源和演进。

总结

当下TuGraph Analytics项目已经内置了CStore JNI的依赖,你可以在高阶API任务中使用并体验CStore静态图存储系统,CStore动态图能力正在建设中,敬请期待。同时我们也非常欢迎图存储系统/Rust爱好者加入到CStore开源项目的建设中来。

相关资料:

电力现货市场出清机制与节点电价计算实战解析 本文深入解析了电力现货市场的出清机制,特别是节点边际电价的计算原理与实战应用。通过一个基于Matlab和IEEE30节点系统的完整案例,详细演示了如何利用最优潮流模型求解市场出清价格,并提取节点电价,揭示了电网阻塞如何影响实时电价的形成。 阅读详情

相关推荐

卸载重装Ubuntu22.04双系统

先说一下写此篇文章的背景吧,我在Windows下配置了三个cornerNet深度学习环境分别是cuda10.3(显卡版本太高不支持),cuda11.3(配置后偶然看到一篇说这个版本win下只能用CPU跑),最后是cuda11.1终究还是没能跑通代码,因为它的代码是在Liunx系统写的,就想着装个Ubuntu试试看,在网上看说一般软件不要装太高版本,我就下载了470版的显卡驱动,跟着步骤升级了系统内核,结果第二天开机Ubuntu就崩了,开机黑屏左上角只有一道横杠显示,只能按ctrl+shift+f5进入命令窗

编程小白的博客 8111

列存储数据库C-Store介绍

C-Store是一个为了快速查询而设计的关系型数据库,它的论文发表于2005年的VLDB。 为了达到更快的查询性能,C-Store按列存储数据,同一个表中的不同列可能被存在不同的、可能有重叠的Projection中。 虽然C-Store没有提出什么新的技术,但它是第一次将与列存储相关的技术整合到一起,成为一个真正理论上可用的系统,所以其设计和系统架构仍被广泛借鉴。

Hansen先生的博客 6504

Vivado与Vscode无缝集成:高效Verilog开发环境搭建指南

本文详细介绍了如何将Vivado与Vscode无缝集成,打造高效的Verilog开发环境。通过替换Vivado默认编辑器为Vscode,配置必备插件和语法检查工具,开发者可以大幅提升FPGA项目的编码效率。文章还提供了代码片段、Testbench自动生成等高级技巧,帮助开发者快速上手这一集成方案。

weixin_33737774的博客 493

C-Store: A Column-oriented DBMS

今天看了一篇CStore论文,笔记记录一下,后续内容待补充~目录1.C-Store: A Column-oriented DBMS 1.1 Proposal 1.2 Why C-Store? 1.3 Architecture 1.4 Innovative 1.5 Projections 1.6 Segments and Storage Keys 1.7 Join Indices ...

Francis的博客 407

基于Simulink进行双向DC-DC变换器的仿真建模

特点双向性:可以将能量从一个电压等级转换到另一个,且方向可逆。效率高:通过合理的控制策略减少能量损失。应用广泛:如电池管理系统、混合动力汽车等。挑战拓扑选择:根据应用场景选择合适的电路结构(如buck-boost、full-bridge等)。控制策略:确保高效稳定运行的同时,适应负载变化。热管理:有效散热以保持长期可靠性。首先明确要模拟的任务内容。设计一个能够支持双向能量传输的变换器。根据输入输出电压要求确定合适的变换器拓扑。实现有效的控制策略来维持输出电压稳定。

xiaoheshang_123的博客 367

69页完整版智慧港口综合解决方案

智慧港口需求4港机远程操控等自动化改造需求自动化码头AGV无线通信及专用视频系统需求安全生产视频监控类需求港机RCMS及设备管理需求岸边智能理货码头三维全景应用智慧港口解决方案5自动化码头AGV/跨运车/无人集卡无线接入港机远控视觉及冗余无线通信视觉集卡防吊起系统集装箱码头岸边智能理货港机RCMS系统无线接入港机智能化管理(无线高清视频监控、一键报警、远程抄表系统)港口拖轮无线接入岸边溢油监测系统TD-LTE覆盖及业务终端接入港口生产管理系统港口可视化集群调度港口GiNMS综合网络设备智能管理全球作业效率最

zuoan1993的博客 2130

【 OpenGauss源码学习 —— 列存储(CStore)(四)】

本章我们继续在【 OpenGauss源码学习 —— 列存储(CStore)(三)】基础上进行进一步学习,本文将继续介绍CStore类中与填充列存储引擎中的数据结构或有关的部分公有成员函数。本文所讲的这一系列的函数主要用于==填充Columnar存储引擎中的数据结构或。==这些函数涵盖了不同的场景和功能,包括普通列数据的填充系统列数据的填充延迟读取列的填充等。用于填充一个,主要用于查询扫描时读取多列数据。用于填充,主要用于普通列的数据填充,支持不同数据类型和压缩方式。根据提供的TID列信息填充。

qq_43899283的博客 941

opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称 解决方案

本文主要介绍了opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称解决方案,希望能对使用opencode的同学们有所帮助。 文章目录 1. 问题描述 2. 解决方案

weixin_43178406的博客 11万+

C-Store:一个列存数据库

今天介绍《C-Store: A Column-oriented DBMS》,这篇文章是VLDB 2005的,作者 Mike Stonebraker,2015年图灵奖获得者...

乔的博客 2115

一文搞定 ST22 短转储 MEMORY_NO_MORE_PAGING:看懂 SAP Paging 机制,参数 rdisp/PG_SHM 与 rdisp/PG_MAXFS 怎么设才稳

SAP系统MEMORY_NO_MORE_PAGING错误通常源于Paging资源耗尽而非物理内存不足。关键排查点包括:通过ST22确认错误类型,ST02监控Paging使用情况,检查工作进程trace中的"no more free blocks"提示。解决方案建议将rdisp/PG_SHM和rdisp/PG_MAXFS设为相同值(如250000块≈2GB),使Paging完全在内存中运行。同时需优化易耗Paging的代码逻辑,如避免滥用EXTRACT命令和超大内存对象传输。典型案例如月末

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 335

以宠辱之戒写 SAP Fiori Elements,把标准能力当成身体,把扩展冲动当成大患

SAP Fiori Elements开发中常面临业务方追求"独特页面"的压力,但过度自定义会破坏框架价值。老子"宠辱若惊"的智慧提醒开发者:不应因用户称赞或批评而动摇架构原则。标准模板的价值在于确保业务语义、交互规范和后端服务的一致性。扩展应遵循官方API,将业务逻辑放在ABAP/CDS层而非前端控制器。成熟项目会平衡标准与定制,使用annotation表达UI行为,仅在必要时通过受支持的extension points进行增强,保持系统的长期可维护性。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 1000

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

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

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

RK3568平台开发系列讲解(安卓篇)LED呼吸灯系统流程

1.app层封装后使用NotificationManager发出:NotificationManager.notify() 2.Android 系统架构中:一个manager类对应一个aidl接口,一个manager对应一个底层的服务,notification也是这个架构

内核笔记 3646

HarmonyOS 分布式深度:跨端迁移、数据对象与多设备协同

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

信息安全领域优质创作者|操作系统领域专家 123

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

EtherCAT从站实现(三):DC同步机制与分布式时钟实现

本文详解EtherCAT伺服从站DC同步机制,解决高精度控制中因主站抖动与传播延迟导致的相位偏差问题。通过ESC硬件维护1ns分辨率全局时间,实现从站自主同步,确保PDO更新与控制环采样精准对齐。核心流程包括传播延迟测量、时钟初始化、漂移补偿及SYNC0/SYNC1信号生成。从站需正确配置DC能力与同步模式,主站则通过DCM机制保障发送周期稳定。调试建议结合示波器与寄存器监控,分阶段验证时序关系,确保多轴协同无误。

yangmu3203的博客 135

visio安装包

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

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

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

todoitbo的博客 1万+

迈瑞BS系列全自动生化分析仪LIS协议接口手册(内含HL7和ASTM)

迈瑞BS系列全自动生化分析仪LIS协议接口手册,内含HL7和ASTM)

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

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

weixin_47502228的博客 404

分布式管控系统技术架构深度拆解:从编解码协议到SM4硬件级安全

支持音视频同步及异步切换、最大16路混音输出这些能力,在方案阶段是参数,在调试阶段是测试项。具备工程替代价值的节点应集成4路IR红外、2路RS232、4路I/O、2路继电器及1路RS485,这一档配置使节点具备直接驱动声、光、电及环境控制回路的能力,在中小型会议室场景中可以替代独立中控主机。H.265/H.264双标准支持是基础,每路视频的主码流与双码流独立控制(VBR/CBR)才是影响带宽规划的关键——双码流的意义在于将本地存储与远端预览的码率策略解耦,全局单一码率在多路并发场景下很难兼顾画质和带宽。

2603_95485477的博客 173

粮库分布式温湿度采集系统,基于环境数据的粮食霉变预警开发实战

本方案构建基于分布式温湿度采集的粮食霉变预警系统,针对传统粮库监测滞后、误报率高等痛点,通过分层布设传感节点、边缘计算网关与时序数据平台,融合温升速率、露点判别、多因子耦合等算法,实现从“静态监测”到“动态预警”的升级。系统支持平房仓、浅圆仓等多场景部署,具备国产化适配、断网续传、联动通风互锁等功能,结合工单闭环与模型迭代机制,显著提升储粮安全水平,为智慧粮库建设提供可复制的工程范式。

330

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

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

mosespaul的博客 330

基于分布式软总线的鸿蒙跨端数据同步与冲突合并机制

更恐怖的是,有时候平板上修改的记录,连带把手机上的最新数据给直接抹除了。这就导致了灾难性的数据覆盖。假设用户的手机系统时间比平板快了五分钟,那么在这五分钟的窗口期内,用户在平板上做出的任何修改,在同步时都会被手机上的老旧数据无情覆盖。版本号相同但内容不同时,通过业务层的自定义策略进行合并,这才是分布式应用应有的数据一致性保障。痛定思痛,我们放弃了最粗暴的覆盖式同步,全面重构了基于底层分布式数据管理的冲突解决机制。),这样不仅同步极快,发生冲突时,也只会影响单条记录,而不会导致全局覆写。

2502_91284977的博客 266

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

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

2602_97267507的博客 393

LabVIEW 加以太网:凹版彩印自动套色的分布式改造

凹版印刷机多色套印,张力波动和材料伸缩会让套色偏差持续漂移。手动对版靠老师傅,模拟电路精度差。把每色一个智能节点挂上以太网、上位机用 LabVIEW 做人机界面,套色偏差实时检测、自动修正,还能经互联网远程监控。

bjcyck的博客 266

从零搭建一个 AI Infra 实验室㉒:KubeRay + Ray Serve——另一条分布式 AI Serving 路线

本篇探索 KubeRay + Ray Serve 这条分布式 AI Serving 路线,介绍 Ray、Task、Actor、RayService 与 vLLM on Ray 的核心原理,并在单节点 Kubernetes 上部署 Ray 集群,通过双 Worker、12 个分布式任务和 20 次 HTTP 请求,验证任务调度与服务分发机制。

mosespaul的博客 557

【分布式训练①】总论:大模型为什么必须分布式?训练显存分析与并行策略全景

本文是分布式训练系列的第一篇。我们将从最基础的问题出发——为什么大模型必须用分布式训练?单卡到底差在哪?搞懂显存构成,才能真正理解各种并行策略的设计初衷。

Dawson Zhu的博客 405

集中式与分布式怎么选?聊聊KingbaseES的架构取舍

KingbaseES采用集中式架构,强调事务一致性与SQL完整性,适用于对数据关系紧密、复杂查询和强一致性要求高的场景。其支持单机、主备、读写分离及共享存储集群等多种部署模式,在不拆分数据的前提下实现高可用与扩展性。分布式并非万能解药,仅当面临真实容量与吞吐瓶颈时才应考虑。选型应基于业务实际需求,而非概念偏好,避免过早引入复杂度。

稻草人 1万+
上一篇: 世界第一!蚂蚁图计算TuGraph打破LDBC SNB-BI世界纪录
下一篇: TuGraph Analytics交互式图查询:让图所见即所得
TuGraph
博客等级 码龄4年 183粉丝 43原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值