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 到 Twitter,都在使用持久化的内存键值存储作为数据基础架构的核心——无缓存化。
如今每家平台都需要全天候的服务才能保证优质的用户体验、达成服务水平协议,还要通过维护和备份做到始终可用。许多 Aerospike 客户刚开始使用较小的集群。当他们的产品不仅仅是增长,而是爆炸式增长的时候,他们发现很容易就可以通过增加服务器而扩展服务。根本没有必要重启现现有节点、客户端,或是计划停机时间等等。
InfoQ:Aerospike 架构里是否有持久化的后台数据库或者完全的内存数据库?
Brian:Aerospike 在使用 RAM 的时候是持久化的,标准配置会写入磁盘。由于不通过磁盘读取数据,因此没什么性能影响。当使用闪存或 SSD 时,数据会同步写入主备机。在数据块写入到磁盘是时是队列维护的,所以所有副本都是持久化的,而且没有性能影响。
InfoQ:它支持什么类型的监控?
Brian:有很多方式可以用来监控 Aerospike。 Aerospike 监控控制台(AMC)提供了一个很全面的仪表盘来监视集群的活动。它通过 vagrant 预装在 Aerospike 虚拟机中,并注册了亚马逊 AMI(亚马逊系统镜像)。
Aerospike 支持 Nagios 和 Graphite 插件——这些 Python 写的插件可以作为其他系统的模板。
InfoQ:使用 Aerospike 有什么限制?
Brian:Aerospike 在如下场景可能不是最佳选择:
- 工作负载总是只读的
- 如果工作负载是批量分析,旋转介质(HDDs)会更高效
关于受访者
Brian Bulkowski**,Aerospike联合创始人兼 CTO**,在设计、开发和优化网络系统和高性能网络规模基础架构方面有着 20 多年经验。他的职业生涯中曾在 Novell、Liberate 和 Aggregate Knowledge 多次担任技术带头人。Brian 拥有布朗大学的数学和计算机科学学士学位。
查看英文原文: Aerospike NoSQL Database Architecture
感谢邵思华对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。
评论