B+Trees
B+Trees相比于B-Trees，把非叶子节点中的data部分去掉了，只留下键值和指针，这样做的好处就是每个非叶子节点中就可以存储更多的数据，从而减少树的深度，提高检索效率。数据都放在了叶子节点中。
如果磁盘的数据在往u盘中拷贝的时候，如果拷贝的是源码，比如上千个文件，每秒传输速度只有几KB，本来100多M的大小，却需要10分钟或更久。如果只是一个zip压缩包，就会很快，因为zip包是一个文件，一个文件在磁盘中占用的空间是连续的。多个文件在磁盘中的位置是随机分布的，在拷贝的时候会不断的产生io。如果是连续的数据，可以从开始位置读取到结束为止。连续读比随机读要快的多。
当对大数据文本做检索的时候B+Trees的性能会直线下降。
你检索的这段可能是这种长文本字段，需要对title和content两个字段创建索引。因为B+Trees的要求是单个索引长度尽量小，所以这种场景就没有办法使用B+Trees了，因为当建立索引的字段都是文本字段，可能一个索引就会占用很多个节点，就会导致树的深度无限深，iO次数无限多，性能极差。索引可能会失效。精确度也很差。所以MySQL索引是不能解决大数据检索问题的。
全文检索
索引系统通过扫描文章中的每一个词，对其创建索引，指明在文章中出现的次数和位置，当用户查询时，索引系统就会根据事先创建的索引进行查找，并将查找的结果反馈给用户的检索方式。
假设这是一张10亿数据量的表（实际开发过程中10亿的数据不会用数据表的方式存储，这里只是为了说明原理 ）。
执行这个模糊查询，对product字段进行检索，会造成全表扫描。
这种查询的弊端：索引效率慢，准确度差（上面的查询语句，id=2的那条数据查询不出来）
建立倒排索引数据表
term dictionary：词项字典，这里面存放的是对索引字段product切词、规范化、去重、字典顺序之后的词项。
Posting List：存放的是当前词项所在的数据的id集合，id是由小到大有序的。
查询需求是"小米 NFC 手机"，切词之后得到的第一个词项是小米，去词项字典中检索，第一个数据就命中了小米，就得到了小米所在数据的id集合，然后再获取对应的原始数据。这里面有10亿条数据，我只查询了一次就知道了这10亿条数据里面有哪些数据包含了这个词项。命中索引之后，就做一个标记，标记为命中，这就是倒排索引，当前分别对3个词项进行检索的过程，就是全文检索。百度就是全文检索引擎。
倒排索引中的三个数据结构
- • Posting List
倒排表，包含了当前词项的每个数据的id，这是一个int类型的数组，不管id原先是什么类型，这里是int类型。
- • 词项字典
词项字典里面存储的就是创建索引字典的每个词项。
- • term index
这是一个抽象的数据结构，为了加速当前词项检索的，底层是用的FST数据结构。
每一条数据如果拆分成若干个词项，每个词项在索引里面是一个新的数据，假如一条数据拆分成5个索引数据行，10亿条数据，索引的行数甚至有可能大于原数据的行数，假如这个索引检索了10亿次还没有查到，所以本身检索也是一个问题。
假如包含小米这个词项的数据有100万个数据，一个索引项有100万数据，怎么存储Post List这些数据，本身就是一个问题。
Post List是一个int数组，一个int是4个字节Byte，也就是32个bit，如果100万个id就是100万*4B=400万个字节即一个索引所带来的存储成本约等于3.8M。十亿数据就是10亿 * 3.8，所以如何解决这个存储问题呢？
怎么节省存储空间，提高检索性能？
- • 硬件层面
访问量高的用SSD，可读可写；访问量不是那么高的用HDD机械硬盘，只读；访问量再低的，就用COLD冻结索引，快照的形式存放，7.x版本的es就支持可搜索快照。
当然这个不能解决主要问题。
- • 软件层面
软件层面要节省存储空间，需要考虑的是怎么解决压缩数据的问题。
一个int类型占4个字节，也就是32个bit比特，一个bit位就是8个01组成。
一个字节8个bit，如果要存一个0，就是8个0；存一个1就是00000001；存一个2就是00000010（进一位）。
一个bit能存储的数据就是2的8次方-1，这也是为什么int类型的范围是2的31次方-1，为什么是31呢，因为有一个bit是用来存储+-号的。
如果100万个id就是100万*4B=400万个字节即一个索引所带来的存储成本约等于3.8M
FOR压缩Frame Of Reference
