シャドーイング練習: The Secret Sauce Behind NoSQL: LSM Tree - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

77 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

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

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発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

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です。話す速さは1分あたり約147語で安定しており、シャドーイングしやすいペースです。英語の頻出3,000語に含まれる単語は72%だけなので、語彙は難しめです。

この動画の重要語彙

動画の中で特に難しい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
compaction 名詞	/kəmˈpækʃən/	圧密
merge 動詞	/mɝd͡ʒ/	合わせる, 合併する
disk 名詞	/dɪsk/	ディスク, 円盤
immutable 形容詞		不変の
tombstone 名詞	/ˈtuːmstoʊn/	墓碑, 墓石
outdated 形容詞	/aʊtˈdeɪtɪd/	古臭い
optimization 名詞	/ˌɑptəmaɪˈzeɪʃən/	最適化
consume 動詞	/kənˈsum/	消費する, 消耗する
organize 動詞	/ˈɔɹɡənaɪz/	組織する
accumulate 動詞	/əˈkjuːmjʊˌleɪt/	積む
chronological 形容詞	/ˌkɹɑnəˈlɑd͡ʒɪkəl/	経時的
discard 動詞	/dɪsˈkɑɹd/	捨てる, 棄てる
insatiable 形容詞	/ɪnˈseɪʃ(j)əbəl/	飽くことを知らない
nutshell 名詞	/ˈnʌt.ʃɛl/	木の実の殻
override 動詞	/oʊ.vɚˈɹaɪd/	酷使する

動画に出てくる句動詞

単語	発音	意味
look up 動詞	/ˌlʊk ˈʌp/	見上げる
check out 動詞		試験する, 検査する
fill up 動詞		満たす
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/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: chronological /ˌkɹɑnəˈlɑd͡ʒɪkəl/, reclaim /ɹɪˈkleɪm/, algorithm /ˈælɡəɹɪðm̩/
/v/ — /b/ にならないように、上の歯を下唇に当てる: exhaustive /ɪɡˈzɔstɪv/, override /oʊ.vɚˈɹaɪd/, starve /stɑɹv/
/f/ — 「フ」ではなく、上の歯と下唇で出す: buffer /ˈbʌfəɹ/, flush /ˈflʌʃ/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
通常の速度で一文ずつシャドーイングし、話し手のリズムに合うまで繰り返します。
自分の声を録音して元の音声と比べます。compaction, merge, diskなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: 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?

How Git Works: Explained in 4 Minutes

おすすめ動画

Sec Growth DataScience staff meeting Sep 14 2022

Did Anthropic Kill Git?

what is a database index?

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

Database vs Data Warehouse vs Data Lake | Explaining the Differences

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

The Man Who Stole MySpace | Samy

You are wasting memory

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

Database Sharding! Designing Data-Intensive Applications chapter 6

LangChain in 5 Minutes (Explained Clearly)