ElasticStack系列之五 & 当前的缺陷与不足

不仅是ElasticStack有以下这样的问题，包括solr或者说分布式系统在一定程度上都会存在以下的问题

脑裂

　　也叫网络分区，当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能。当脑裂出现是，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理。

 

丢数据

　　1. translog文件每5秒刷新到磁盘，但是就这5s内服务器挂掉了，就会导致这个translog丢失即这5s的数据就会丢失了（因为当服务器再启动的时候需要通过translog进行同步恢复）

　　2. 每一次数据写入的时候首先通过primary节点进行写入，再通过primary主节点同步到对应的replica节点上，当网络不好的情况下，有一批数据已经写入到primary节点上了，但是假如在1s内还是没有同步到相应的从节点，此时primary节点挂掉了，根据es规则会从replica选出一个主，此时没有同步的数据就会丢掉了。

 

数据不一致

　　常见的情况就是你发送同样的请求的时候，第一次和第二次返回的数据不一样，即有一些数据一会儿有一会儿又没有，这就是数据不一致的问题，这个问题主要就是网络延迟导致的。即主节点已经写入这批数据，但是从节点还没有同步过去，而查询请求为了提高性能，有时候是主节点返回有时候是从节点返回，故会导致数据不一致的情况，这种情况还是很普遍存在的，尤其针对网络经常不稳定的环境中。

　　ES为了避免这个问题，在请求的时候可以追加：_primary_frist

 

随机IO

　　普通的例如hdfs、mysql等都是按照顺序扫描访问的，对于一般机械磁盘来说，这个性能还是比较快的，但是对于搜索引擎来说，它是通过倒排索引表来读取数据的，即它是随机IO读取的，这样对于一般的机械磁盘来说性能就比较差了，所以为什么要换成SSD硬盘了（它的随机IO比普通的硬盘高100倍左右），这个针对这种场景来说读取性能有明显的提高。所以，对于那种查询要求比较高的话，搜索引擎推荐使用SSD硬盘。

 

非SQL

　　ES使用query DSL语句进行拼写查询语句，普通的还可以，当设计到复杂聚合条件的时候需要语句嵌套，非常麻烦，学习成本也很大，书写也比较复杂。

 

不适用场景

　　1. OLTP

　　当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果.

　　2. 要求数据强一致性

　　3. 不能容忍丢数据

　　例如银行、支付宝等业务

　　4. “真”实时检索

　　最快也就1s，无法达到真正的实时检索。

 

这里额外补充常见的问题：

　　depth-first VS breadth-first (深度优先 VS 广度优先)

　　depth-first

• default
• few buckets and large documents（每一个组内数据量比较大且只有很少几个种类）

　　breadth-first

• few documents and large buckets（每一个组内数据量比较小且有成千上万了分类）