为什么会有Aerospike？
Redis是一个纯内存型数据库，性能上没有多大问题。 但这又带来一个新问题，内存是很贵的，所以全内存的存储成本非常昂贵。为了节省成本，我们需要把一部分不经常用到的数据存储到硬盘上，
但是又要求性能不能下降很多，这时候 Aerospike 数据库应运而生，它可以是内存 + SSD 存储。
Aerospike 官网：http://www.aerospike.com/
github地址：https://github.com/aerospike
Redis与Aerospike一些对比
|
redis
|
Aerospike
|
|
|
运维
|
运维成本较高，扩容麻烦
|
部署和扩容都比较容易
|
|
性能
|
读写性能高
|
读性能高，写性能中高
|
|
使用成本
|
纯内存数据库，成本高
|
内存+ssd，成功较低
|
|
其他方面
|
内存浪费严重。 数据结构丰富，应用场景广泛
|
支持二级索引，满足常见需求。支持聚合
|
|
排序
|
支持排序
|
不支持排序
|
|
集群管理
|
简单集群管理
|
相当强大，多个平等的结点，平摊存储所有数据，并且互相备份。集群结点的失效及添加完全自动化处理，不影响用户请求
|
|
事务
|
支持简单事务
|
支持行事务
|
Aerospike支持的数据类型：
Aerospike supports numerous data types used for bin values, as arguments, and as UDF return values. Supported values are:
- integer
- string
- bytes
- double
- list
- map
- GeoJSON
- native-language serialized (blobs)
Aerospike优点：
Aerospike是一个高性能、可扩展、可靠性强的NoSQL解决方案，支持RAM和SSD作为存储介质，并专门针对SSD特殊优化，广泛应用于实时竞价等实时计算领域。官方保证99%的操作在1ms内完成，并提供集群数据自动Rebalance、集群感知客户端等功能，且支持超大规模数据集(100T级别)的存储。
作为KV存储，Aerospike提供多种数据类型，其操作方式和Redis比较类似。除基础功能之外，Aerospike还支持AMC控制台、API等多种监控方式，有集群QPS、健康度、负载等多项监控指标，对运维比较友好。支持集群内数据的自动Rebalance，和Redis集群方案相比，维护成本下降不少。
Aerospike缺点：
- 只支持batch read，不支持batch writes
- 记录大小有限制: <= 1M => 有点小，不过对于我们的场景基本没问题
- bin name长度: <= 14 Chars => 一般来说单字段不会超过，嵌套属性如果拼接就很容易超长
- 没有内建的聚合函数(Aggregations: count, max, min, sum, group by, etc.)，通过UDFs可以支持（queryAggregate），但是使用方式不友好，效率也不高
- namespace 下的sets限制1024，二级索引限制256，唯一binname限制32K，一个namespace下最多4 billion记录
- 范围查询只支持BETWEEN语句，没有小于，大于查询，并且RANGE结果只支持包含
- 范围查询只支持整数类型，不支持浮点数
- Query不支持分页(no cursor or pagination..)
- Query不支持排序(no order by..)
- 不支持动态创建namespace，只能通过修改配置文件、重启服务器
- 只有清空set数据接口，但是并没有真正drop掉sets（会留下empty set，然后一个namespace下只有有1024个sets..）
Aerospike架构一览：https://www.aerospike.com/docs/architecture/index.html