写点什么

专访 FoundationDB 联合创始人 Nick Lavezzo

  • 2013-01-20
  • 本文字数:1759 字

    阅读完需:约 6 分钟

FoundationDB 是一个数据库,它保证了 ACID,同时还具有通常只有 NoSQL 数据库才有的高性能和可用性。InfoQ 对该项目的创始人之一 Nick Lavezzo 做了独家专访,从他那里我们获得了更多与该项目相关的内容。

InfoQ: 我们了解到为了避开 CAP 定理宣称的限制,实现 ACID 和可扩展性,FoundationDB 使用了两种不同类型的节点进行读写操作,事实是这样吗?你可以详细地解释一下这个架构吗?

Nick: FoundationDB 并没有避开 CAP 定理;它只不过是采用了非传统的方式(对 NoSQL 而言)在网络分区间维护一致性。但是构建一个分布式的、完全一致的数据库很难;因此,为了让事情更简单,我们使用不同的服务器担当不同的角色。其中,最重要的两个角色是事务服务器和存储服务器。事务服务器负责检查发生的冲突,以保证 ACID。存储服务器负责存储大量的有序键 - 值对,同时为事务服务器批准的读写请求提供服务。当然,在一个单独的物理机器上或者一个较小的集群中,这些角色可能重叠,一台电脑可以同时做多个任务。想要获取更多的信息可以在我们的网站上查看更加详细的解释

InfoQ:你提到 FoundationDB 和一个“分层的”生态系统将会有开源和商业两个版本——对于爱好者而言,现在能够获取它们的源码吗?

Nick:我们一直在致力于构建核心数据库,但是我们对内部层的清理和文档化工作做的还不够,因此还不能公开对外发布(不过在我们的 alpha 测试者的要求下,现在这一层已经可以访问)。在往 beta 版进发的过程中,我们计划为层创建公共仓库。这些层一方面是揭示高层次数据模型的优秀工具,另一方面也展示了基于 FoundationDB 的有序键 - 值对 API 构建强大的应用是多么地容易。现在对层 / 应用程序代码示例有兴趣的人,可以在这里查看一些示例

InfoQ:你提到一个构建在 C++ 之上的新语言 Flow,同时还提供了工具——可以分享一些相关的细节么?

Nick:我们已经在网站上发布了一段新内容,解释了 Flow 以及构建它的目的。

InfoQ: 现在有人开始使用 FoundationDB 构建应用程序了么?

Nick:我们的测试员已经在构建基于 FoundationDB 的应用程序了,但我并不认为这是你期望的答案。你的意思应该是指生产环境中的应用程序,例如在它上面运行业务。FoundationDB 现在正在 Alpha 阶段。在我们推出快照备份功能之前,也就是几周之前,我们不推荐任何人在生产环境中使用它。无论一个系统如何容灾,如果有人意外地(或者故意地)删除数据库中的数据,你都需要一个外部备份来恢复生产环境的应用程序。现在我们有了这个功能,所以我们正在和一些 alpha 测试者们一起将它应用于一些生产环境中的项目上。

InfoQ:FoundationDB 现在或者将来能够支持全球分布式的数据库节点么,就像 Google Spanner 那样?如果是,它将如何实现?

Nick:是的。FoundationDB 就是为了在本地和跨数据中心的集群中使用而设计的。在多数据中心配置环境中运行时,FoundationDB 能够感知网络拓扑并做出智能的决定,例如在不同的数据中心存储数据副本。和 Google Spanner 一样,FoundationDB 并不会使用全球各地所有的数据中心创建一个单一的、全局的数据库;相反,它会创建一个能够在几个临近的数据中心上高效运行的数据库。(通过在全球各地自动移动数据可以加快数据读取速度,但是,数据写入则是一个更加困难且特定于应用程序的工作。Spanner 和 FoundationDB 都没有彻底解决这个问题。)

