mirror of
https://github.com/DistSysCorp/ddia.git
synced 2024-12-25 20:30:39 +08:00
Update ch03.md
remove redundant * in ch03
This commit is contained in:
parent
c83bc07ffc
commit
98411d8804
12
ch03.md
12
ch03.md
@ -53,7 +53,7 @@ $ db_get 42
|
|||||||
1. set:在文件末尾追加一个 KV 对。
|
1. set:在文件末尾追加一个 KV 对。
|
||||||
2. get:匹配所有 Key,返回最后(也即最新)一条 KV 对中的 Value。
|
2. get:匹配所有 Key,返回最后(也即最新)一条 KV 对中的 Value。
|
||||||
|
|
||||||
可以看出:写很快,但是读需要全文逐行扫描,会慢很多。典型的以读换写。为了加快读,我们需要构建**索引:**一种允许基于某些字段查找的额外数据结构。
|
可以看出:写很快,但是读需要全文逐行扫描,会慢很多。典型的以读换写。为了加快读,我们需要构建**索引**:一种允许基于某些字段查找的额外数据结构。
|
||||||
|
|
||||||
索引从原数据中构建,只为加快查找。因此索引会耗费一定额外空间,和插入时间(每次插入要更新索引),即,重新以空间和写换读取。
|
索引从原数据中构建,只为加快查找。因此索引会耗费一定额外空间,和插入时间(每次插入要更新索引),即,重新以空间和写换读取。
|
||||||
|
|
||||||
@ -99,7 +99,7 @@ $ db_get 42
|
|||||||
乍一看,基于日志的存储结构存在折不少浪费:需要以追加进行更新和删除。但日志结构有几个原地更新结构无法做的优点:
|
乍一看,基于日志的存储结构存在折不少浪费:需要以追加进行更新和删除。但日志结构有几个原地更新结构无法做的优点:
|
||||||
|
|
||||||
1. **以顺序写代替随机写**。对于磁盘和 SSD,顺序写都要比随机写快几个数量级。
|
1. **以顺序写代替随机写**。对于磁盘和 SSD,顺序写都要比随机写快几个数量级。
|
||||||
2. **简易的并发控制**。由于大部分的文件都是**不可变(immutable)**的,因此更容易做并发读取和紧缩。也不用担心原地更新会造成新老数据交替。
|
2. **简易的并发控制**。由于大部分的文件都是**不可变(immutable)** 的,因此更容易做并发读取和紧缩。也不用担心原地更新会造成新老数据交替。
|
||||||
3. **更少的内部碎片**。每次紧缩会将垃圾完全挤出。但是原地更新就会在 page 中留下一些不可用空间。
|
3. **更少的内部碎片**。每次紧缩会将垃圾完全挤出。但是原地更新就会在 page 中留下一些不可用空间。
|
||||||
|
|
||||||
当然,基于内存的哈希索引也有其局限:
|
当然,基于内存的哈希索引也有其局限:
|
||||||
@ -176,7 +176,7 @@ Elasticsearch 和 Solr 的索引引擎 Lucene,也使用类似 LSM-Tree 存储
|
|||||||
|
|
||||||
如果想让一个引擎工程上可用,还会做大量的性能优化。对于 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 便是支持后者而得名。前者比较简单粗暴,后者性能更好,也因此更为常见。
|
**层级化组织 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)
|
![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
|
|||||||
|
|
||||||
但这种构建出来的视图只能针对固定的查询进行优化,如果有的查询不在此列,则这些优化就不再起作用。
|
但这种构建出来的视图只能针对固定的查询进行优化,如果有的查询不在此列,则这些优化就不再起作用。
|
||||||
|
|
||||||
> 在实际中,需要针对性的识别(或者预估)每个场景查询分布,针对性的构建物化视图。
|
> 在实际中,需要针对性的识别(或者预估)每个场景查询分布,针对性的构建物化视图。
|
||||||
|
Loading…
Reference in New Issue
Block a user