简介
海量数据分析并不一定要用elasticsearch，但搜索一定要用elasticsearch。elasticsearch是基于文档型的数据结构。
百度是全文搜索引擎，搜索的内容不是固定的；京东淘宝是垂直搜索，有明确的搜索目的，站内搜索是垂直领域的一种。
搜索引擎包括NLP(自然语言分析处理)、大数据处理、网页处理、爬虫、算法、elasticsearch。
elasticsearch除了搜索之外，还可以做大数据分析，ELK就是使用的elasticsearch大数据分析功能。
搜索框架技术选型
- • redis
redis不适合做大数据搜索和存储，它是一个内存型数据库。如果开启持久化，性能会下降。
- • mongodb
mongodb适合做大数据存储，可以做搜索引擎，但更适合对数据的管理，不适合做检索。
- • es
es更倾向于搜索。数据写入的实时性并不高。es不支持事务。es和mongodb都是基于文档型数据库。
- • solr
搜索这块，可以和es相比较的是solr，两者都是基于lucene。lucene是单点的。solr是技术比较老的框架。es稳定性不会随着数据量的增大而发生明显的改变，es天生就支持分布式的，solr不一样，并不是天生就支持分布式，需要自己去管理分布式集群，还要使用第三方中间件zookeeper管理集群状态。es也支持数据迁移，比如从solr迁移到es。
为什么mysql索引结构不适合做搜素引擎
在mysql中这样的一个节点大小是固定的，节点就是寻址最小的数据单元即data page，默认大小是16KB。
假设这是一个磁盘，磁盘由很多节点数据单元组成，每个节点包含键值、指针和数据。
磁盘和内存之间数据交互的时候，一次性最小取这么一个单位的数据。
在图[1]中查找id=7的数据，需要做几次io操作？
首先把跟节点16KB放入内存中（在创建索引树的时候就会把根节点放入内存，这里先忽略这点），经过一次io，cpu判断id=7的数据不在这个节点里，根据当前004这个节点去磁盘中寻址，找到006～008这个节点，然后从磁盘加载到内存，这是第二次io操作，cpu判断得知数据在007节点，然后再寻址找到007节点，加载数据到内存，然后读取里面的数据，这是第三次io操作，那么该过程内存和磁盘之间一共产生了3次交互，计算结果就是16KB*3=48KB。
任何小的数据一旦用户量过大的时候都是不可以忽略的，所以要尽量减少磁盘io的次数。
树的深度不断增大的时候就意味着磁盘io的次数不断的增大。
B-Trees
非叶子节点里面包含键值、指针和数据。单个节点的大小都是固定的，也意味着单条数据体积越大，单个节点所能装下的数据量越少，需要的节点数量越多，Max Degree是确定的即每一个节点的子节点数量是固定的，所以树的深度就越深，检索路径变长，检索效率越低。
类比电梯，人越重，电梯里面装的人数量越少，那么需要的电梯数量越多。
所以尽量避免单个节点的数据过大。节点中包含键值、指针和数据。指针即索引，单个索引长度越小越好。
键值就是第一列的id数据，除了第一列其他的都是数据即data。
如果节点中data不存在的话即节点只包含键值和指针，那么节点中存储的数据个数就会变多，所需要的节点数量就会越少，树的深度也会越小。
一个节点空间是16KB，一条数据4KB，可以存储4条数据，1600万的数据需要400万个节点，树的深度越深；若一条数据1KB，那么一个节点可以存储16条数据，1600万的数据需要100万个节点，树的深度变浅。
