Update ch03.md

remove redundant * in ch03
This commit is contained in:
muniao 2023-01-08 16:07:00 +08:00 committed by GitHub
parent c83bc07ffc
commit 98411d8804
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

12
ch03.md
View File

@ -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
但这种构建出来的视图只能针对固定的查询进行优化,如果有的查询不在此列,则这些优化就不再起作用。
> 在实际中,需要针对性的识别(或者预估)每个场景查询分布,针对性的构建物化视图。
> 在实际中,需要针对性的识别(或者预估)每个场景查询分布,针对性的构建物化视图。