diff --git a/ch03.md b/ch03.md
index c8f27b8..279c280 100644
--- a/ch03.md
+++ b/ch03.md
@@ -53,7 +53,7 @@ $ db_get 42
 1. set：在文件末尾追加一个 KV 对。
 2. get：匹配所有 Key，返回最后（也即最新）一条 KV 对中的 Value。
 
-可以看出：写很快，但是读需要全文逐行扫描，会慢很多。典型的以读换写。为了加快读，我们需要构建**索引：**一种允许基于某些字段查找的额外数据结构。
+可以看出：写很快，但是读需要全文逐行扫描，会慢很多。典型的以读换写。为了加快读，我们需要构建**索引**：一种允许基于某些字段查找的额外数据结构。
 
 索引从原数据中构建，只为加快查找。因此索引会耗费一定额外空间，和插入时间（每次插入要更新索引），即，重新以空间和写换读取。
 
@@ -99,7 +99,7 @@ $ db_get 42
 乍一看，基于日志的存储结构存在折不少浪费：需要以追加进行更新和删除。但日志结构有几个原地更新结构无法做的优点：
 
 1. **以顺序写代替随机写**。对于磁盘和 SSD，顺序写都要比随机写快几个数量级。
-2. **简易的并发控制**。由于大部分的文件都是**不可变（immutable）**的，因此更容易做并发读取和紧缩。也不用担心原地更新会造成新老数据交替。
+2. **简易的并发控制**。由于大部分的文件都是**不可变（immutable）** 的，因此更容易做并发读取和紧缩。也不用担心原地更新会造成新老数据交替。
 3. **更少的内部碎片**。每次紧缩会将垃圾完全挤出。但是原地更新就会在 page 中留下一些不可用空间。
 
 当然，基于内存的哈希索引也有其局限：
@@ -176,7 +176,7 @@ Elasticsearch 和 Solr 的索引引擎 Lucene，也使用类似 LSM-Tree 存储
 
 如果想让一个引擎工程上可用，还会做大量的性能优化。对于 LSM-Tree 来说，包括：
 
-**优化 SSTable 的查找。**常用 [**Bloom Filter**](https://www.qtmuniao.com/2020/11/18/leveldb-data-structures-bloom-filter/)。该数据结构可以使用较少的内存为每个 SSTable 做一些指纹，起到一些初筛的作用。
+**优化 SSTable 的查找**。常用 [**Bloom Filter**](https://www.qtmuniao.com/2020/11/18/leveldb-data-structures-bloom-filter/)。该数据结构可以使用较少的内存为每个 SSTable 做一些指纹，起到一些初筛的作用。
 
 **层级化组织 SSTable**。以控制 Compaction 的顺序和时间。常见的有 size-tiered 和 leveled compaction。LevelDB 便是支持后者而得名。前者比较简单粗暴，后者性能更好，也因此更为常见。
 
@@ -286,7 +286,7 @@ SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
 
 ### 全内存数据结构
 
-随着单位内存成本下降，甚至支持持久化（*non-volatile memory，*NVM，如 Intel 的 [傲腾](https://www.intel.cn/content/www/cn/zh/products/details/memory-storage/optane-dc-persistent-memory.html "傲腾")），全内存数据库也逐渐开始流行。
+随着单位内存成本下降，甚至支持持久化（*non-volatile memory*，NVM，如 Intel 的 [傲腾](https://www.intel.cn/content/www/cn/zh/products/details/memory-storage/optane-dc-persistent-memory.html "傲腾")），全内存数据库也逐渐开始流行。
 
 根据是否需要持久化，内存数据大概可以分为两类：
 
@@ -351,7 +351,7 @@ AP 中的处理模型相对较少，比较常用的有**星状模型**，也称
 
 ![ddia3-9-star-schema.png](img/ch03-fig08.png)
 
-如上图所示，星状模型通常包含一张**事件表（*fact table*）**和多张**维度表（*dimension tables*****）**。事件表以事件流的方式将数据组织起来，然后通过外键指向不同的维度。
+如上图所示，星状模型通常包含一张**事件表（*fact table*）** 和多张**维度表（*dimension tables*****）**。事件表以事件流的方式将数据组织起来，然后通过外键指向不同的维度。
 
 星状模型的一个变种是雪花模型，可以类比雪花（❄️）图案，其特点是在维度表中会进一步进行二次细分，讲一个维度分解为几个子维度。比如品牌和产品类别可能有单独的表格。星状模型更简单，雪花模型更精细，具体应用中会做不同取舍。
 
@@ -497,4 +497,4 @@ WHERE product_sk = 31 AND store_sk = 3
 
 但这种构建出来的视图只能针对固定的查询进行优化，如果有的查询不在此列，则这些优化就不再起作用。
 
-> 在实际中，需要针对性的识别（或者预估）每个场景查询分布，针对性的构建物化视图。
\ No newline at end of file
+> 在实际中，需要针对性的识别（或者预估）每个场景查询分布，针对性的构建物化视图。