diff --git a/SUMMARY.md b/SUMMARY.md
index f87bae6..fbe9ca5 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -51,7 +51,7 @@
    * [5.11. Load-balance负载均衡](ch5-web/ch5-11-load-balance.md)
 * [第六章 分布式系统](ch6-cloud/readme.md)
    * [6.1. 云上地鼠(TODO)](ch6-cloud/ch6-01-cloud.md)
-   * [6.2. 分布式搜索引擎(DOING)](ch6-cloud/ch6-02-dist-search-engine.md)
+   * [6.2. 分布式搜索引擎](ch6-cloud/ch6-02-dist-search-engine.md)
    * [6.2. Raft协议(TODO)](ch6-cloud/ch6-02-raft.md)
    * [6.3. 分布式哈希(TODO)](ch6-cloud/ch6-03-hash.md)
    * [6.4. 分布式队列(TODO)](ch6-cloud/ch6-04-queue.md)
diff --git a/ch6-cloud/ch6-02-dist-search-engine.md b/ch6-cloud/ch6-02-dist-search-engine.md
index b212c0a..c37fcf6 100644
--- a/ch6-cloud/ch6-02-dist-search-engine.md
+++ b/ch6-cloud/ch6-02-dist-search-engine.md
@@ -1,4 +1,4 @@
-# 6.x. 分布式搜索引擎
+# 6.2. 分布式搜索引擎
 
 在 web 一章中，我们提到 MySQL 很脆弱。数据库系统本身要保证实时和强一致性，所以其功能设计上都是为了满足这种一致性需求。比如 write ahead log 的设计，基于 B+ 树实现的索引和数据组织，以及基于 MVCC 实现的事务等等。
 
@@ -61,7 +61,7 @@ elasticsearch 是开源分布式搜索引擎的霸主，其依赖于 Lucene 实
 
 即将所有 Ti 和 T(i+1) 组成一个词(在 es 中叫 term)，然后再编排其倒排列表，这样我们的倒排列表大概就是这样的：
 
-TODO omnigraffle 的图
+![terms](../images/ch6-terms.png)
 
 当用户搜索 '天气很好' 时，其实就是求：天气、气很、很好三组倒排列表的交集，但这里的相等判断逻辑有些特殊，用伪代码表示一下：
 
@@ -83,7 +83,7 @@ func equal() {
 }
 ```
 
-时间复杂度分析 TODO
+多个有序列表求交集的时间复杂度是：O(N * M)， N 为给定列表当中元素数最小的集合， M 为给定列表的个数。
 
 在整个算法中起决定作用的一是最短的倒排列表的长度，其次是词数总和，一般词数不会很大(想像一下，你会在搜索引擎里输入几百字来搜索么？)，所以起决定性作用的，一般是所有倒排列表中，最短的那一个的长度。
 
@@ -272,7 +272,8 @@ SQL 的 where 部分就是 boolean expression。我们之前提到过，这种 b
 
 当然可以，我们把 SQL 的 where 被 Parse 之后的结构和 es 的 DSL 的结构做个对比：
 
-TODO 这里有图
+
+![ast](../images/ch6-ast-dsl.png)
 
 既然结构上完全一致，逻辑上我们就可以相互转换。我们以广度优先对 AST 树进行遍历，然后将二元表达式转换成 json 字符串，再拼装起来就可以了，限于篇幅，本文中就不给出示例了，读者朋友可以查看：
 
diff --git a/images/ch6-ast-dsl.png b/images/ch6-ast-dsl.png
new file mode 100644
index 0000000..cb67106
Binary files /dev/null and b/images/ch6-ast-dsl.png differ
diff --git a/images/ch6-terms.png b/images/ch6-terms.png
new file mode 100644
index 0000000..e63b4de
Binary files /dev/null and b/images/ch6-terms.png differ