跟读练习: The Secret Sauce Behind NoSQL: LSM Tree - 通过视频学习英语口语

选择练习模式

每种模式都会打开全屏练习室。

77 句

如果句子过短或过长，请点击 Edit 进行调整。

NoSQL databases like Cassandra have exploded in popularity in recent years.

近年来，Cassandra 等 NoSQL 数据库的普及度出现了爆发式增长。

One driver is the insatiable demand to ingest huge amounts of

data from an ever-growing number of sources like mobile application and IoT devices.

The secret sauce behind many of these NoSQL databases is a data structure called Log Structure Merge Tree.

An LSM tree is optimized for fast writes.

To understand how an LSM tree works, let's first take a look at how data is typically stored in a relational database.

A relational database is commonly backed by a data structure called a B-tree.

A B-tree is optimized for reads.

Updating the B-tree is relatively expensive as it involves random I.O and might include updating multiple pages on disk.

This limits how fast a B tree can ingest data.

An LSM tree works differently.

Writes are bashed in memory as they arrive in a structure called a mem table.

A mem table is ordered by object key and is usually implemented as a balanced binary tree.

As a mem table reaches a certain size, it is flushed to disk as an immutable sorted string table.

An ss table stores the key value pairs in a sorted sequence.

These writes are all sequential I.O.

They are fast on any storage media.

The new ss table becomes the most recent segment of the LSM tree.

As more data comes in, more and more of these immutable SS tables are created and added to the LSM tree,

with each one representing a small chronological subset of the incoming changes.

Since SS tables are immutable, an update to an existing object key does not override an existing table.

Instead, a new entry is added to the most recent SS table, which supersedes any entries in the old SS tables for the object key.

Deleting an object requires special handling too, since we cannot mark anything in the SS table as deleted.

To perform a delete, it adds a marker called a tombstone to the most recent SS table for the object key.

When we encounter the tombstone on read, we know the object has been deleted.

And yes, it is a bit unintuitive that a delete takes up extra space.

To serve a read request, we first try to find the key in the mem table, then in the most recent SS table in the LSM tree,

then the next SS table, and so on.

Since an SS table is sorted, the lookup can be done efficiently.

The accumulation of SS tables presents two issues.

As the number of SSTables grows, it will take an increasingly long time to look up a key.

And as the SSTables accumulate, there are more and more outdated entries as keys are updated and tombstones are added.

These take up precious disk space.

To fix these issues, there is a periodic merging and compaction process running in the background

to merge SSTables and discard outdated or deleted values.

This reclaims this space and caps the number of SSTables a read has to look through.

Since the tables are sorted, this merging and compaction process is simple and efficient.

The approach is similar to the one used in the merge phase of the merge sort algorithm.

This, in a nutshell, is how an LSM tree provides fast writes.

Let's recap.

An LSM tree buffers incoming writes in memory.

When the buffer fills up, we sort and flush it to disk as an immutable SS table.

The number of SS tables increases as more buffers get flushed to disk.

This creates a problem for reads, as each read has to search through these SS tables to perform a lookup.

To cap the number of SS tables it has to search through for each read, the LSM tree merges the SSTables and compacts them in the background.

Let's look at the compaction process more closely.

When the SSTables are merged, they are organized into levels.

This is where the tree part of the LSM tree comes into the picture.

There are different strategies to determine when and how the SSTables are merged and compacted.

There are two broad strategies, size-tiered compaction and leveled compaction.

Size tier compaction is optimized for write throughput.

Level compaction is more read optimized.

We won't go into too much detail on how these compaction strategies work.

There are a few key points to remember though.

Compaction keeps the number of SS tables manageable.

The SS tables are organized into levels, with each level gets exponentially larger as SS tables from the level above emerged into it.

Compaction consumes a lot of I.O.

A mistuned compaction could starve the system and slow down both read and write.

Finally, let's visit some common optimizations for the LSM trees in production systems.

There are many optimization strategies that try to provide read performance closer to that of the B tree.

What we explain below are just the common ones, and they are by no means exhaustive.

To look up a key, it performs searches on the SS tables at every level.

Even though search is fast on sorted data, going through all the on-disk SS tables consumes a lot of I.O.

Many systems keep a summary table in memory that contains the min-max range of each disk block of every level.

It allows the system to skip searches on those disk blocks where the key does not fall within the range.

This saves a lot of random I.O.

Another issue that could be potentially expensive is to look up a key that does not exist.

This would require looking through all the eligible blocks at all the levels.

Most systems keep a bloom filter at each level.

A bloom filter is a space-efficient data structure that returns a firm no if a key does not exist, or a probably yes if a key might exist.

This allows the system to skip a level entirely if the key does not exist there, which dramatically reduces the number of random I.O required.

In conclusion, NoSQL databases backed by an LSM tree could be tuned to support a very high write rate.

As with any database, proper tuning is the key.

For an LSM tree, compaction tuning is the most critical.

If you would like to learn more about system design, check out our books and weekly newsletter.

Please subscribe if you learn something new.

Thank you so much and we'll see you next time.

下载应用

流利口语所需的一切

AI 发音评分逐句打分

音标练习掌握每个音

词汇学习建立你的词库

词汇游戏边玩边学

扫码

Download on theApp Store Get it onGoogle Play

同频道

FOR YOU

本课的词汇与口语要点

