- 综合排序
- 最热优先
- 最新优先
- 来自专栏PingCAP的专栏
FoundationDB 学习 - 事务流程
作者：唐刘 不久之前，FoundationDB （后面用 fdb 简化） 重新开源，对于大家来说，这真的是一个非常好的消息。 后面我会详尽的捣鼓折腾下 FoundationDB，做下 benchmark，也正在将它集成到我们的 YCSB 里面，毕竟对我来说，至少 fdb 那套 deterministic 理念是可以借鉴学习的。
1.9K140发布于 2018-05-03 - 来自专栏喔家ArchiSelf
支持事务的分布式NoSQL——FoundationDB
同时，FoundationDB提供了一个最小的、精心挑选的功能集，可以在FoundationDB上构建不同的系统。 1.2 FoundationDB的由来与特点 FoundationDB是在2009年创建的，希望成为构建高级分布式系统所需的基础系统。 例如，FoundationDB记录层添加了用户从关系数据库中期望的大部分内容，图数据库JanusGraph提供了一个基于FoundationDB层的实现。 【参考资料与关联阅读】 FoundationDB. https://github.com/apple/foundationdb. FoundationDB Joshua. https://github.com/FoundationDB/FoundationDB-joshua.
2K30编辑于 2023-09-15 - 来自专栏飞总聊IT
苹果公司开源FoundationDB的简单分析
美国时间 2018年4月19日，苹果公司宣布开源FoundationDB。 FoundationDB刚出来的时候，有很多公司使用。 但是2015年苹果公司收购了FoundationDB以后，导致源代码被从GitHub上删除，FoundationDB的开发人员也再也不回答任何技术问题，所以这之后长期一直使用FoundationDB的主要还是苹果公司 自从4月19日苹果公司宣布FoundationDB再次开源以来，唯一比较有影响力的宣称自己在使用FoundationDB的公司是Snowflake。 鉴于目前使用FoundationDB的商业化应用还不多，披露的信息尤其少，尚不好判断在商用场景下FoundationDB的舒适区和不适区。
6.3K20发布于 2018-07-25 - 来自专栏linjinhe的专栏
FoundationDB Record Layer: A Multi-Tenant Structured Datastore
FoundationDB Record Layer: A Multi-Tenant Structured Datastore 是苹果公司在 SIGMOD 2019 上发表的一篇论文，介绍他们在 FoundationDB FoundationDB 和 FoundationDB Record Layer 的代码都在 Github 上开源了。 FoundationDB Record Layer 是建立在 FoundationDB 之上的类关系模型的结构化数据层，支持多租户，以 library 方式提供给应用。 FoundationDB Record Layer 的架构（图片来自论文） FoundationDB Record Layer 在设计上是完全无状态的（stateless），并且是以 library 的方式直接链接到应用程序中 如上图所示，FoundationDB Record Layer 的整体架构： 应用程序（Application）通过 library 的方式使用 FoundationDB Record Layer。
1.4K40发布于 2019-06-24 - 来自专栏ATYUN订阅号
【业界】苹果公司继续开源活动：在GitHub上发布了FoundationDB
苹果公司今天宣布，FoundationDB数据库架构正式开放源代码。这是苹果公司最近采取的一项举措，旨在向公众提供更多的非秘密软件项目。 虽然FoundationDB不是苹果公司最知名的产品，但它是iCloud的数据库，是苹果公司庞大的基于云的服务器系统，用于存储和同步数以亿计的用户帐户以及数以万亿计的数据。 苹果公司将FoundationDB描述为一个可扩展的“分布式数据存储”，它是基于数据一致性而设计的，可以部署在商品硬件集群上。 为什么苹果公司开放它? “我们相信FoundationDB可以成为下一代分布式数据库的基础，”该公司解释说，“该系统由一个简单的核心加上多个特定于数据类型和独立访问模式的层组成。 苹果公司提供的FoundationDB数据库可在Foundationdb下载页面中下载，不仅如此，macOS、Windows和Linux二进制安装程序的源代码也可在此下载。
71240发布于 2018-07-27 - 来自专栏深度学习与python
苹果 iCloud 的“极端”架构：管理数十亿独立用户数据库！
FoundationDB 和 Record Layer 解决了这两个问题。 FoundationDB 苹果对 FoundationDB 的公开程度要高得多。 他们于 2015 年收购了 FoundationDB，并发表了多篇论文，详细介绍了他们对 FoundationDB 的使用情况。 FoundationDB 是一个开源、分布式、事务性的键值对存储。 在 FoundationDB Record Layer 的论文中，他们写道： “[FoundationDB Record Layer 用于] 为服务于数亿用户的应用程序提供强大的抽象。 FoundationDB、Record Layer 和 CloudKit 的结构如下所示： 来源：FoundationDB Record Layer：开源的结构化存储 FoundationDB 完成所有分布式系统和并发控制的工作 FoundationDB 和 Record Layer 一起为苹果解决了 4 个关键问题，这些问题是单独使用 Cassandra 或单独使用 FoundationDB 无法解决的。
1K10编辑于 2024-01-23 - 来自专栏一臻数据
【Apache Doris】3.0存算分离｜标准部署篇
默认集群信息文件 fdb.cluster将存放在/etc/foundationdb/fdb.cluster，默认集群配置文件 foundationdb.conf 将存放在/etc/foundationdb /foundationdb.conf。 默认将数据和日志分别保存在/var/lib/foundationdb/data/和/var/log/foundationdb。 其中，fdb_cluster 是 FoundationDB 集群的连接信息，通常可从 FoundationDB 所部署机器上的 /etc/foundationdb/fdb.cluster 文件中获得。 其中，fdb_cluster 是 FoundationDB 集群的连接信息，通常可从 FoundationDB 所部署机器上的 /etc/foundationdb/fdb.cluster 文件中获得。
2.6K11编辑于 2024-12-24 从零开发分布式文件系统(三) :JuiceFS｜沧海｜3FS 百万 OPS 答疑（2）(ceph 默认 5 千)
，就没有瓶颈 误区 “FoundationDB 有分布式事务，系统极限就是线性扩展。” 真相 FoundationDB 是单集群 Leader-based 协议，热点 key-range 会导致 leader 抢占成为瓶颈。 提前演练 FoundationDB 风暴的冲突重试。 三、 误区 2：3FS 可以天然抗 rename 风暴 “3FS 用 FDB 做事务，rename 高并发完全没问题。” 真相 FoundationDB 是乐观事务，如果 rename 操作涉及同一个目录，冲突率会飙升。 rename 风暴下，FDB 的冲突重试会造成尾延迟爆炸。 FoundationDB已在苹果公司内部的生产环境使用三年，主要用于iCloud上的云存储服务 FoundationDB有潜力成为下一代分布式数据库系统的底层基础设施 在独立的KV存储服务上实现事务ACID
35310编辑于 2025-10-10- 来自专栏云原生民工
Byconity on Kubesphere
1 2 3 4 5 6 7 8 9 docker pull foundationdb/foundationdb-kubernetes-sidecar:6.2.30-1 docker pull foundationdb /foundationdb-kubernetes-sidecar:6.3.23-1 docker pull foundationdb/foundationdb-kubernetes-sidecar:7.1.15 -1 docker pull foundationdb/fdb-kubernetes-operator:v1.9.0 docker pull byconity/byconity:0.1.0-GA
47310编辑于 2024-02-03 3FS为什么没有完全遵守POSIX语义
针对元数据服务组件 是无状态的设计，采用FoundationDB存储元数据 • 无主从区别，每个服务都对我提供功能 • 更不会缓存大量元数据 采用FoundationDB 有点如下 核心优势 对3FS的意义 实现元数据服务的无状态与线性扩展 采用存算分离设计，元数据本身持久化在FoundationDB中，Meta Service节点无状态。 架构解耦，专注上层优化 FoundationDB是专注“数据库下半部分”的事务性KV存储。 这在采用FoundationDB时体现为： 为了避免其高隔离级别事务（SSI）和**跨分片两阶段提交 场景：有两个进程操作同一个日志文件 train.log。 3 最终提交 • 元数据服务收到客户端的报告后，并不一定立即更新FoundationDB。
16010编辑于 2025-12-24- 来自专栏深度学习与python
DeepSeek 3FS 架构分析和思考
Meta Service 提供元数据服务，采用存算分离设计： 元数据持久化存储到 FoundationDB 中，FoundationDB 同时提供事务机制支撑上层实现文件系统目录树语义； Meta Service 选主机制 mgmtd 的选主机制基于租约和 FoundationDB 读写事务实现。租约信息 LeaseInfo 记录在 FoundationDB 中，包括节点 ID、租约失效时间、软件版本信息。 上述流程通过以下几点保证了选主机制的正确性： LeaseInfo 的读取和写入在同一个 FoundationDB 读写事务里完成，FoundationDB 读写事务确保了即使多个 mgmtd 并发进行租约检查 3FS 选择使用 FoundationDB 作为底层的 KV 存储系统。 利用 FoundationDB SSI 隔离级别的事务能力，目录树操作串行化，冲突处理、一致性问题等都交由 FoundationDB 解决。
3.1K10编辑于 2025-03-12 - 来自专栏ByConity
ByConity build on Centos
ninja-linux.zip && mv ninja /usr/local/bin/# foundationdbRUN cd ${WORKDIR}/tools && \ yum localinstall -y foundationdb-clients 部分资源可从 https://github.com/enjay-s/software 下载echo "tools start"test -d tools || mkdir toolstest -f tools/foundationdb-clients -7.1.27-1.el7.x86_64.rpm || curl -L -o tools/foundationdb-clients-7.1.27-1.el7.x86_64.rpm \https://github.com /apple/foundationdb/releases/download/7.1.27/foundationdb-clients-7.1.27-1.el7.x86_64.rpmtest -f tools
37721编辑于 2024-12-19 - 来自专栏大数据和云计算技术
大数据和云计算技术周报（第57期）
本期会给大家奉献上精彩的：HBase、Neo4j、FoundationDB、日志采集、知识图谱、数据管理、架构选型、IPv6、Elasticsearch、Alluxio、Redis、MongoDB。 https://mp.weixin.qq.com/s/ZYqDSx333nTCYBpHydfYMg 3 FoundationDB 苹果公司开源FoundationDB的简单分析，值得入门看看 https
76230发布于 2018-07-26 为啥 DeepSeek-3FS元数据无状态，CephFS 的 元数据 要搞得这么复杂？
文件属性获取 CHUNK:{inode}:{offset} chunk_id 数据块定位 3FS 使用 FoundationDB 作为其元数据的分布式存储系统。 FoundationDB 提供键值存储接口，并支持可序列化快照隔离 (SSI) 事务。 3FS 将所有元数据以键值对的形式存储在 FoundationDB 中。 元操作利用 FoundationDB 的事务： • 用于元数据查询的只读事务：fstat、lookup、listdir 等。 • 用于元数据更新的读写事务：创建、链接、取消链接、重命名等。 管理，不然无法形成一棵树 特性 Ceph (CephFS) 3FS (Fire-Flyer File System) 核心设计 目录即对象 全局有序KV，前缀范围查询 存储后端 RADOS 对象存储 FoundationDB 四、面试官反问：节点故障, 扩容如何保证一致性 4.1 3FS 甩手掌柜 • 把文件才做 变成kv操作， • 然后保证kv操作一致性 元操作利用 FoundationDB 的事务： • 用于元数据查询的只读事务
34010编辑于 2025-10-10- 来自专栏分布式存储
从零实现分布式文件系统(二) 如何在不升级硬件的前提下,小文件并发读写性能提升十倍
而非 TiKV Meta Service 提供元数据服务，采用存算分离设计 • 元数据持久化存储到 FoundationDB 中，FoundationDB 同时提供事务机制支撑上层实现文件系统目录树语义 事务模型的差异与成熟度 • FoundationDB 的事务模型设计非常严谨，事务隔离和一致性强，尤其擅长处理复杂跨多键事务。 • 3FS 需要强事务保证，FoundationDB 能提供更加稳健的事务保障。 2. 一致性和容错保证 • FoundationDB 在分布式一致性算法（Paxos）和故障恢复方面经验丰富，设计成熟。 架构设计和接口差异 • FoundationDB 提供简单且强大的多版本键值事务接口，易于构建复杂系统如文件系统。
64211编辑于 2025-08-15 - 来自专栏IT技术订阅
苹果iCloud架构的关键组成
数据库技术 - FoundationDB和Cassandra： 苹果使用FoundationDB作为其核心数据库技术之一，特别是对于CloudKit服务，而Cassandra则用于处理大量结构化数据的存储和查询
1.1K10编辑于 2024-05-10 从零开发分布式文件系统（四):一道经典面试题，深度对比 CephFS 与 3FS 的元数据架构优劣
等 KV 数据库中 元数据管理 由 MDS 集中管理 由无状态的元数据服务管理 查询方式 通过 MDS 进行查询 客户端直接查询 KV 存储 一致性保证 MDS 提供一致性和事务支持 FoundationDB 3FS 的元数据管理 在 3FS 中，元数据服务是无状态的，所有元数据存储都依赖于 FoundationDB 等分布式事务性键值数据库。 3FS 的元数据服务通过查询 FoundationDB 来获取所需的元数据。 由于 FoundationDB 提供了强一致性和事务支持，3FS 能够确保元数据操作的原子性和一致性。 特性 Ceph (CephFS) 3FS (Fire-Flyer File System) 核心设计 目录即对象，条目存于对象OMap 全局有序KV，前缀范围查询 存储后端 RADOS 对象存储 FoundationDB 它直接将所有元数据存放在全局有序的 FoundationDB 中， 同样创建 /mnt/icfs/dir01/file.txt，在 3FS 中会发生： 1 分配 Inode：系统分配全局唯一的 inode
45910编辑于 2025-10-10- 来自专栏Rust语言学习交流
【Rust日报】2021-08-30 如何来看待 unwrap
目前支持的 backends 有: FoundationDB 单机部署的 SQLite。 一个简单的内存键值存储。
98540发布于 2021-09-08 - 来自专栏AustinDatabases
“龙虾” OpenClaw完蛋了！创始人跑路 OpenAI，三大 AI 巨头关门放狗
2 FoundationDB：被苹果“收编并雪藏”的分布式神作 它是分布式数据库领域的“扫地僧”，最早实现了在分布式 key-value 存储上提供 ACID 事务，其测试框架（模拟各种极端故障）至今仍是业界标杆 昙花一现的原因： * 大厂收编： 2015 年正值 FoundationDB 社区爆发前夕，苹果突然将其收购。收购后的第一件事就是撤下所有公开下载链接，停止商业授权。
15110编辑于 2026-04-16 - 来自专栏ApacheHudi
2025 年 7 月 Apache Hudi 社区新闻
github.com/apache/hudi-rs/contribute/ 数据生态系统的其余部分 • Apache DataFusion Comet和Gluten的比较[22] - DataFusion团队 • FoundationDB DataFusion Comet和Gluten的比较:https://datafusion.apache.org/comet/user-guide/gluten_comparison.html [23]FoundationDB ：一个杀不死的分布式数据库:https://thenewstack.io/foundationdb-a-distributed-database-that-cant-be-killed/ [24]Parquet
38600编辑于 2025-08-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号