쉐도잉 연습: 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입니다. 화자는 분당 약 147단어의 일정한 속도로 말해서 섀도잉하기에 편한 속도입니다. 영어에서 가장 많이 쓰이는 3,000단어에 속하는 단어가 72%뿐이라 어휘가 어려운 편입니다.

이 영상의 핵심 어휘

영상에서 가장 어려운 단어 15개를 발음, 뜻과 함께 정리했습니다.

단어	발음	뜻
merge 동사	/mɝd͡ʒ/	합하다
disk 명사	/dɪsk/	디스크, 원반
tombstone 명사	/ˈtuːmstoʊn/	묘석
outdated 형용사	/aʊtˈdeɪtɪd/	구식이다, 철 지나다
organize 동사	/ˈɔɹɡənaɪz/	조직하다
accumulate 동사	/əˈkjuːmjʊˌleɪt/	모으다, 축적하다
chronological 형용사	/ˌkɹɑnəˈlɑd͡ʒɪkəl/	연대기의
discard 동사	/dɪsˈkɑɹd/	버리다
throughput 명사	/ˈθɹuː.pʊt/	스루풋
starve 동사	/stɑɹv/	굶어죽다
subset 명사	/ˈsʌbˌsɛt/	부분집합
newsletter 명사	/ˈn(j)uzˌlɛtɚ/	뉴스레터
explode 동사	/ɪkˈsploʊd/	폭발적으로 증가하다, 폭발하다
binary 형용사	/ˈbaɪ.nə.ɹi/	참거짓, 진리
subscribe 동사	/səbˈskɹaɪb/	구독하다

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
수동태 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/

한국어 화자가 어려워하는 소리:

/f/ — ㅍ(/p/)으로 바꾸지 말고 윗니를 아랫입술에 대기: buffer /ˈbʌfəɹ/, flush /ˈflʌʃ/
/v/ — ㅂ(/b/)과 구별하기: exhaustive /ɪɡˈzɔstɪv/, override /oʊ.vɚˈɹaɪd/, starve /stɑɹv/
/z/ — ㅈ이 아니라 성대를 울리는 /s/: optimize /ˈɑptɪmaɪz/, optimization /ˌɑptəmaɪˈzeɪʃən/, organize /ˈɔɹɡənaɪz/, exhaustive /ɪɡˈzɔstɪv/, newsletter /ˈn(j)uzˌlɛtɚ/

이 영상으로 연습하는 방법

먼저 말하지 않고 영상을 끝까지 듣고 모르는 단어를 적어 둡니다.
보통 속도로 한 문장씩 섀도잉하고, 화자의 리듬과 맞을 때까지 반복합니다.
자신의 목소리를 녹음해 원본과 비교하고, merge, disk, tombstone 같은 단어에 특히 주의합니다.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(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?

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