mirror of
https://github.com/Vonng/ddia.git
synced 2026-06-21 00:47:05 +08:00
docs: 修正ch4中的术语和表达错误
将"级别"改为"层级"以保持术语一致性 修正"有序"的表述使语义更准确 调整"提供了"的句式使表达更自然
This commit is contained in:
parent
9dc6c1086a
commit
c43ffe14b0
1 changed files with 3 additions and 3 deletions
|
|
@ -112,7 +112,7 @@ $ cat database
|
|||
|
||||
#### 构建和合并 SSTable {#constructing-and-merging-sstables}
|
||||
|
||||
SSTable 文件格式在读取方面比仅追加日志更好,但它使写入更加困难。我们不能简单地追加到末尾,因为那样文件就不再排序了(除非键恰好按升序写入)。如果我们每次在中间某处插入键时都必须重写整个 SSTable,写入将变得太昂贵。
|
||||
SSTable 文件格式在读取方面比仅追加日志更好,但它使写入更加困难。我们不能简单地追加到末尾,因为那样文件就不再有序了(除非键恰好按升序写入)。如果我们每次在中间某处插入键时都必须重写整个 SSTable,写入将变得太昂贵。
|
||||
|
||||
我们可以用 *日志结构* 方法解决这个问题,这是仅追加日志和排序文件之间的混合:
|
||||
|
||||
|
|
@ -237,7 +237,7 @@ B 树的基本底层写操作是用新数据覆盖磁盘上的页。假设覆盖
|
|||
|
||||
#### 读取性能 {#read-performance}
|
||||
|
||||
在 B 树中,查找键涉及在 B 树的每个级别读取一个页。由于级别数通常很小,这意味着从 B 树读取通常很快并且具有可预测的性能。在 LSM 存储引擎中,读取通常必须检查处于不同压实阶段的几个不同 SSTable,但布隆过滤器有助于减少所需的实际磁盘 I/O 操作数。两种方法都可以表现良好,哪个更快取决于存储引擎的细节和工作负载。
|
||||
在 B 树中,查找键涉及在 B 树的每个层级读取一个页。由于层级数通常很小,这意味着从 B 树读取通常很快并且具有可预测的性能。在 LSM 存储引擎中,读取通常必须检查处于不同压实阶段的几个不同 SSTable,但布隆过滤器有助于减少所需的实际磁盘 I/O 操作数。两种方法都可以表现良好,哪个更快取决于存储引擎的细节和工作负载。
|
||||
|
||||
范围查询在 B 树上简单而快速,因为它们可以使用树的排序结构。在 LSM 存储上,范围查询也可以利用 SSTable 排序,但它们需要并行扫描所有段并组合结果。布隆过滤器对范围查询没有帮助(因为你需要计算范围内每个可能键的哈希,这是不切实际的),使得范围查询在 LSM 方法中比点查询更昂贵 [^29]。
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ Redis 和 Couchbase 通过异步写入磁盘提供弱持久性。
|
|||
|
||||
反直觉的是,内存数据库的性能优势不是因为它们不需要从磁盘读取。即使是基于磁盘的存储引擎,如果你有足够的内存,也可能永远不需要从磁盘读取,因为操作系统无论如何都会在内存中缓存最近使用的磁盘块。相反,它们可以更快,因为它们可以避免将内存数据结构编码为可以写入磁盘的形式的开销 [^49]。
|
||||
|
||||
除了性能,内存数据库的另一个有趣领域是提供难以使用基于磁盘的索引实现的数据模型。例如,Redis 为各种数据结构(例如优先队列和集合)提供类似数据库的接口。因为它将所有数据保留在内存中,其实现相对简单。
|
||||
除了性能,内存数据库的另一个有趣领域是提供了基于磁盘的索引难以实现的数据模型。例如,Redis 为各种数据结构(例如优先队列和集合)提供类似数据库的接口。因为它将所有数据保留在内存中,其实现相对简单。
|
||||
|
||||
|
||||
## 分析型数据存储 {#sec_storage_analytics}
|
||||
|
|
|
|||
Loading…
Reference in a new issue