Aerospike NoSQL 数据库架构

jopen 9年前

 

Aerospike 是一个开源的分布式键-值NoSQL数据库。它支持灵活的数据模式,并且支持满足ACID特性的事务。其 架构 包括如下三层:

  • 客户端层: 这一层包括带有Aerospike API的开源客户端库和能够感知数据在Aerospike集群中位置的追踪节点。
  • 集群和数据分布层: 这一层监控集群通讯并提供一些自动化功能,比如故障转移、数据复制和跨数据中心同步。
  • 数据存储层: 这一层负责在DRAM(动态随机存取存储器)和Flash(闪存)中存储数据。

InfoQ采访了Aerospike的联合创始人兼CTO Brian Bulkowski,内容包括NoSQL数据库架构、其优势以及限制。

InfoQ:现在有不少NoSQL解决方案——Aerospike解决了哪些问题?

Brian:Aerospike为应用开发者们解决了键-值存储问题。当他们想要使用支持分片的键-值NoSQL数据库时就应该考虑Aerospike。它为解决大量的网络负载而生,在这一点上很多成功的公司已经证明部署Aerospike的重要性。它不是一个只用于分析功能的数据库,也不是Hadoop 的替代品。

在大规模用户信息存储和会话管理方面,Aerospike的表现都极其出色。而且在很多商家使用实时数据在做的个性化项目、安全项目、移动支付和很多其他项目的例子中,Aerospike都是不二之选。

通过发布Aerospike源代码和最近的一些用户自定义函数,还有二级索引和统计收集而来的数据集的使用,Aerospike可以被选做可扩展高性能应用的数据库。

InfoQ:如何比较Aerospike和关系型数据库?

Brian:Aerospike在一开始就是以擅长做键-值存储的分布式数据库为目标开发的。关系型数据库功能完备但是丧失了主键使用上的速度和规模优势。然而,主键的使用方面——为了性能而做数据反规范化,是互联网应用开发者最看重的一个特性。

关系型数据库是很棒的多功能工具,然而,糟糕的扩展性、缓慢的连接操作(joins)、维护数据关系的复杂性和难以更改的架构降低了应用的性能和开发者的敏捷性。这就是为什么为了打造那些真正令人兴奋的应用,缓存和分片已经被应用多年。

SQL尚未适配几个关键的开发需求。多语言使用要侧重于列表和图的抽象和更高级的数据结构,比如文档。NoSQL数据库给开发者们提供了想要的东西——列表和图作为上层数据类型并且允许跨语言访问。还有一些小的改进,比如可以很容易地保持原子性地更新和读取记录(UPDATE和SELECT),这让开发者的工作变得更轻松。

不同于关系型数据库的实现,Aerospike利用最新的硬件——多核、多CPU服务器和闪存(PCIe卡和SSD),还有可以向外扩展,处理数十亿的对象、TB级的数据和每秒百万级的事务的分布式无共享架构。当下的公有云都可以配置SSD,只需花费RAM的小部分费用就能获得内存般的性能。一个关于“高可扩展性”的 博客 列举了原因。

InfoQ:如何比较它与其他NoSQL数据库?

Brian:一些流行的NoSQL数据库提倡高性能,但是仍然需要缓存技术来解决并发读写的问题。Aerospike优良的内存性能使应用开发更简单,同时部署也更便捷。如果你正在使用NoSQL替代MySQL满足高性能和可扩展性,你需要一个性能很可靠的内存数据库。

然而,开源的缓存系统比如Memcache和Redis,都不容易扩展。它们性能确实很好,但是它们的持久化模型不成熟,而且需要完全的DRAM。扩容服务器的时候要手动分割数据才能避免低性能。

Aerospike从设计之初就同时支持RAM和闪存(SSDs)。淘汰从RAM到闪存之间的数据交换方案,Aerospike实现了一个混合方式,把已分配的索引和数据或者存储在RAM或者SSD中。我们发现对于不同的部署环境,有一些数据最好放在RAM中,而有一些最好放在闪存中,这个工作对Aerospike来讲很简单。

其他的NoSQL数据库只实现了延迟一致性,但是Aerospike默认运行同步复制机制,提供单行ACID属性。读提交是最实用的ACID隔离级别,它为程序员提供了写后读的实时性,确保返回正确结果。Aerospike实现了包括锁存器和短期记录锁的分布式隔离技术,确保了隔离性。Aerospike 提供的持久化机制包括在RAM和持久化存储上的多节点复制,另外每次事务更新都会在发送提交成功信号之前写入集群中的多个位置。更多的细节可以在这篇 超大数据集会议论文 中找到。