这节 C1 级别的口语课以视频“The Secret Sauce Behind NoSQL: LSM Tree”为素材。视频中反复出现的词有：table, tree, key, Lsm, compaction。这段视频共有 77 个句子、1089 个单词可供跟读。讲话部分时长为 7:26。说话人语速平稳，每分钟约 147 个词，很适合跟读。只有 72% 的单词属于英语最常用的 3,000 词，词汇难度较高。

视频中的重点词汇

视频中最难的 15 个单词，附发音和释义：

单词	发音	释义
compaction 名词	/kəmˈpækʃən/	壓實 /压实
merge 动词	/mɝd͡ʒ/	合并
disk 名词	/dɪsk/	圓盤 /圆盘
optimize 动词	/ˈɑptɪmaɪz/	优化
tombstone 名词	/ˈtuːmstoʊn/	墓碑, 墓石
flush 动词	/ˈflʌʃ/	衝水 /冲水
outdated 形容词	/aʊtˈdeɪtɪd/	过期的, 过时的
optimization 名词	/ˌɑptəmaɪˈzeɪʃən/	優化 /优化
consume 动词	/kənˈsum/	耗費 /耗费, 消耗
organize 动词	/ˈɔɹɡənaɪz/	組織 /组织
compact 形容词	/kəmˈpækt/	緊湊的 /紧凑的
accumulate 动词	/əˈkjuːmjʊˌleɪt/	積累 /积累
chronological 形容词	/ˌkɹɑnəˈlɑd͡ʒɪkəl/	按時間先後 /按时间先后
discard 动词	/dɪsˈkɑɹd/	丟棄 /丢弃, 拋棄 /抛弃
exponentially 副词	/ɛkspə(ʊ)ˈnɛnʃəli/	指数地

视频中出现的短语动词

单词	发音	释义
look up 动词	/ˌlʊk ˈʌp/	仰, 上看
check out 动词		退房
fill up 动词		裝滿 /装满
go through 动词		通過 /通过
slow down 动词		減速 /减速, 放慢

视频中的语法

说话人最常用的结构，并附上视频中的原话：

结构	视频中的用法
被动语态 be + 过去分词 — 强调发生了什么，而不是谁做的	is optimized · is typically stored · is commonly backed
现在完成时 have/has + 过去分词 — 过去发生但与现在仍有关联的事	have exploded · has been deleted

需要注意的发音

“th” 音: throughput /ˈθɹuː.pʊt/, algorithm /ˈælɡəɹɪðm̩/
“sh” 和 “zh” 音: compaction /kəmˈpækʃən/, flush /ˈflʌʃ/, optimization /ˌɑptəmaɪˈzeɪʃən/, exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, insatiable /ɪnˈseɪʃ(j)əbəl/
长单词——注意重音位置: optimization /ˌɑptəmaɪˈzeɪʃən/, accumulate /əˈkjuːmjʊˌleɪt/, chronological /ˌkɹɑnəˈlɑd͡ʒɪkəl/, exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, insatiable /ɪnˈseɪʃ(j)əbəl/

中文母语者容易读错的音：

/v/ — 不要读成 /w/，上齿轻触下唇: exhaustive /ɪɡˈzɔstɪv/, override /oʊ.vɚˈɹaɪd/, starve /stɑɹv/
词尾辅音 — 要读清楚，后面不要加元音: merge /mɝd͡ʒ/, disk /dɪsk/, optimize /ˈɑptɪmaɪz/, flush /ˈflʌʃ/, ingest /ɪnˈd͡ʒɛst/
/r/ 和 /l/ 的区别: chronological /ˌkɹɑnəˈlɑd͡ʒɪkəl/, reclaim /ɹɪˈkleɪm/, algorithm /ˈælɡəɹɪðm̩/

如何用这段视频练习

先完整听一遍视频，不要开口，记下不认识的单词。
用正常速度逐句跟读，每句重复到你的节奏与说话人一致为止。
录下自己的声音并与原声对比，特别注意 compaction, merge, disk 这类单词。

什么是跟读法？

跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。

影子跟读法: 阅读完整分步指南 →

跟读练习: The Secret Sauce Behind NoSQL: LSM Tree - 通过视频学习英语口语

选择练习模式

下载应用

Proxy vs Reverse Proxy (Real-world Examples)

Cache Systems Every Developer Should Know

Top 5 Redis Use Cases

Everything You Need to Know About DNS: Crash Course System Design #4

CAP Theorem Simplified

What Is REST API? Examples And How To Use It: Crash Course System Design #3

8 Most Important System Design Concepts You Should Know

System Design: Why is Kafka fast?

What Are Microservices Really All About? (And When Not To Use It)

System Design Was HARD - Until You Knew the Trade-Offs

How Does a URL Shortener Work?

System Design: Why is Kafka Popular?

What is API Gateway?

10+ Key Memory & Storage Systems: Crash Course System Design #5

Kubernetes Explained in 6 Minutes | k8s Architecture

What Is Redis Really About? Why Is It So Popular?

FANG Interview Question | Process vs Thread

How Git Works: Explained in 4 Minutes

What Is a Data Mesh? Databricks Unity Catalog Explained

Did Anthropic Kill Git?

what is a database index?

How do microSD Cards Store 2 TB in such a TINY space?

SAC | Soft Actor Critic (SAC) architecture | SAC Explained

Redis Crash Course - the What, Why and How to use Redis as your primary database

Sec Growth DataScience staff meeting Sep 14 2022

The Man Who Stole MySpace | Samy

Database Sharding! Designing Data-Intensive Applications chapter 6

You are wasting memory

How an Ex-Googler Accidentally Founded a Database Company