问题的本质还是磁盘随机操作慢，顺序读写快的老问题。
传统数据库的核心通常是页级缓存、B+树、堆或索引组织表，这些机制，对随机IO的抵抗能力，都无一例外的可 悲的差。
数据库如何抵抗随机IO的问题、方法与现实
https://blog.csdn.net/tianlianchao1982/article/details/8939309?locationNum=9&fps=1
1、Hash存储引擎
代表数据库：redis、memcache等
通常也常见于其他存储引擎的查找速度优化上。 Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端。
这里列举缺点：
（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。
（2）Hash 索引无法被用来避免数据的排序操作。
（3）Hash 索引不能利用部分索引键查询。
(4）Hash 索引在任何时候都不能避免表扫描。
Hash碰撞，就是链式扫描：
由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
（5）Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。
2、B树存储引擎
代表数据库：MongoDB、mysql(基本上关系型数据库)等
还有一种算是B树存储引擎：COLA树（CacheObliviousBTree）
代表数据库：tokudb
为了如何让B树更有效的执行，他们提出了一个缓存忘却CacheOblivious算法，该算法在不需要明确知道存储器层次中数据传输规模的情况下，也可以高效的工作。更多请参见：https://en.wikipedia.org/wiki/Cache-oblivious_algorithm。
说个大家熟悉的名称TokuMX : 目前非常流行的NoSQL数据库MongoDB的底层替换成与TokuDB同样的存储引擎[ ToKuMx]，达到了非常好的效 果
3、LSM树（Log-Structured Merge Tree）存储引擎
代表数据库：nessDB、leveldb、hbase等
核心思想的核心就是放弃部分读能力，换取写入的最大化能力。LSM Tree ，这个概念就是结构化合并树的意思，它的核心思路其实非常简单，就是假定内存足够大，因此不需要每次有数据更新就必须将数据写入到磁盘中，而可以先将最新的数据驻留在磁盘中，等到积累到最后多之后，再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的，可以通过合并排序的方式快速合并到一起)。
https://blog.csdn.net/moonpure/article/details/79788897