作者介绍

精选留言(12)

• 

  LongXiaJun

  老师好萌

  作者回复: 可能主要还是胖的吧

  2019-07-19

  

   11
• 

  alnssi

  Aerospike和Redis或Pika比起来有什么优势？老师能说说嘛😄

  编辑回复: 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。

  2019-07-15

  

   5
• 

  金生水足

  能和mongoDB比较一下吗？

  作者回复: 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的读写压力评估一下，是否能够适应业务相当一段时间内的增长。

  2019-08-16

  

   2
• 

  蜗牛

  还有其他课程吗，想听

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

  2019-07-30

  

   1
• 

  李饶

  老师您好，请问一下那Hbase保持key的顺序性是仅仅了为了保证索引到key的效率，而逻辑上连续的业务数据(value)本身则在存储上就是需要离散的，是需要分配的不同的机器上的，那这种设计下需要取得连续数据时索引到的key也是离散的，而为了力保效率的scan操作在此时是不是没有使用价值？（scan出来的key是连续的，value却是离散,也就是不能取出连续的数据），scan在什么设计下才能发挥最大价值呢？

  作者回复:
  从理论上分析，“逻辑上连续的业务数据(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。

  2019-11-25

  

  
• 

  春天里的布谷鸟

  讲的不赖

  作者回复: 😁

  2019-11-03

  

  
• 

  一个好名字

  老师好有意思，哈哈哈哈

  2019-09-27

  

  
• 

  王小迈

  老师您好，对于HBase的数据表+索引表的方案，有个疑问，给定startKey和endKey，可以顺序scan出索引表里所有的UUID，但得到UUID不是连续的，这样访问数据表就没法使用scan一次性扫描出所有期望的记录了，访问效率不高，这个问题怎么解决呢？

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

  2019-09-23

  

  
• 

  kyleqian

  这样看，是否可以认为如果业务中需要大量的顺序查询读取一个范围内的数据，而且写入大多也是顺序的，最好还是使用hbase？

  作者回复:
  准确来说，还是要看同一时间并发的请求的分布。
  
  比如一秒钟有一万个请求，集群有10台机器。那么如果这一万个请求能均匀分布到10台机器上，那么是最充分利用集群的方式。如果一秒钟有一万个请求，都打到同一个机器上，另外9个就是闲置着，整个集群的吞吐量就受制于单台机器了。
  
  读取也是一样的道理。

  2019-09-17

  

  
• 

  闫飞

  超级厉害👍

  2019-08-13

  

  
• 

  MIKE

  最终都还是要靠类似hash的方法实现数据存储的均匀分布

  作者回复: 兵来将挡，水来土掩。Hash的水平扩展性比较好。Redis的集群解决方案和Aerospike如出一辙，大家在这方面都是有共识的。
  
  个人见解，除非是TSDB这种对数据顺序访问有刚需的场景，否则尽量不要假设数据是排序的，太累太烦。

  2019-07-31

  

  
• 

  rubylalala

  优秀

  作者回复: (-:

  2019-07-29

  

  