Aerospike-介绍
Aerospike架构
Aerospike是一个开源的分布式键－值NoSQL数据库。它支持灵活的数据模式，并且支持满足ACID特性的事务。其架构包括如下三层：
- 客户端层：这一层包括带有Aerospike API的开源客户端库和能够感知数据在Aerospike集群中位置的追踪节点。
- 集群和数据分布层：这一层监控集群通讯并提供一些自动化功能，比如故障转移、数据复制和跨数据中心同步。
- 数据存储层：这一层负责在DRAM（动态随机存取存储器）和Flash（闪存）中存储数据。
数据模型
1、Namespaces
AS数据存储的最高层级，类比于传统的数据库的库层级，一个namespace包含记录（records），索引（indexes ）及策略（policies）。
其中策略决定namespace的行为，包括：
1.数据的存储位置是内存还是SSD。
2.一条记录存储的副本个数。
3.过期时间（TTL）：不同redis的针对key设置TTL，AS可以在库的层级进行全局设置，并且支持对于已存在的数据进行TTL的设置，方便了使用。
2、Sets
存储于namespace，是一个逻辑分区，类比于传统数据库的表。set的存储策略继承自namespace，也可以为set设置单独的存储策略
3、Records
3.1、key
- 唯一标识. 根据key的hash查询Records
- key的类型：Integers, String, and bytes
- 内部会hash成一个 160-bit(20-bytes) 的digest
3.2、metadata
每一条记录包含以下几条元数据：
1.generation（代）：表示记录被修改的次数。该数字在程序度数据时返回，用来确认正在写入的数据从最后一次读开始未被修改过。
2.time-to-live（TTL）：AS会自动根据记录的TTL使其过期。每次在对象上执行写操作TTL就会增加。3.10.1版本以上，可以通过设置策略，使更新记录时不刷新TTL。
3.last-update-time（LUT）：上次更新时间，这是一个数据库内部的元数据，不会返回给客户端。
3.3、bins
在一条记录里，数据被存储在一个或多个bins里，bins由名称和值组成。bins不需要指定数据类型，数据类型由bins中的值决定。动态的数据类型提供了很好的灵活性。AS中每条记录可以由完全不同的bins组成。记录无模式，你可以记录的任何生命周期增加或删除bins。
在一个库中bins的名称最多包含32k，这是由内部字符串优化所致。（相比于HBase支持几百万列还是有一定差距，如果想直接将HBase表迁移到AS可能需要重新设计存储结构）
数据类型
- integer: 8 bytes
- string: 128 KB;
- bytes
- double: 8 bytes
- CDTs (Complex Data Types)
- list
- map
- GeoJSON (3.7.0+)
- native-languages serialized(blobs)
特点
1、数据存放
数据可以放内存，也可以放SSD。
数据放内存时速度肯定会很快，但这和memcache一样，相比memcache性能并没有优势
数据也可以放SSD，并做了特定优化，相比mysql会更快，但数据操作模型过于简单，可使用场景很少。也比mongo性能更好，但其要求SSD存储，这样容量较小，费用也较高，这时mongo是好选择。
--------现在有不少NoSQL解决方案——Aerospike解决了哪些问题？
Aerospike为应用开发者们解决了键－值存储问题。当他们想要使用支持分片的键－值NoSQL数据库时就应该考虑Aerospike。它为解决大量的网络负载而生，在这一点上很多成功的公司已经证明部署Aerospike的重要性。它不是一个只用于分析功能的数据库，也不是Hadoop的替代品。
在大规模用户信息存储和会话管理方面，Aerospike的表现都极其出色。而且在很多商家使用实时数据在做的个性化项目、安全项目、移动支付和很多其他项目的例子中，Aerospike都是不二之选。
通过发布Aerospike源代码和最近的一些用户自定义函数，还有二级索引和统计收集而来的数据集的使用，Aerospike可以被选做可扩展高性能应用的数据库。
2、数据操作模型
支持 按主键及二级索引筛选数据
支持 聚合 （强大，一个卖点）
不支持排序（通过聚合功能的lua脚本也可能可以实现，但并不现实）
虽然支持类SQL语法操作，但可进行的操作非常简单，好于memcache, 稍好于mongo，比redis差些，跟mysql完全没法比，但其聚合功能还比较强大。
---------如何比较Aerospike和关系型数据库？
Aerospike在一开始就是以擅长做键－值存储的分布式数据库为目标开发的。关系型数据库功能完备但是丧失了主键使用上的速度和规模优势。然而，主键的使用方面——为了性能而做数据反规范化，是互联网应用开发者最看重的一个特性。
关系型数据库是很棒的多功能工具，然而，糟糕的扩展性、缓慢的连接操作（joins）、维护数据关系的复杂性和难以更改的架构降低了应用的性能和开发者的敏捷性。这就是为什么为了打造那些真正令人兴奋的应用，缓存和分片已经被应用多年。
SQL尚未适配几个关键的开发需求。多语言使用要侧重于列表和图的抽象和更高级的数据结构，比如文档。NoSQL数据库给开发者们提供了想要的东西——列表和图作为上层数据类型并且允许跨语言访问。还有一些小的改进，比如可以很容易地保持原子性地更新和读取记录（UPDATE和SELECT），这让开发者的工作变得更轻松。
不同于关系型数据库的实现，Aerospike利用最新的硬件——多核、多CPU服务器和闪存（PCIe卡和SSD），还有可以向外扩展，处理数十亿的对象、TB级的数据和每秒百万级的事务的分布式无共享架构。当下的公有云都可以配置SSD，只需花费RAM的小部分费用就能获得内存般的性能。一个关于“高可扩展性”的博客列举了原因。
3、集群管理
相当强大，多个平等的结点，平摊存储所有数据，并且互相备份。集群结点的失效及添加完全自动化处理，不影响用户请求。
相比memcache，这是它强大的地方，也不会弱于其它nosql的集群管理。
4、聚合功能
这里聚合的概念等同于mysql中的聚合。可以通过编写lua脚本，实现对数据的聚合，此时aerospike可以看作一个分布式的基于内存的map-reduce计算平台，相比普通的hadoop map-reduce,速度是很快的,当然，可处理的数据量相对较少。
5、事务
支持行事务
6、坑点
只支持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
与redis相比
- 从性能上来看，二者都是用C写的，Redis是单线程的，只支持内存方式，Aerospike是多线程的，支持内存+SSD+HDD的存储方式。
-
从数据存储上来看，二者都支持多种数据结构和操作，Redis的API是以数据结构为中心的，应用程序必须知道Redis节点且每节点最多有2的32次方个key，Aerospike所有操作都不是预定义的，应用程序不需要知道节点，每个名称空间最多有2^160个键。
-
从持久化方面来看，二者都支持持久化，Redis支持RDB和AOF，Aerospike本身支持内存+SSD模式，也结构化日志文件系统，且支持热重启。
-
从数据同步上来看，Redis需要主从手动配置，是异步复制方式，各节点完全是主或从节点。Aerospike主从自动分配，是同步复制方式，各节点既是主节点又是从节点。
-
从数据分片上来看，Redis需要应用程序分片，Aerospike支持自动分片，分区被分配给节点且自动平衡各节点数据。
-
从集群方式来看，Redis需要手动或脚本的方式形成集群，Aerospike基于组播自动集群，集群变化时自动重新平衡且重新平衡过程中允许的读/写操作。此外Aerospike自身还提供监控台，用于监视集群的活动。
与memcache相比
- memcache不支持持久化
- memcache只支持string类型数据
- 不支持事务
- memcache集群管理差
-----------如何比较它与其他NoSQL数据库？
一些流行的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部署中，维护窗口的存在是不必要的——备份和升级的操作会在数据库集群还在响应请求服务的同时就完成了。
-----------Aerospike作为解决方案一部分的最佳用例或者最佳应用是什么？
Aerospike是一个可以满足广告优化和广告个性化这些低延迟应用的数据库选择。实时竞价广告系统——运行着大量互联网上常见的竞价广告，很依赖服务器上最近的cookie数据变化，还要加上海量的Hadoop分析而来的更深层用户数据。这种类型的大数据应用要求REST API请求响应在毫秒级，而且要把最近行为写到上层数据库。Aerospike被平台用作用户信息存储、服务端cookie存储、实时上下文存储、设备ID存储和ID映射，可以预见，这些平台必须在1毫秒之内存储和读写几十亿条数据。此外，Aerospike提供金融交易必需的单行ACID特性。
Aerospike还被商家用于在用户浏览商品时生成动态内容——报价和交易信息，并给出相关产品的最佳推荐。以Snapdeal公司举例来说，过去一直使用运行于RAM的MongoDB作为缓存，后来发现性能欠佳。现在他们使用Aerospike，满足了开发人员单页面更多的数据库调用，由此实现了视觉更丰富、利益更大化的网络体验。
我们发现缓存正在变成历史。很多社交媒体公司——从Pinterest到Twitter，都在使用持久化的内存键值存储作为数据基础架构的核心——无缓存化。
如今每家平台都需要全天候的服务才能保证优质的用户体验、达成服务水平协议，还要通过维护和备份做到始终可用。许多Aerospike客户刚开始使用较小的集群。当他们的产品不仅仅是增长，而是爆炸式增长的时候，他们发现很容易就可以通过增加服务器而扩展服务。根本没有必要重启现现有节点、客户端，或是计划停机时间等等。
-----------Aerospike架构里是否有持久化的后台数据库或者完全的内存数据库？
Aerospike在使用RAM的时候是持久化的，标准配置会写入磁盘。由于不通过磁盘读取数据，因此没什么性能影响。当使用闪存或SSD时，数据会同步写入主备机。在数据块写入到磁盘是时是队列维护的，所以所有副本都是持久化的，而且没有性能影响。
-----------它支持什么类型的监控？
有很多方式可以用来监控Aerospike。Aerospike监控控制台（AMC）提供了一个很全面的仪表盘来监视集群的活动。它通过vagrant预装在Aerospike虚拟机中，并注册了亚马逊AMI（亚马逊系统镜像）。
Aerospike支持Nagios和Graphite插件——这些Python写的插件可以作为其他系统的模板。
-----------使用Aerospike有什么限制？
Aerospike在如下场景可能不是最佳选择：
- 工作负载总是只读的
- 如果工作负载是批量分析，旋转介质（HDDs）会更高效
适用场景
简单的说：
1、替换memcache做缓存
这是由于它有强大的集群管理功能，对非常重要不能宕机的缓存服务可以采用它，但代价就是需要更多的硬件服务器。
2、性能要求很高的实时聚合计算
aerospike是一个分布式的基于内存的map-reduce服务，速度快。一般来说，原始数据变化较频繁，而对聚合计算实时要求较高的情景可以用它。
参考：https://blog.csdn.net/u012092620/article/details/79883598
https://blog.csdn.net/songhuiqiao/article/details/50324073?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-3.control
