编辑回复: Aerospike 原生支持多核，持久化到磁盘，集群和HA。根据业界经验，一个 DB 从设计之初就支持的核心功能的易用性+稳定性要好过以后增加的核心功能。

Redis也支持了集群和HA，两者的套路如出一辙，可谓英雄所见略同。我本人并没有在生产环境用过 Redis，不确定 Redis 现在的持久化方案和集群方案是不是有坑。Aerospike 的还是没什么大问题的，包括集群扩容等操作也都安排得明明白白。

同时，Aerospike还有针对SSD的核心技术，号称可以充分利用SSD磁盘。SSD确实和普通的机械磁盘不一样。初步的介绍可以移步 https://www.bilibili.com/video/av52944283/。 Aerospike 针对的SSD优化：https://www.aerospike.com/docs/operations/plan/ssd/

Redis 的数据结构比较丰富，这里一个Aerospike支持的数据结构的文档：https://www.aerospike.com/docs/guide/cdt.html

两者都是用C写的，性能都很棒棒。两者的客户端也都很丰富。

就像视频中说的，Aerospike 启动的时候需要将所有的 key 都从磁盘加载到内存，这个是比较耗时间的。但是好处是集群服务的时候更稳定。

Aerospike 也支持UDF，使用的语言是Lua，就是在服务器端进行计算。这个Redis好像没有。

当然，Aerospike是商业版的软件，要想用的爽，还是得花钱。社区免费版有各种限制，包括集群机器数量（三台）等。具体的免费版和收费版的对比（https://www.aerospike.com/products/product-matrix/）。但是即使是收费版，也最多支持128台，和Redis号称的1000台差距很大。这是 Aerospike 官方公布的限制 https://www.aerospike.com/docs/guide/limitations.html。

作者回复: mongoDB和HBase以及Aerospike感觉不是在一个象限中的。mongoDB更像是和MySQL这种传统的DB在一个象限竞争的。

mongoDB有以下特征：
 - 原生支持索引
 - 原生支持JSON数据
 - 支持根据JSON的数据进行查询

所以它和MySQL这种DB的差别就是对数据的schema没有强制的约束，不需要在数据变化的时候修改表结构。这些特性可以灵活的应对业务数据的变化。


mongoDB可以根据JSON数据的值进行查询，所以它是document-based的数据库。

相比之下，HBase和Aerospike则是更存粹的key-value(s)的NoSQL。他俩都是用bin来描述一条记录里的一个值的。可以用key得到这一行所有的bin，也可以指定key和bin name(s)获取一行对应的value(s)。这一点和mongoDB就很不一样了。

如果说的再掺杂一点个人观点。我认为mongoDB和传统的关系型数据库更像的原因是，它们都侵入了一点业务逻辑。无论是mongoDB的client的查询API，还是SQL，其本质都是业务逻辑。我们在用它们提供的接口，来操作数据，执行业务逻辑。

而HBase和Aerospike则更薄，只做到数据这一层。虽然AS也支持complex data type，HBase也支持coprocessor，但是更主流的情况下，它们是获取数据，然后让用户自己写代码处理数据，完成业务逻辑，而非是使用它们客户端提供的API完成业务逻辑。

换个角度来说。HBase和Aerospike速度应该更快。毕竟它们的接口更简单。

尝试总结一下，如果受够了修改table schema，尝试寻找MySQL的替代品，那么mongoDB可以试试看。如果是纯粹的需要一个key-value(s)系统，可以考虑HBase和Aerospike。至于HBase和Aerospike怎么选，看视频吧～

P.S. mongoDB是业内有名的第一眼DB，看着很爽，试着用用也很爽，量一大就凉凉了。个人不是mongoDB的专家，如果考虑mongoDB，建议对mongoDB的读写压力评估一下，是否能够适应业务相当一段时间内的增长。

作者回复: 你想从0开始学Java吗？让你听个够

作者回复:
从理论上分析，“逻辑上连续的业务数据(value)本身则在存储上就是需要离散的”并不一定就会比业务数据都聚集在一台机器上慢，因为一台机器就只有固定的几个磁盘。而如果数据请求分散到很多机器上，很多机器的磁盘一起工作，获取单条value的代价/时间可能更高，但是因为是很多机器上的很多磁盘一起工作，所以从集群的角度看，完成这次数据获取的请求可能需要的时间会更少。

HBase本身是基于HDFS的，每个文件默认是三个copy，所以即使业务数据确实是存储在一个region上，但是实际读取时，HDFS文件是否是在一台机器上，还未可知。当然在一台机器上的概率肯定是比较高的。

说完理论，谈实际。实际使用的时候，还是要根据数据的特性做设计。文中给的设计是key连续，value分散，是基于value远大于key的前提。比如100B的key，32k的数据。这样数据散列开，可以充分利用集群的资源。

当然，除了数据特性，还要看请求的特性。如果请求量特别大，整个集群的压力很大，磁盘IO达到了瓶颈，value散列开反而是没什么好处，反而会增加IO的次数和压力。当然这并不是一个健康的集群状态，需要从operation层面解决。

所以scan在什么情况下才能发挥最大价值，要看实际情况。但是如果需要获取连续的多个值，而又不想独立建索引系统（比如在DB，或者ES里索引key），那么HBase的scan就是值得一试的。最典型的就是TSDB。

作者回复: 😁

作者回复:
这个不是问题是目的。集群的目的就是为了让请求尽量分散到集群里所有的机器上。index小，100条数据的index对一台机器的压力可能就相当于1条数据对一台机器的压力。然后再读100条记录，大概率这100条记录会均匀分散到集群的所有机器上。所以从整个集群的角度看，这样是最大化的利用集群资源，提高集群吞吐量。

作者回复:
准确来说，还是要看同一时间并发的请求的分布。

比如一秒钟有一万个请求，集群有10台机器。那么如果这一万个请求能均匀分布到10台机器上，那么是最充分利用集群的方式。如果一秒钟有一万个请求，都打到同一个机器上，另外9个就是闲置着，整个集群的吞吐量就受制于单台机器了。

读取也是一样的道理。

作者回复: 兵来将挡，水来土掩。Hash的水平扩展性比较好。Redis的集群解决方案和Aerospike如出一辙，大家在这方面都是有共识的。

个人见解，除非是TSDB这种对数据顺序访问有刚需的场景，否则尽量不要假设数据是排序的，太累太烦。

作者回复: (-: