aerospike与tair对比

1. 性能不弱于ssdb+rocksdb，功能上尽量兼容
tair性能数据未知，从网上查到一些数据，但感觉可信度不高，需要自己测下，不过如果考虑换用ROCKSDB的存储引擎，性能应该和SpringDB相当
areospike的论文中，提到单机读22万qps, 单机写15万tps，但机器配置较低，而且没有介绍数据大小，只能作为简单参考。

2. 跨机房的复制方案
tair支持双机房部署主备两个集群，元数据服务器config server 会负责监控集群健康状态.
aerospike支持多种跨机房部署方式：active-passive, active-active, star等，active集群的node宕机了，则会先将数据同步给备集群去，保证服务持续可用；如果备集群宕机，则主集群会记录数据流同步的断开点，当连接回复后，继续同步；另外，支持按照namepspace为部署单位。
跨机房的数据同步模块XDR模块开源版本并没有实现，可以自己实现。

3. 扩容方便（稳定）
tair一致性哈希数据分布，如果哈希函数分布均匀，则保证了整个集群数据的负载均衡，对于热点桶还没有看到有特殊均衡策略。扩容即按照一致性哈希方法进行。
aerospike 同样采用一致性哈希管理数据分布，但没有中心节点，使用paxos选举协议统一所有节点对集群状态的认知。

4. 更高效的利用内存。Hybrid Storage，冷热数据
tari如果采用levelDB/rocksDB的存储引擎，冷热数据的区分主要靠memtable以及sstable，另外使用存储引擎的blck/row cache作为补充
aerospike也只有内存中索引数据和磁盘（固体盘/机械盘），没有更多冷热数据的级别。

其他：
1. 最好可以和redis兼容
tair不能完全支持redis，只有接口只支持List 和Map和普通KV以及自定义的类型
aerospike支持以下类型：int string 比特流 list map和自定义的序列化数据，并且支持list和map的组合，接口比air更丰富一些，而且支持同一个set的不同record有不同的bin。

2. 长数据支持友好
tair没有对长数据做专门设计，所有使用sstable来组织数据，多列数据会拆分成多个<key,value>存取，同一个容器内的数据一般来说是存在同一个sstable中（有可能被分隔）
aerospike的大数据支持分为两种：
大得List：单独有B+树索引，元素无数量上限；
大数据支持：指的是一个列（bin)很大，则单独使用sub-record存储，其类型可以是任意支持的类型，其大小是1KB- 1MB（取决于磁盘的块大小)，和父record共享锁和访问接口 长数据应该是不可嵌套存储的(即长数据中不可再包含长数据）

3. 过期时间的支持效率好
tair在接口中可以指定数据的过期时间，过期后则对外不可见，资源回收的方式没有查到，需要看代码搞清楚，猜测是后台线程批量执行，对于levelDB存储引擎，猜测是合并时候才会执行过期数据删除。
areospike中没行都有过期的时间戳，有个专门额组件Degragmenter负载回收内存和磁盘数据，这个Degragmenter应该就是个后台线程，猜测定时+资源紧张时候出发其工作。

4. SSD空间占用小，支持压缩
tair使用levelDB存储引擎的话，是使用snappy压缩算法，压缩比率75%。
aerospike在其公开资料中没有找到相关说明，需要看代码进一步确定。

5. 更冷的数据？
tair和aerospike对更冷的数据都没有支持。