document/ddia_read
2
0
Fork 0
mirror of https://github.com/DistSysCorp/ddia.git synced 2024-12-25 20:30:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update ch03.md

Browse Source 
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
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ch03.md
View File

@ -53,7 +53,7 @@ $ db_get 42
1. set：在文件末尾追加一个 KV 对。
2. get：匹配所有 Key，返回最后（也即最新）一条 KV 对中的 Value。
可以看出：写很快，但是读需要全文逐行扫描，会慢很多。典型的以读换写。为了加快读，我们需要构建**索引：**一种允许基于某些字段查找的额外数据结构。
可以看出：写很快，但是读需要全文逐行扫描，会慢很多。典型的以读换写。为了加快读，我们需要构建**索引**：一种允许基于某些字段查找的额外数据结构。
索引从原数据中构建，只为加快查找。因此索引会耗费一定额外空间，和插入时间（每次插入要更新索引），即，重新以空间和写换读取。
@ -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 "傲腾")），全内存数据库也逐渐开始流行。
根据是否需要持久化，内存数据大概可以分为两类：