fix: fix some problem in ch2 and ch3

ch2.md

@@ -927,7 +927,7 @@ Cypher和SPARQL使用SELECT立即跳转，但是Datalog一次只进行一小步
 
 * 使用基因组数据的研究人员通常需要执行**序列相似性搜索**，这意味着需要一个很长的字符串（代表一个DNA分子），并在一个拥有类似但不完全相同的字符串的大型数据库中寻找匹配。这里所描述的数据库都不能处理这种用法，这就是为什么研究人员编写了像GenBank这样的专门的基因组数据库软件的原因【48】。
 * 粒子物理学家数十年来一直在进行大数据类型的大规模数据分析，像大型强子对撞机（LHC）这样的项目现在可以工作在数百亿兆字节的范围内！在这样的规模下，需要定制解决方案来阻止硬件成本的失控【49】。
-* **全文搜索**可以说是一种经常与数据库一起使用的数据模型。信息检索是一个很大的专业课题，我们不会在本书中详细介绍，但是我们将在第三章和第三章中介绍搜索索引。
+* **全文搜索**可以说是一种经常与数据库一起使用的数据模型。信息检索是一个很大的专业课题，我们不会在本书中详细介绍，但是我们将在第三章和第三部分中介绍搜索索引。
 
 让我们暂时将其放在一边。在[下一章](ch3.md)中，我们将讨论在**实现**本章描述的数据模型时会遇到的一些权衡。
 

ch3.md

@@ -41,7 +41,7 @@ db_get () {
 麻雀虽小，五脏俱全：
 
 ```bash
-$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}' $ 
+$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'
 
 $ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'
 
@@ -118,7 +118,7 @@ $ cat database
 
 ***崩溃恢复***
 
-如果数据库重新启动，则内存散列映射将丢失。原则上，您可以通过从头到尾读取整个段文件并在每次按键时注意每个键的最近值的偏移量来恢复每个段的哈希映射。但是，如果段文件很大，这可能需要很长时间，这将使服务器重新启动痛苦。 Bitcask通过存储加速恢复磁盘上每个段的哈希映射的快照，可以更快地加载到内存中。
+如果数据库重新启动，则内存散列映射将丢失。原则上，您可以通过从头到尾读取整个段文件并在每次按键时注意每个键的最近值的偏移量来恢复每个段的哈希映射。但是，如果段文件很大，这可能需要很长时间，这将使服务器重新启动痛苦。 Bitcask 通过存储每个段的哈希映射的快照在磁盘上来加速恢复，可以使哈希映射更快地加载到内存中。
 
 ***部分写入记录***
 
@@ -193,7 +193,7 @@ $ cat database
 
 #### 用SSTables制作LSM树
 
-这里描述的算法本质上是LevelDB 【6】和RocksDB 【7】中使用的键值存储引擎库，被设计嵌入到其他应用程序中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了类似的存储引擎【8】，这两种引擎都受到了Google的Bigtable文档【9】（引入了SSTable和memtable）的启发。
+这里描述的算法本质上是LevelDB 【6】和RocksDB 【7】中使用的键值存储引擎库，被设计嵌入到其他应用程序中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了类似的存储引擎【8】，这两种引擎都受到了Google的Bigtable文档【9】（引入了术语 SSTable 和 memtable ）的启发。
 
 最初这种索引结构是由Patrick O'Neil等人描述的，且被命名为日志结构合并树（或LSM树）【10】，它是基于更早之前的日志结构文件系统【11】来构建的。基于这种合并和压缩排序文件原理的存储引擎通常被称为LSM存储引擎。