我们如何实现它呢?我认为解释它最简单的方式就是,所有像 FoundationDB 或者 Spanner 这样的系统都会有一个复杂的保障层,该层和其他层一起保持系统正确。Spanner 的实现方式是构建一个独立的“全局变量”:时间。集群中的任何一个节点都能够对它进行强引用。例如,如果计算机 A 更新数据,计算机 B 读取数据,Spanner 的 TrueTime 能够保证:如果 B 的读取操作发生在 A 的写入操作之后,那么 B 看到的一定是修改后的值。FoundationDB 使用一种不同的策略:它使用一个名为 Paxos 的算法(我们的“全局变量”)存储少量的信息,并从中构建其它的保证和引用,而不是依靠时钟。

英文原文地址 Interview With Nick Lavezzo, Co-Founder of FoundationDB


感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2013-01-20 07:471592
用户头像

发布了 321 篇内容, 共 122.1 次阅读, 收获喜欢 19 次。

关注

评论

发布
暂无评论
发现更多内容

2022年中国证券类APP创新专题分析

易观分析

金融 证券 证券app

详解UDS CAN诊断:SecurityAccess Service(SID:0X27)

不脱发的程序猿

汽车电子 CAN ISO 14229 诊断和通信管理功能单元 SecurityAccess Service

群晖NAS设置Calibre个人电子图书馆

刘旭东

群晖 Calibre 个人图书

2022年人民满意手机银行服务白皮书

易观分析

金融 白皮书 手机银行 用户

从源码角度看React-Hydrate原理

flyzz177

React

React源码分析(一)Fiber

flyzz177

React

React-Hooks源码深度解读

flyzz177

React

看透react源码之感受react的进化

flyzz177

React

TiCDC 在大单表场景下的性能优化:我们如何将吞吐量提升 7 倍?

PingCAP

#TiDB

如何确定解决的问题的价值?

珑彧

方法论

2022年11月中国网约车领域月度观察

易观分析

网约车 行业 打车

ChatGPT 使用 API 进行 Postman 调用测试

HoneyMoose

Kubernetes 跨集群流量调度实战 :访问控制

Flomesh

Service Mesh 服务网格 服务网格

架构训练营模块三作业

现在不学习马上变垃圾

架构训练营10期

《解构领域驱动设计》-软件复杂度解析

珑彧

读书笔记 方法论 领域驱动设计 DDD 复杂

ChatGPT 最近火得不要不要的

HoneyMoose

Java高手速成 | 数据库实训:图书馆管理系统建模

TiAmo

数据库 管理系统 1月月更

从recat源码角度看setState流程

flyzz177

React

属于 PingCAP 用户和开发者的 2022 年度记忆

PingCAP

#TiDB

Reids的BigKey和HotKey

小小怪下士

Java redis 程序员

4天带你上手HarmonyOS ArkUI开发——《HarmonyOS ArkUI入门训练营之健康生活实战》

HarmonyOS开发者

HarmonyOS

LiveMe x TiDB丨单表数据量 39 亿条,简化架构新体验

PingCAP

#TiDB

2023-01-04:有三个题库A、B、C,每个题库均有n道题目,且题目都是从1到n进行编号 每个题目都有一个难度值 题库A中第i个题目的难度为ai 题库B中第i个题目的难度为bi 题库C中第i个题目

福大大架构师每日一题

算法 rust Solidity 福大大

TableLayout(表格布局)

芯动大师

Android Studio tablelayout 表格布局

链上隐私交易成新刚需,Unijoin.io或成该赛道新契机

股市老人

k8s 学习实战(一)

AiDaddy

k8s安装 kubenetes

5A原则

穿过生命散发芬芳

1月月更

深入react源码看setState究竟做了什么?

flyzz177

React

谈谈你在面试中遇到的一面、二面、三面有什么区别?

风铃架构日知录

Java java面试 程序员面试 面试‘’ 面试流程

每个人都必须为2023年的十大基本技术趋势做好准备

超自动化

AI 超自动化

一文教会你mock(Mockito和PowerMock双剑合璧)

京东科技开发者

测试 powermock Mock pom 企业号 1 月 PK 榜

专访FoundationDB联合创始人Nick Lavezzo_大数据_Roopesh Shenoy_InfoQ精选文章