kevx's Writing

架构 / 云计算 / 技术管理 | kevx@outlook.com 未经授权请勿转载©

Contact Me

Aerospike数据库

什么是Aerospike

先进的分布式高性能KV数据库!数据库!数据库!一个有着完善商业支持的开源产品,目前提供免费版和商业版;在国内外(尤其是国外)有着较广泛的使用。

Aerospike诞生的历史背景

对于任何一个存储产品我们需要结合当时特定历史进程去看待和分析,否则就会面临生不逢时的囧况; 我们现在处在什么样一个时代:

  • 单机性能面临瓶颈,无论是CPU还是内存,其容量和性能的提升速度大幅下降;
  • 近年来内存成本急剧上升;
  • 传统机械磁盘逐步淘汰(尤其在服务器领域);
  • SATA SSD、NVMe SSD等新兴硬件占有比重快速提升;
  • 互联网等行业飞速发展,访问量、数据量几何级增加;

计算机基本原理告诉我们,从CPU二级缓存到内存到磁盘,性能是依次降低的,SSD的出现一定程度上填补了内存和磁盘之间的性能鸿沟, 特别是NVMe SSD,提供了面向新时代的大容量、高带宽、低延迟的硬件基础。

然而我们的软件呢?

无论是持久化Redis还是Cassandra等传统NoSQL产品,它们的构造实现思想仍然是基于多年以前的磁盘文件+文件系统方式; 虽然没有什么计算机问题是中间层不能解决的,但是中间层越多,额外开销就越大,性能就越差;

尽管硬件可能性能提升了,但瓶颈开始出现在OS;例如OS提供的各种缓存和IO调度机制如PageCache/IO Scheduler等, 在落后的SATA磁盘上这将带来较大的硬件提升,但对于新型硬件这层机制在很多场景下会适得其反。

换句话就是,我们在某种程度上缺乏一种能真正发挥出这些先进硬件性能的存储软件。我们需要尽可能的让数据更靠近硬件。

在这样一种背景下 Aerospike诞生了。 Aerospike采用C实现,完全没有GC类问题,最重要一点是它直接使用裸设备,彻底绕过OS文件系统,最大程度发挥硬件性能。

我们为什么需要Aerospike

很简单,两个关键词:性能、成本;Aerospike提供了接近Redis的读写性能和成千上万倍于Redis的存储空间容量,并保持了一个相对可控的Total Cost of Ownership(TCO)成本。

这是历史的必然选择。

特性和功能

既然是分布式存储,它必然无法绕过经典的CAP问题,Aerospike提供了AP支持(是的,没错,和Cassandra一样), 在某些时刻如节点宕机时候,正在更新的数据极小概率会出现少量不一致状态。

下面是几个常用的存储特性:

  • CP
    • Hbase
    • MySQL Cluster
  • AP
    • Cassandra
    • Aerospike
    • Redis Cluster

详细的情况可以参考 https://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdf

功能特性

  • Aerospike提供丰富和易用的API,支持简单KV、Map、List等数据存储结构,熟悉Redis的同学将会感到十分舒适和惬意;
    • 另外支持GeoJSON数据格式,因此可以一定程度满足地理位置检索需求
  • Aerospike支持服务端批处理操作,例如一个场景中需要先执行append,再执行remove,最后执行get这三个操作,可以在一次API调用中搞定,减少了网络交互次数并提高了数据一致性;
  • Aerospike支持服务端脚本,目前支持脚本语言为LUA,这些脚本将直接在服务端运行,可用于实现一些较为复杂的事务性业务逻辑;
  • 支持集群按Namespace切分;
  • 还有许多动人的特性请详细查阅官网;

性能指标

简而言之,在我们3台机器的测试集群上(标准JBOD方式SSD),4K Value长度下的TPS峰值可达100K以上,几乎可以秒杀其它任何一种分布式存储。

应用场景

尽管Aerospike拥有很多优点,但它并非万金油,如果将其用在不恰当的场景则可能会导致一些困扰。

下面几个场景是不合适的

  • 极高的数据强一致,宁可牺牲系统可用性,不允许出现任何数据不一致,例如交易或者账务相关;
  • 单条数据非常长(大于1MB)且不能做拆分的;
  • 需要按条件做全表扫描的,这是一个典型的SQL场景,不适合使用NoSQL;
  • 总体数据规模在200T以上的; 这一条可能存在一些争议,目前确实没有这种规模的集群运维经验,但宏观架构来看,当数据量到达这个程度的时候你需要考虑这是不是一个数据仓库的需求了;
  • 信仰某种非Aerospike存储哲学的信徒(所谓道不同不相为谋);

下面几个场景是特别合适的

  • 读写量较大(高于1W TPS)且数据量在百T规模以内的Key-Value场景;
  • 业务发展较快,对扩容要求较高的;
  • 对性能要求很高且成本敏感的;
  • 愿意跟上时代步伐的;

系统架构

硬性限制

下表只列出较为重要的限制,完整的限制清单请查阅下面的官方文档;

  • 单条数据: 1MB
  • 单分区: 2TB
  • 单机最大数据条数: 40亿

详细参考:https://www.aerospike.com/docs/guide/limitations.html

部署和使用

Aerospike最低一般3台物理机集群,机器要求配备NVMe SSD(普通SSD也可,但延迟会略有上升) 标准机器:32C 128G内存 万兆网卡 单机磁盘10T以内 不得有RAID

附录

什么是NVMe

NVMe其实与AHCI一样都是逻辑设备接口标准,NVMe全称Non-Volatile Memory Express,是使用PCI-E通道的SSD一种规范,NVMe的设计之初就有充分利用到PCI-E SSD的低延时以及并行性,还有当代处理器、平台与应用的并行性。 现在所用的SATA接口与AHCI标准其实是为高延时的机械硬盘而设计的,目前主流SSD依然继续使用它们,随着SSD的性能逐渐增强,这些标准已经成为限制SSD的一大瓶颈。

NVMe标准对比AHCI标准的优势,其中之一就是低延时,原生PCI-E通道与CPU直连可以免去SATA与SAS接口的外置控制器(PCH)与CPU通信所带来的延时。 在软件层方面,NVMe标准的延时只有AHCI的一半不到,NVMe精简了调用方式,执行命令时不需要读取寄存器;而AHCI每条命令则需要读取4次寄存器,一共会消耗8000次CPU循环,从而造成大概2.5微秒的延迟。

---EOF---

返回主页