diff --git a/Algorithm.md b/Algorithm.md
index 3f3ae0e..4d16eb9 100644
--- a/Algorithm.md
+++ b/Algorithm.md
@@ -416,7 +416,7 @@ public class Node<E> {
 
 栈是一种**先进后出**（`FILO`，First in last out）或**后进先出**（`LIFO`，Last in first out）的数据结构。
 
-![数据结构-stack](images/Algorithm/数据结构-stack.png)
+![Stack-Push-and-Pop-Operations](images/Algorithm/Stack-Push-and-Pop-Operations.png)
 
 - **单向链表**：可以利用一个单链表来实现栈的数据结构。而且，因为我们都只针对栈顶元素进行操作，所以借用单链表的头就能让所有栈的操作在 O(1) 的时间内完成。
 - **Stack**：是Vector的子类，比Vector多了几个方法
@@ -511,7 +511,7 @@ public class Stack<E> extends Vector<E> {
 - **栈**：采用**后进先出**（`LIFO`）
 - **队列**：采用 **先进先出**（First in First Out，即`FIFO`）
 
-![数据结构-queue](images/Algorithm/数据结构-queue.png)
+![FIFO-Representation-of-Queue](images/Algorithm/FIFO-Representation-of-Queue.png)
 
 **实现方式**
 
@@ -939,7 +939,9 @@ public class TreeNode {
 
 
 
-#### B树(Balance Tree)
+#### B-树(Balance Tree)
+
+![B-tree图解](images/Algorithm/B-tree图解.png)
 
 对于在内存中的查找结构而言，红黑树的效率已经非常好了(实际上很多实际应用还对RBT进行了优化)。但是如果是数据量非常大的查找呢？将这些数据全部放入内存组织成RBT结构显然是不实际的。实际上，像OS中的文件目录存储，数据库中的文件索引结构的存储…. 都不可能在内存中建立查找结构。必须在磁盘中建立好这个结构。
 在磁盘中组织查找结构，从任何一个结点指向其他结点都有可能读取一次磁盘数据，再将数据写入内存进行比较。大家都知道，频繁的磁盘IO操作，效率是很低下的(机械运动比电子运动要慢不知道多少)。显而易见，所有的二叉树的查找结构在磁盘中都是低效的。因此，B树很好的解决了这一个问题。
@@ -963,6 +965,8 @@ public class TreeNode {
 
 
 
+**案例分析**
+
 如下图（B树的内部节点可以存放数据，类似ZK的中间节点一样。B树不是每个节点都有足够多的子节点）：
 
 ![BalanceTree](images/Algorithm/BalanceTree.png)
@@ -973,12 +977,18 @@ public class TreeNode {
 
 #### B+树(B+Tree)
 
+![B+tree图解](images/Algorithm/B+tree图解.png)
+
 **B+树是从B树的变体**。跟B树的不同：
 
 - **内部节点不保存数据，只用于索引**
 - **B+树的每个叶子节点之间存在指针相连，而且是单链表**，叶子节点本身依关键字的大小自小而大顺序链接
 
-如下图（其实B+树上二叉搜索树的扩展，二叉搜索树是每次一分为二，B树是每次一分为多），现代操作系统中，磁盘的存储结构使用的是B+树机制，mysql的innodb引擎的存储方式也是B+树机制：
+
+
+**案例分析**
+
+如下图，其实B+树上二叉搜索树的扩展，二叉搜索树是每次一分为二，B树是每次一分为多，现代操作系统中，磁盘的存储结构使用的是B+树机制，mysql的innodb引擎的存储方式也是B+树机制：
 
 ![B+Tree](images/Algorithm/B+Tree.png)
 
@@ -1006,6 +1016,18 @@ public class TreeNode {
 
 ## 高级数据结构
 
+### 哈希表(Hash Table)
+
+In a hash table, a new index is processed using the keys. And, the element corresponding to that key is stored in the index. This process is called **hashing**.
+
+Let k be a key and h(x) be a hash function. Here, h(k) will give us a new index to store the element linked with k.
+
+![Hash-table-Representation](images/Algorithm/Hash-table-Representation.png)
+
+
+
+
+
 ### 优先队列（Priority Queue）
 
 能保证每次取出的元素都是队列中优先级别最高的。优先级别可以是自定义的，例如，数据的数值越大，优先级越高；或者数据的数值越小，优先级越高。优先级别甚至可以通过各种复杂的计算得到。
@@ -1227,8 +1249,12 @@ public class Solution {
 
 **最大堆**：任何一个父节点的值，都 **大于** 或 **等于** 它左、右子节点的值，**堆顶** 是整个堆中的 **最大** 元素。
 
+![Max-heap](images/Algorithm/Max-heap.png)
+
 **最小堆**：任何一个父节点的值，都 **小于** 或 **等于** 它左、右孩子节点的值，**堆顶** 是整个堆中的 **最小** 元素。
 
+![Min-heap](images/Algorithm/Min-heap.png)
+
 
 
 # Algorithm
diff --git a/Database.md b/Database.md
index d806c57..ad07c34 100644
--- a/Database.md
+++ b/Database.md
@@ -2078,7 +2078,7 @@ redo log 实际的触发 fsync 操作写盘包含以下几个场景：
 
 **背景**：二叉查找树查询的时间复杂度是O(logN)，查找速度最快和比较次数较少。但用于数据库索引，当数据量过大，不可能将所有索引加载进内存，使用二叉树会导致磁盘I/O过于频繁，最坏的情况下磁盘I/O的次数由树的高度来决定。
 
-B-Tree(平衡多路查找树)对二叉树进行了横向扩展，能很好解决红黑树中遗留的高度问题，使树结构更加**矮胖**，使得一次I/O能加载更多关键字，对比在内存中完成，减少了磁盘I/O次数，更适用于大型数据库，但是为了保持自平衡，插入或者删除元素都会导致节点发生裂变反应，有时候会非常麻烦。
+**B-Tree(平衡多路查找树)**对二叉树进行了横向扩展，能很好**解决红黑树中遗留的高度问题**，使树结构更加**矮胖**，使得一次I/O能加载更多关键字，对比在内存中完成，减少了磁盘I/O次数，更适用于大型数据库，但是为了保持自平衡，插入或者删除元素都会导致节点发生裂变反应，有时候会非常麻烦。
 
 ![索引-B树结构](images/Database/索引-B树结构.png)
 
diff --git a/images/Algorithm/B+tree图解.png b/images/Algorithm/B+tree图解.png
new file mode 100644
index 0000000..7d7cc4e
Binary files /dev/null and b/images/Algorithm/B+tree图解.png differ
diff --git a/images/Algorithm/B-tree图解.png b/images/Algorithm/B-tree图解.png
new file mode 100644
index 0000000..4df54d4
Binary files /dev/null and b/images/Algorithm/B-tree图解.png differ
diff --git a/images/Algorithm/FIFO-Representation-of-Queue.png b/images/Algorithm/FIFO-Representation-of-Queue.png
new file mode 100644
index 0000000..1283e9b
Binary files /dev/null and b/images/Algorithm/FIFO-Representation-of-Queue.png differ
diff --git a/images/Algorithm/Hash-table-Representation.png b/images/Algorithm/Hash-table-Representation.png
new file mode 100644
index 0000000..c2f877a
Binary files /dev/null and b/images/Algorithm/Hash-table-Representation.png differ
diff --git a/images/Algorithm/Max-heap.png b/images/Algorithm/Max-heap.png
new file mode 100644
index 0000000..5792a82
Binary files /dev/null and b/images/Algorithm/Max-heap.png differ
diff --git a/images/Algorithm/Min-heap.png b/images/Algorithm/Min-heap.png
new file mode 100644
index 0000000..e1865a0
Binary files /dev/null and b/images/Algorithm/Min-heap.png differ
diff --git a/images/Algorithm/Stack-Push-and-Pop-Operations.png b/images/Algorithm/Stack-Push-and-Pop-Operations.png
new file mode 100644
index 0000000..cf8f0e4
Binary files /dev/null and b/images/Algorithm/Stack-Push-and-Pop-Operations.png differ