BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

探讨NuoDB数据库的架构—2

| 作者 Seth Proctor 关注 0 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2013年12月21日. 估计阅读时间: 10 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在本文的第1部分,我们介绍了NuoDB,并对它的几个主要特性进行了讲解:三层架构、对等的节点以及原子这个基本的数据单元。此外还讲述了版本控制、用以处理数据更新冲突的并发系统以及如何实现一致性。

运行中的事务

你现在已经熟悉了整体模型、内部的结构以及版本控制,接下来让我们看几个简单的例子,以帮助你更好地理解它们在实际中是怎样运用的。为了简单起见,假设有一个简单的数据库,包含两个事务引擎(TE)和一个存储管理器(SM),从这个简单配置着手研究,应该能够很简单地推导出更复杂的配置。

首先考虑一下原子是怎样被导入到这两个TE缓存中的。假设有一个原子存在归档中,但并不存在任何缓存中,当某个客户端连接到第一个TE并且启动一个需要这个原子的事务时,TE就会在它的目录(Catalog)结构中进行查找,当它发现缓存中没有该数据时,就会到SM中去获取对象。这时,目录结构就会反映出原子已经处于第一个TE的缓存中了,并且该TE将被认为是相关数据的Chairman(主持人)。

此时如果在第二个TE上启动一个事务,并且该事务需要同一个原子中的数据时,目录将会告诉事务可以在SM与第一个事务这两处找到该原子。虽然第二个TE可以自由地选择从哪里获取这个原子,但在实际过程中它总是会从第一个TE请求该原子,因为从内存中的拷贝获取原子速度更快。此时目录会相应地进行更新,显示原子已经存在于两个缓存中了。

接下来,让我们看看当原子中的数据产生变化时会发生些什么。举个例子,假设原子中的数据里的某一行被更新,为了接受这个更新,运行该事务的TE需要发送两条消息:一是对所有包含该数据拷贝的对等进程(在本例中就是指另一个TE以及SM)发送一条等待更新的消息,二是对Chairman发送一条申请批准该更新的权限的消息。如果该更新发生于第一个TE,那么第二条消息的发送会被短路(跳过),因为该TE本身就是Chairman。两条消息都是异步执行的,这确保了事务能够继续执行。如果没有发生任何冲突情况,Chairman最终会接受该更新,并发出响应。

如果两个事务同时尝试更新同一份数据,就会发生冲突。哪个事务能够首先将请求传递给Chairman就能够“获胜”,另一个事务最终会收到一条更新被拒绝的响应。此时这个失败的事务必须被回滚,随后再次尝试。

之前我曾经提过,NuoDB对提交协议的支持很灵活,现在就会讲到它的应用了。为了将某个客户端的提交执行成功的信息发送回去,TE必须始终确保ACID中的原子性、一致性和隔离性,但在持久性方面则拥有一定的灵活性。

在上面的示例中,更新消息将会异步地发送给所有拥有该对象拷贝的对等进程,包括SM在内。当消息在可靠的频道中传递时,除非我们等待确认消息的到来,否则是没有办法知道该SM的生存时间是否足够使该数据保持持久性的。作为数据库配置的一部分,你可以选择某个TE在报告提交成功前是否需要等待确认消息。由于你可以选择性地在运行时打开日志功能,实际上你所需要从SM返回的内容也就有了多个版本。

因此提交即可以表示消息已发送至所有的对等进程,也可以表示SM对本次改变的响应已进行日志记录或者已经被写入持久化的归档中,提交还可以表示至少有某些最小数量的SM发送了响应。这种方式给了你充分的灵活性,你可以决定在发生提交失败时你的持久化保证有多可靠,也可以决定你的分布式数据库运行有多快。

管理层

我之前曾提到过,NuoDB有一个管理层,正是它支持了按需伸缩功能以及那些我们已见识过的迁移模型。每个主机系统都运行着一个本地的管理代理,代理构成了一个与数据库无关的对等网络。我们将这个互联主机的集合称为一个领域(Domain)。

领域包含一个单一的本地管理视图,这使得监控、管理及自动化等数据库活动变得简单。每个代理都负责它的本地主机,有些代理还会以中介(Broker)的角色运行,中介将整个领域展示为一个全局视图。所有中介都具有相同的知识与能力,因此如果你有多个中介在运行,你就可以访问管理与自动化接口。通过中介,你可以启动、停止或迁移数据库,改变你的配置,监控以及捕获TE和SM的日志记录,并运行一切按预计运行。

