[Feature] add for new

Author: bbhou

src/posts/leetcode/datastruct/2018-06-19-data-struct-dynamic-array.md

@@ -0,0 +1,25 @@
+---
+
+title:  Data Struct-01-Dynamic Array
+date: 2018-06-19
+categories: [Data Struct]
+tags: [data struct]
+published: true
+---
+
+# 动态数组
+
+> [Dynamic_array](https://en.wikipedia.org/wiki/Dynamic_array)
+
+> [Linked List](https://en.wikipedia.org/wiki/Linked_list)
+
+> [Doubly linked list](https://en.wikipedia.org/wiki/Doubly_linked_list)
+
+
+
+
+
+
+
+
+

src/posts/leetcode/datastruct/2018-09-10-index-lsm.md

@@ -0,0 +1,66 @@
+---
+
+title:  LSM 索引
+date: 2018-09-07
+categories: [Data-Struct]
+tags: [index, data-struct, sh]
+published: true
+---
+
+# LSM 树（Log-Structured Merge Tree）
+
+LSM树而且通过批量存储技术规避磁盘随机写入问题。 
+
+LSM树的设计思想非常朴素, 它的原理是把一颗大树拆分成N棵小树，它首先写入到内存中（内存没有寻道速度的问题，随机写的性能得到大幅提升），在内存中构建一颗有序小树，随着小树越来越大，内存的小树会flush到磁盘上。磁盘中的树定期可以做merge操作，合并成一棵大树，以优化读性能。
+
+# 常见索引对比
+
+一般来说，索引本身很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。
+
+这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以决定索引性能的一个最重要指标就是在查找过程中磁盘I/O操作次数的渐进复杂度，换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。
+
+一般来讲，索引有如下几种数据结构：
+
+## B+ Tree
+
+1、B+树索引：mysql的默认索引类型，B+树的内结点只存储了key没有存储data，节点的出度大，树的高度小，查找的磁盘寻址次数就少，因此拥有不错的性能
+
+## Hash
+
+2、hash索引：hash表的查找复杂度只有O(1)，索引的检索可以一次定位，不像B+Tree 索引需要从根节点到枝节点，但不支持范围查找，另外在有大量重复键值或者数据量非常大的情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。
+
+## FULLTEXT
+
+3、FULLTEXT索引：全文索引，lucene、elasticsearch的默认索引类型，也叫反向索引、倒排索引，即根据关键字来找到文档
+
+## 空间索引
+
+4、空间索引：mongodb和MySQL 5.7之后的版本都支持空间索引，用于对GIS数据类型的索引，比如根据自己所在位置查询来查询附近50米的POI（point of interest）
+
+## 位图索引
+
+5、位图索引：位图索引是一种特殊的索引，适用范围比较小，只适用于字段值固定并且值的种类很少的情况，比如性别，只能有男和女，或者级别，状态等
+
+ps: 这种常规的索引效果不好，直接使用位图索引看起来不错。
+
+## LSM
+
+6、LSM：Log Structured-Merge Tree,当前许多产品都在使用，比如HBase, Cassandra, LevelDB, SQLite。
+
+LSM通过消去随机的本地更新操作，把磁盘随机写操作变为顺序写操作，从而得到更好的写操作吞吐量。
+
+LSM树的设计思想非常朴素，将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘。
+
+文件是不可修改的，他们永远不会被更新，新的更新操作只会写到新的文件中。读操作会依次从最新的文件查找，通过周期性的合并这些文件来减少文件个数。所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。
+
+综上，LSM索引相比哈希索引能够大幅提高写性能，数据量非常大的情况下因为哈希碰撞哈希索引的效率低。
+
+# 拓展阅读
+
+[B+ Tree]()
+
+# 参考资料
+
+https://blog.csdn.net/qq_26222859/article/details/79645243
+
+

src/posts/leetcode/datastruct/2018-09-10-index-slimtrie.md

@@ -0,0 +1,138 @@
+---
+
+title:  Slim 战胜Btree索引 
+date: 2018-09-07
+categories: [Data-Struct]
+tags: [index, data-struct, sh]
+published: true
+---
+
+# Slim
+
+[Slim](https://github.com/openacid/slim) Slim is collection of surprisingly space efficient data types, with corresponding serialisation APIs to persisting them on-disk or for transport.
+
+# 索引的一点背景知识
+
+索引可以被认为是业务数据（用户文件）之外的一些"额外"的数据, 在这些额外的数据帮助下, 可以在大量的数据中快速找到自己想要的内容. 就像一本数学课本的2个"索引": 一个是目录, 一个是关键词索引.
+
+## 索引的要求
+
+现实系统中，存储系统中的索引需要做到：
+
+足够小 : 一般实现为将索引信息全部存储在内存中可以达到比较好的性能。访问索引的过程中不能访问磁盘, 否则延迟变得不可控(这也是为什么leveldb或其他db在我们的设计中没有作为索引的实现来考虑).
+
+足够准确 : 对较小的文件, 访问一个文件开销为1次磁盘IO操作。
+
+## hash vs tree
+
+分析下已有的2种索引类型, hash-map类型的和tree类型的,Hash map类索引利用hash函数的计算来定位一个文件：
+
+优势 ：快速，一次检索定位数据。非常适合用来做 单条 数据的定位。
+
+劣势 ：无序。不支持范围查询。必须是等值匹配的，不支持“>”、“<”的操作。
+
+内存开销: O(k * n)。
+
+查询效率: O(k)。
+
+## Tree 
+
+而基于Tree 的索引中代表性的有: B+tree, RBTree, SkipList, LSM Tree, 排序数组 :
+
+优势 : 它对保存的key是排序的；
+
+劣势 : 跟Hash map一样, 用Tree做索引的时候, map.set(key = key, value = (offset, size)) 内存中必须保存完整的key, 内存开销也很大: O(k * n)；
+
+内存开销: O(k * n)；
+
+查询效率: O(k * log(n))；
+
+以上是两种经典的索引都存在一个无法避免的问题： key的数量很大时，它们对内存空间的需求会变的非常巨大：O(k * n) 。
+
+如果100亿个key（文件名）长度为1KB的文件。那么仅这些key的索引就是 1KB * 100亿 = 10,000GB。导致以上的经典数据结构无法将索引缓存在内存中。而索引又必须避免访问磁盘IO，基于这些原因我们实现了一套专为存储系统设计的SlimTrie索引.
+
+# 索引数据大小的理论极限
+
+如果要索引n个key, 那每条索引至少需要 log 2 (n) 个bit的信息, 才能区分出n个不同的key. 因此理论上所需的内存空间最低是log 2 (n) * n * n, 这个就是我们空间优化的目标. 
+
+在这里,空间开销仅仅依赖于key的数量，而不会受key的长度的影响!
+
+我们在实现时将所有要索引的key拆分成多组，来限制了单个索引数据结构中 n的大小, 这样有2个好处:
+
+n 和  log 2 (n)  都比较确定, 容易进行优化；
+
+占用空间更小, 因为: a * log(a) + b * log(b) <(a+b) * log(a+b)；
+
+# SlimTrie索引结构的设计
+
+我们最终达到每个文件的索引平均内存开销与key的长度无关， 每条索引一共10 byte, 其中:
+
+6 byte是key的信息;
+
+4 byte是value: (offset, size); // value的这个设定是参考通常的存储实现举的一个例子，不一定是真实生产环境的配置。
+
+# 实现思路：从Trie开始
+
+在研究Trie索引的时候, 我们发现它的空间复杂度(的量级)、顺序性、查询效率(的量级)都可以满足预期, 虽然实现的存储空间开销仍然很大，但有很大的优化空间。
+
+Trie 就是一个前缀树, 例如，保存了8个key（"A", "to", "tea", "ted", "ten", "i", "in", and "inn"）的Trie的结构如下：
+
+Trie的特点在于原生的前缀压缩, 而Trie上的节点数最少是O(n), 这在量级上跟我们的预期一致。
+
+但Trie仍然需要每个节点都要保存若干个指针(指针在目前普遍使用的64位系统上单独要占8字节)。
+
+# limTrie的设计目标
+  
+## 功能要求：
+
+  SlimTrie能正确的定位存在的key，但不需要保证定位不存在的key。
+  
+  SlimTrie支持范围定位key。
+  
+  SlimTrie的内存开销只与key的个数n相关，不依赖于key的长度k 。
+  
+  SlimTrie查询速度要快。
+
+## 限制：
+  
+  SlimTrie只索引静态数据。 数据生成之后在使用阶段不修改, 依赖于这个假设我们可以对索引进行更多的优化。
+  
+  SlimTrie支持最大16KB的key 。
+  
+  SlimTrie在内存中不保存完整的key的信息。
+  
+最终性能目标对比其他几种常见的数据结构应是：
+
+## SlimTrie的术语定义
+   
+   key：某个用户的文件名，一般是一个字符串。
+   
+   value: 要索引的用户数据, 这里value是一组(offset, size)。
+   
+   n: key的总数: <=  2 15 。
+   
+   k: key的平均长度 < 2 16  。
+   
+   Leaf 节点: SlimTrie中的叶子节点, 每个Leaf对应一个存在的key。
+   
+   LeafParent 节点：带有1个Leaf节点的节点。 SlimTrie中最终Leaf节点会删掉，只留下LeafParent节点。
+   
+   Inner 节点: SlimTrie中的Leaf和LeafParent节点之外的节点。
+  
+
+# 总结
+
+SlimTrie 为未来而生。当下信息爆炸增长，陈旧的索引模式已无法适应海量数据新环境，存储系统海量数据的元信息管理面临巨大挑战，而SlimTrie 提供了一个全新的解决方法，为海量存储系统带来一丝曙光，为云存储拥抱海量数据时代注入了强大动力，让我们看到了未来的无限可能。
+
+作为索引，SlimTrie 的优势巨大，可以在10GB内存中建立1PB数据量的索引，空间节约惊人，令以往的索引结构望尘莫及；时间消耗上，SlimTrie 的查找性能与 sorted Array 接近，超过经典的B-Tree。
+
+抛下索引这个身份，SlimTrie 在各项性能方面表现依旧不俗，作为一个通用 Key-Value 的数据结构，内存额外开销仍远远小于经典的 map 和 Btree 。
+
+SlimTrie 不仅为我们解决了眼前的困境，也让我们看到了未来的可能。它的成功不会停下我们开拓的脚步，这只是个开始，还远没有结束。
+
+# 参考资料
+
+[SlimTrie：战胜Btree单机百亿文件的极致索引-实现篇](https://mp.weixin.qq.com/s/QSnKJCtbZCbW0ymsvY8IFQ)
+
+[SlimTrie: 单机百亿文件的极致索引-设计篇](https://openacid.github.io/tech/algorithm/slimtrie-design)
+

src/posts/leetcode/datastruct/2018-09-12-b-tree.md

@@ -0,0 +1,59 @@
+---
+
+title: 数据结构之 B Tree
+date: 2018-09-12
+categories: [Data-Struct]
+tags: [data-struct, java, sh]
+published: true
+---
+
+# B+树
+
+B+ 树是一种树数据结构，通常用于数据库和操作系统的文件系统中。
+
+B+ 树的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。
+
+B+ 树元素自底向上插入，这与二叉树恰好相反。
+
+B+ 树在节点访问时间远远超过节点内部访问时间的时候，比可作为替代的实现有着实在的优势。这通常在多数节点在次级存储比如硬盘中的时候出现。通过最大化在每个内部节点内的子节点的数目减少树的高度，平衡操作不经常发生，而且效率增加了。这种价值得以确立通常需要每个节点在次级存储中占据完整的磁盘块或近似的大小。
+
+B+ 背后的想法是内部节点可以有在预定范围内的可变数目的子节点。因此，B+ 树不需要象其他自平衡二叉查找树那样经常的重新平衡。对于特定的实现在子节点数目上的低和高边界是固定的。例如，在 2-3 B 树（常简称为2-3 树）中，每个内部节点只可能有 2 或 3 个子节点。如果节点有无效数目的子节点则被当作处于违规状态。
+
+B+ 树的创造者 Rudolf Bayer 没有解释B代表什么。
+
+最常见的观点是B代表平衡(balanced)，因为所有的叶子节点在树中都在相同的级别上。B也可能代表Bayer，或者是波音（Boeing），因为他曾经工作于波音科学研究实验室。
+
+# B+ 树的优点
+
+根据B+树的结构，我们可以发现B+树相比于B树，在文件系统，数据库系统当中，更有优势，原因如下：
+
+## B+树的磁盘读写代价更低
+
+B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说I/O读写次数也就降低了。
+
+
+## B+树的查询效率更加稳定
+
+由于内部结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
+
+
+## B+树更有利于对数据库的扫描
+
+B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题，而B+树只需要遍历叶子节点就可以解决对全部关键字信息的扫描，所以对于数据库中频繁使用的range query，B+树有着更高的性能。
+
+---------------------
+
+本文来自 guoziqing506 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/guoziqing506/article/details/64122287?utm_source=copy 
+
+# 参考资料
+
+[B+树](https://zh.wikipedia.org/wiki/B%2B%E6%A0%91)
+
+[从B树、B+树、B*树谈到R 树](https://blog.csdn.net/v_JULY_v/article/details/6530142)
+
+[平衡二叉树、B树、B+树、B*树 理解其中一种你就都明白了](https://zhuanlan.zhihu.com/p/27700617)
+
+[B树和B+树的插入、删除图文详解](https://www.cnblogs.com/nullzx/p/8729425.html)
+
+
+