Aerospike有力保证让数据离处理它的进程更近,这是通过运行在服务器而非客户端的用户自定义函数实现的。分布式的代码管理器可以使得模块安全地上传至集群,而后高效地执行。这一特性减轻了网络拥堵。举例来说,在数据库中把一个元素添加到列表,列表管理可以写成一个简单的UDF(用户自定义函数),其实就是用自定义操作扩展数据库功能。

其他的NoSQL数据库要求手动分片、手动故障转移、维护窗口等。MongoDB和HBase提供了自动分片,但是MongoDB需要一个区分数据的分片键值作为参数,而HBase要涉及到从原则集里选择一个RegionSplitPolicy(域分配原则)。然而Aerospike是可以自我复合和自动执行一些功能的,包括故障转移和数据再平衡,这极大地减少了维护的工作量。在Aerospike部署中,维护窗口的存在是不必要的——备份和升级的操作会在数据库集群还在响应请求服务的同时就完成了。

InfoQ:Aerospike作为解决方案一部分的最佳用例或者最佳应用是什么?

Brian:Aerospike是一个可以满足广告优化和广告个性化这些低延迟应用的数据库选择。实时竞价广告系统——运行着大量互联网上常见的竞价广告,很依赖服务器上最近的cookie数据变化,还要加上海量的Hadoop分析而来的更深层用户数据。这种类型的大数据应用要求REST API请求响应在毫秒级,而且要把最近行为写到上层数据库。Aerospike被平台用作用户信息存储、服务端cookie存储、实时上下文存储、设备 ID存储和ID映射,可以预见,这些平台必须在1毫秒之内存储和读写几十亿条数据。此外,Aerospike提供金融交易必需的单行ACID特性。

Aerospike还被商家用于在用户浏览商品时生成动态内容——报价和交易信息,并给出相关产品的最佳推荐。以Snapdeal公司举例来说,过去一直使用运行于RAM的MongoDB作为缓存,后来发现性能欠佳。现在他们使用Aerospike,满足了开发人员单页面更多的数据库调用,由此实现了视觉更丰富、利益更大化的网络体验。

我们发现缓存正在变成历史。很多社交媒体公司——从Pinterest到推ter,都在使用持久化的内存键值存储作为数据基础架构的核心——无缓存化。

如今每家平台都需要全天候的服务才能保证优质的用户体验、达成服务水平协议,还要通过维护和备份做到始终可用。许多Aerospike客户刚开始使用较小的集群。当他们的产品不仅仅是增长,而是爆炸式增长的时候,他们发现很容易就可以通过增加服务器而扩展服务。根本没有必要重启现现有节点、客户端,或是计划停机时间等等。

InfoQ:Aerospike架构里是否有持久化的后台数据库或者完全的内存数据库?

Brian:Aerospike在使用RAM的时候是持久化的,标准配置会写入磁盘。由于不通过磁盘读取数据,因此没什么性能影响。当使用闪存或SSD时,数据会同步写入主备机。在数据块写入到磁盘是时是队列维护的,所以所有副本都是持久化的,而且没有性能影响。

InfoQ:它支持什么类型的监控?

Brian:有很多方式可以用来监控Aerospike。 Aerospike监控控制台 (AMC)提供了一个很全面的仪表盘来监视集群的活动。它通过vagrant预装在Aerospike虚拟机中,并注册了亚马逊AMI(亚马逊系统镜像)。

Aerospike支持 NagiosGraphite 插件——这些Python写的插件可以作为其他系统的模板。

InfoQ:使用Aerospike有什么限制?

Brian:Aerospike在如下场景可能不是最佳选择:

  • 工作负载总是只读的
  • 如果工作负载是批量分析,旋转介质(HDDs)会更高效

关于受访者

Brian Bulkowski ,Aerospike 联合 创始人兼CTO ,在设计、开发和优化网络系统和高性能网络规模基础架构方面有着20多年经验。他的职业生涯中曾在Novell、Liberate和Aggregate Knowledge多次担任技术带头人。Brian拥有布朗大学的数学和计算机科学学士学位。

查看英文原文: Aerospike NoSQL Database Architecture