由于数据库就是一个运行中的进程集合而已,要在一台单独的主机上运行多个数据库也很方便。换句话说,管理层能够支持多租户(multi-tenant)系统的部署,每个租户运行着自己的数据库,它们在进行级别上进行了隔离,由自己的安全通道进行保护,并将数据存于自己的归档内。那么我们在一个单一的系统里可以创建多少个数据库呢?关于这一点在我们的博客中的“支持密集部署”文章中谈论了更多内容。

SQL客户端在连接到数据库时,正是利用中介而得以找到TE的。这就使中介的功能像一个简单的负载均衡器一样,它了解领域中发生的一切,并能够智能地决定让客户端连接到哪里。

总结NuoDB的功能

了解了这些特性之后,让我们再回头看看我说所的云伸缩,我认为有一些用例是尤其适合NuoDB进行处理的。首先,它不仅支持自动化、按需水平伸缩,并且在拥有这些能力的同时还提供了高可用性(HA)。这种高可用性并非来自预先搭建的额外的故障转移功能,而是因为NuoDB能够监控系统错误,并且非常迅速地将新资源上线所带来的。这种反应迅速的高可用性意味着你不需要为了避免错误而带来多余的开销,并且在面临错误情况时依然能够保持良好的可用性。

其次,NuoDB能够为跨越数据中心、并且分布在不同区域的数据库提供一个单一的逻辑数据库视图。这一点显然有助于高可用性,不仅如此,如果你的应用程序的用户来自不同地方,而且你希望让他们尽量连接到最接近他们的应用与数据,这一特性也非常关键。NuoDB支持按地理位置分布,因为连接系统的客户端会乐于使用本地化的数据,因此尽管已经有了简单负载均衡、按需缓存以及区域间的异步分发功能,单一数据库这一特性仍然能够将大多数协调信息保持在一个本地区域内。

再次,因为MVVC为NuoDB提供了一个高效的快照隔离模型,它能够很好地支持对同一份数据的操作性与分析性的访问。换句话说,对频繁更新的数据进行运行时间较长的只读查询也不会产生冲突。这一特性有助于简化部署操作,否则部署时将不得不运行多个数据库,并且要不断地试图同步数据集。

最后,NuoDB是全自动的。无论是按需水平伸缩,还是多租户的运行效率,我们都将数据库当做服务看待,它需要由简单的SLA(服务级别协议)和策略进行驱动。这正是NuoDB的开发方向。

NuoDB的下一步是什么?

我在本文中想表达的是,NuoDB展现了一种全新的架构,在设计的最初就支持水平伸缩、敏捷式部署与自动化。可以很方便地加入新的主机并扩展系统能力,并且在出现大量的数据加载或者系统错误时能够自动地扩展,还能够跨多个数据中心扩展数据库。回到这篇文章开始的地方,我认为这些能力足以保证NuoDB是一个优秀的云伸缩数据库。

我们当前的工作是使自动化功能进一步简化。你可以通过简单的SLA详细地定义你对某个数据库的需求。无论你是否正打算在笔记本上进行开发,管理你公司的内部数据库或是在互联网上启用一个服务,这一特性让NuoDB使用起来就像一个服务一样简单。

我们正在扩展按地理位置分布的数据库的功能,它在你遇到错误时提供了更多灵活性,并且进一步保证了数据可用性。我们也在继续加强服务端编程模型,存储层并行的能力,并且改善了SQL与管理客户端的API。我希望你能够去尝试一下,然后告诉我你的想法。

关于作者

Seth Proctor是NuoDB公司的CTO,在可伸缩系统的研究、设计和实现上有超过十五年的经验。这些经验来自于网络、语言、操作系统、安全、数据库和分布式环境等领域,然后凝结成了NuoDB产品。在NuoDB之前,Seth就职于Nokia,负责内部私有云的架构。再往前,Seth在Sun公司的研究实验室工作,和产品组、大学进行合作。

Seth拥有八项跨多个技术领域的先进专利。还有五项专利正在等待批准,这五项专利都是NuoDB去中心化数据库部署中提升数据库效率和最终用户灵活度相关的。你可以从www.nuodb.com联系到他。

查看英文原文:Exploring the Architecture of the NuoDB Database, Part 2

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT