Luyện nói tiếng Anh bằng Shadowing qua video: The Secret Sauce Behind NoSQL: LSM Tree

Chọn chế độ luyện tập

Mỗi chế độ mở một phòng luyện tập toàn màn hình.

77 câu

Nếu các câu quá ngắn hoặc quá dài, hãy bấm Edit để chỉnh sửa.

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

Các cơ sở dữ liệu NoSQL như Cassandra đã bùng nổ về mức độ phổ biến trong những năm gần đây.

One driver is the insatiable demand to ingest huge amounts of

Một trong những yếu tố thúc đẩy là nhu cầu không bao giờ đủ để tiếp nhận một lượng lớn

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

dữ liệu từ một số lượng nguồn ngày càng tăng, chẳng hạn như ứng dụng di động và các thiết bị IoT.

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

Yếu tố cốt lõi tạo nên sức mạnh của nhiều cơ sở dữ liệu NoSQL này là một cấu trúc dữ liệu có tên gọi Log-Structured Merge Tree.

An LSM tree is optimized for fast writes.

Cây LSM được tối ưu hóa cho các thao tác ghi nhanh.

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

Để hiểu cách hoạt động của cây LSM, trước hết chúng ta hãy xem xét cách dữ liệu thường được lưu trữ trong cơ sở dữ liệu quan hệ.

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

Cơ sở dữ liệu quan hệ thường được hỗ trợ bởi một cấu trúc dữ liệu gọi là cây B.

A B-tree is optimized for reads.

Cây B được tối ưu hóa cho các thao tác đọc.

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

Việc cập nhật cây B tương đối tốn kém vì nó liên quan đến hoạt động nhập/xuất ngẫu nhiên và có thể bao gồm việc cập nhật nhiều trang trên đĩa.

This limits how fast a B tree can ingest data.

Điều này giới hạn tốc độ mà cây B có thể tiếp nhận dữ liệu.

An LSM tree works differently.

Cây LSM hoạt động theo cách khác.

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

Các thao tác ghi được xử lý trực tiếp trong bộ nhớ ngay khi chúng đến một cấu trúc gọi là memtable.

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

Bảng nhớ (mem table) được sắp xếp theo khóa đối tượng và thường được triển khai dưới dạng cây nhị phân cân bằng.

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

Khi một bảng nhớ (mem table) đạt đến một kích thước nhất định, nó sẽ được đổ ra đĩa dưới dạng bảng chuỗi được sắp xếp bất biến.

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

Bảng ss lưu trữ các cặp khóa-giá trị theo một trình tự được sắp xếp.

These writes are all sequential I.O.

Tất cả các lần ghi này đều là I/O tuần tự.

They are fast on any storage media.

Chúng hoạt động nhanh trên mọi loại phương tiện lưu trữ.

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

Bảng ss mới trở thành phân đoạn gần đây nhất của cây LSM.

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

Khi có thêm dữ liệu, ngày càng nhiều bảng SS bất biến này được tạo ra và thêm vào cây LSM.

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

trong đó mỗi phần đại diện cho một tập hợp con theo thứ tự thời gian nhỏ của các thay đổi đang đến.

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

Vì các bảng SS là bất biến, việc cập nhật khóa đối tượng hiện có sẽ không ghi đè lên bảng hiện có.

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.

Thay vào đó, một mục mới được thêm vào bảng SS gần nhất, sẽ thay thế mọi mục trong các bảng SS cũ tương ứng với khóa đối tượng.

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

Việc xóa một đối tượng cũng đòi hỏi cách xử lý đặc biệt, vì chúng ta không thể đánh dấu bất kỳ mục nào trong bảng SS là đã bị xóa.

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

Để thực hiện thao tác xóa, nó sẽ thêm một dấu hiệu gọi là tombstone vào bảng SS gần nhất tương ứng với khóa của đối tượng.

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

Khi chúng ta gặp một tombstone trong quá trình đọc, chúng ta biết rằng đối tượng đó đã bị xóa.

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

Và đúng vậy, việc một thao tác xóa lại chiếm thêm không gian lưu trữ thì hơi khó hiểu một chút.

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,

Để xử lý một yêu cầu đọc, trước tiên chúng ta thử tìm khóa trong bảng nhớ (mem table), sau đó tìm trong bảng SS gần đây nhất trong cây LSM.

then the next SS table, and so on.

sau đó là bảng SS tiếp theo, và cứ thế tiếp tục.

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

Vì bảng SS được sắp xếp, việc tra cứu có thể được thực hiện một cách hiệu quả.

The accumulation of SS tables presents two issues.

Việc tích lũy các bảng SS đặt ra hai vấn đề.

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

Khi số lượng SSTable tăng lên, việc tra cứu một khóa sẽ mất ngày càng nhiều thời gian.

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

Khi các SSTable tích lũy lại, số lượng các mục không còn hiệu lực ngày càng tăng khi các khóa được cập nhật và các tombstone được thêm vào.

These take up precious disk space.

Những thứ này chiếm dụng không gian đĩa quý giá.

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

Để khắc phục những vấn đề này, một quá trình hợp nhất và nén dữ liệu định kỳ đang chạy ở chế độ nền.

to merge SSTables and discard outdated or deleted values.

để hợp nhất các SSTable và loại bỏ các giá trị đã lỗi thời hoặc đã bị xóa.

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

Điều này thu hồi lại không gian này và giới hạn số lượng SSTable mà một thao tác đọc phải duyệt qua.

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

Vì các bảng đã được sắp xếp, quá trình hợp nhất và nén này rất đơn giản và hiệu quả.

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

Cách tiếp cận này tương tự như cách tiếp cận được sử dụng trong giai đoạn hợp nhất của thuật toán sắp xếp hợp nhất.

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

Tóm lại, đây chính là cách cây LSM cung cấp tốc độ ghi nhanh.

Let's recap.

Chúng ta hãy tóm tắt lại nhé.

An LSM tree buffers incoming writes in memory.

Cây LSM đệm các thao tác ghi đến vào bộ nhớ trong.

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

Khi bộ đệm đầy, chúng ta sắp xếp và đẩy dữ liệu ra đĩa dưới dạng bảng SS bất biến.

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

Số lượng bảng SS tăng lên khi nhiều bộ đệm hơn được đẩy ra đĩa.

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

Điều này gây ra một vấn đề đối với các thao tác đọc, vì mỗi thao tác đọc phải tìm kiếm qua các bảng SS này để thực hiện tra cứu.

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.

Để giới hạn số lượng bảng SS mà nó phải tìm kiếm cho mỗi lần đọc, cây LSM sẽ hợp nhất các bảng SSTable và nén chúng trong nền.

Let's look at the compaction process more closely.

Chúng ta hãy xem xét kỹ hơn quá trình nén chặt.

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

Khi các SSTable được hợp nhất, chúng được sắp xếp thành các cấp độ.

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

Đây chính là lúc phần cây của cấu trúc LSM tree phát huy tác dụng.

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

Có nhiều chiến lược khác nhau để xác định thời điểm và cách thức các SSTable được hợp nhất và nén.

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

Có hai chiến lược tổng quát là nén theo cấp kích thước và nén theo cấp độ.

Size tier compaction is optimized for write throughput.

Việc nén theo cấp kích thước được tối ưu hóa cho thông lượng ghi.

Level compaction is more read optimized.

Nén theo cấp độ được tối ưu hóa nhiều hơn cho hoạt động đọc.

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

Chúng ta sẽ không đi quá sâu vào chi tiết cách các chiến lược nén này hoạt động.

There are a few key points to remember though.

Tuy nhiên, có một vài điểm quan trọng cần nhớ.

Compaction keeps the number of SS tables manageable.

Việc nén giữ số lượng bảng SS ở mức có thể quản lý được.

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

Các bảng SS được tổ chức thành các cấp độ, với mỗi cấp độ có kích thước tăng theo cấp số nhân khi các bảng SS từ cấp độ trên hợp nhất vào nó.

Compaction consumes a lot of I.O.

Quá trình nén dữ liệu tiêu tốn rất nhiều tài nguyên I/O.

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

Quá trình nén bị lệch tần có thể làm hệ thống thiếu tài nguyên và làm chậm cả hoạt động đọc và ghi.

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

Cuối cùng, chúng ta hãy xem xét một số tối ưu hóa phổ biến cho cây LSM trong các hệ thống sản xuất.

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

Có rất nhiều chiến lược tối ưu hóa nhằm mục đích mang lại hiệu suất đọc gần với hiệu suất của cây B.

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

Những điều chúng tôi giải thích dưới đây chỉ là những trường hợp phổ biến, và chúng hoàn toàn không phải là danh sách đầy đủ.

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

Để tra cứu một khóa, nó thực hiện tìm kiếm trên các bảng SS ở mọi cấp độ.

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

Mặc dù việc tìm kiếm trên dữ liệu đã được sắp xếp diễn ra nhanh chóng, việc duyệt qua toàn bộ các bảng SS nằm trên đĩa tiêu tốn rất nhiều tài nguyên I/O.

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

Nhiều hệ thống duy trì một bảng tóm tắt trong bộ nhớ chứa phạm vi giá trị nhỏ nhất-lớn nhất của mỗi khối đĩa ở mọi cấp độ.

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

Nó cho phép hệ thống bỏ qua việc tìm kiếm trên những khối đĩa mà khóa không nằm trong phạm vi đó.

This saves a lot of random I.O.

Điều này giúp tiết kiệm rất nhiều hoạt động nhập/xuất ngẫu nhiên.

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

Một vấn đề khác có thể gây tốn kém về mặt hiệu năng là việc tìm kiếm một khóa không tồn tại.

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

Điều này sẽ yêu cầu xem xét tất cả các khối đủ điều kiện ở tất cả các cấp độ.

Most systems keep a bloom filter at each level.

Hầu hết các hệ thống đều duy trì một bộ lọc bloom ở mỗi cấp độ.

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.

Bộ lọc Bloom là một cấu trúc dữ liệu tiết kiệm không gian, nó trả về kết quả chắc chắn là không nếu một khóa không tồn tại, hoặc kết quả có thể là có nếu một khóa có khả năng tồn tại.

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.

Điều này cho phép hệ thống bỏ qua hoàn toàn một cấp nếu khóa không tồn tại ở đó, giúp giảm đáng kể số lượng hoạt động nhập/xuất ngẫu nhiên cần thực hiện.

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

Tóm lại, các cơ sở dữ liệu NoSQL được hỗ trợ bởi cây LSM có thể được điều chỉnh để hỗ trợ tốc độ ghi rất cao.

As with any database, proper tuning is the key.

Như với bất kỳ cơ sở dữ liệu nào, việc tinh chỉnh đúng cách là yếu tố then chốt.

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

Đối với cây LSM, việc tinh chỉnh quá trình nén là yếu tố quan trọng nhất.

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

Nếu bạn muốn tìm hiểu thêm về thiết kế hệ thống, hãy xem qua các cuốn sách và bản tin hàng tuần của chúng tôi.

Please subscribe if you learn something new.

Hãy đăng ký kênh nếu bạn học được điều gì đó mới nhé.

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

Cảm ơn rất nhiều và hẹn gặp lại lần sau.

Tải Ứng Dụng

Mọi thứ bạn cần để nói trôi chảy

Chấm điểm AIChấm từng câu nói

Luyện IPAThành thạo mọi âm

Từ vựngMở rộng vốn từ

Game Từ vựngHọc qua chơi

Quét QR

Download on theApp Store Get it onGoogle Play

Cùng kênh

FOR YOU

Video gợi ý

147 câu

What Is a Data Mesh? Databricks Unity Catalog Explained

Daily ConversationUniversity StudentsWorking Adults

65 câu

Did Anthropic Kill Git?

Daily ConversationUniversity StudentsWorking Adults

68 câu

what is a database index?

Daily ConversationUniversity StudentsWorking Adults

65 câu

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

Daily ConversationUniversity StudentsWorking Adults

202 câu

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

Daily ConversationUniversity StudentsWorking Adults

231 câu

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

Daily ConversationUniversity StudentsWorking Adults

398 câu

Sec Growth DataScience staff meeting Sep 14 2022

Daily ConversationUniversity StudentsWorking Adults

205 câu

The Man Who Stole MySpace | Samy

Daily ConversationUniversity StudentsWorking Adults

689 câu

Database Sharding! Designing Data-Intensive Applications chapter 6

Daily ConversationUniversity StudentsWorking Adults

27 câu

You are wasting memory

Daily ConversationUniversity StudentsWorking Adults

532 câu

How an Ex-Googler Accidentally Founded a Database Company

Daily ConversationUniversity StudentsWorking Adults

Từ vựng và ghi chú luyện nói cho bài học này

Bài luyện nói trình độ C1 này dựa trên video “The Secret Sauce Behind NoSQL: LSM Tree”. Những từ được nhắc lại nhiều nhất trong bài: table, tree, key, Lsm, compaction. Video này có 77 câu và 1089 từ để luyện shadowing. Phần lời nói dài 7:26. Người nói giữ tốc độ đều, khoảng 147 từ mỗi phút, vừa sức để nói đuổi theo. Chỉ 72% số từ nằm trong 3.000 từ tiếng Anh thông dụng nhất, nên từ vựng khá khó.

Từ vựng quan trọng trong video

13 từ khó nhất trong video, kèm phiên âm và nghĩa:

Từ	Phiên âm	Nghĩa
merge động từ	/mɝd͡ʒ/	kết hợp, hợp nhất
disk danh từ	/dɪsk/	đĩa
tombstone danh từ	/ˈtuːmstoʊn/	bia mộ, mộ chí
flush động từ	/ˈflʌʃ/	xả
consume động từ	/kənˈsum/	dùng, tiêu thụ
organize động từ	/ˈɔɹɡənaɪz/	sắp xếp, tổ chức
discard động từ	/dɪsˈkɑɹd/	vứt, loại bỏ
starve động từ	/stɑɹv/	chết đói
subset danh từ	/ˈsʌbˌsɛt/	tập hợp con, tập con
newsletter danh từ	/ˈn(j)uzˌlɛtɚ/	bản tin
explode động từ	/ɪkˈsploʊd/	nổ
subscribe động từ	/səbˈskɹaɪb/	đăng kí
algorithm danh từ	/ˈælɡəɹɪðm̩/	thuật toán

Cụm động từ bạn sẽ nghe

Từ	Phiên âm	Nghĩa
look up động từ	/ˌlʊk ˈʌp/	ngước
check out động từ		tính tiền, trả phòng

Ngữ pháp trong video

Những cấu trúc người nói dùng nhiều nhất, kèm đúng cụm từ trong video:

Cấu trúc	Trong video
Câu bị động be + quá khứ phân từ — nhấn vào việc xảy ra, không phải người làm	is optimized · is typically stored · is commonly backed
Thì hiện tại hoàn thành have/has + quá khứ phân từ — việc đã xảy ra nhưng còn liên quan đến hiện tại	have exploded · has been deleted

Phát âm cần chú ý

Âm “th”: throughput /ˈθɹuː.pʊt/, algorithm /ˈælɡəɹɪðm̩/
Âm “sh” và “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/
Từ dài — đặt trọng âm cho đúng: 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/

Những âm người Việt thường gặp khó:

Cụm phụ âm cuối — đọc đủ từng âm, đừng nuốt âm cuối: disk /dɪsk/, ingest /ɪnˈd͡ʒɛst/, compact /kəmˈpækt/, discard /dɪsˈkɑɹd/, starve /stɑɹv/
Âm /tʃ/, /dʒ/ và /ʒ/ — tiếng Việt không có, đừng đọc thành “ch” hay “gi”: merge /mɝd͡ʒ/, ingest /ɪnˈd͡ʒɛst/, chronological /ˌkɹɑnəˈlɑd͡ʒɪkəl/, manageable /ˈmænəd͡ʒəb(ə)l/, sequential /səˈkwɛntʃəl/
Âm /æ/ — mở miệng rộng hơn âm “e”: compaction /kəmˈpækʃən/, compact /kəmˈpækt/, manageable /ˈmænəd͡ʒəb(ə)l/, bash /bæʃ/, algorithm /ˈælɡəɹɪðm̩/

Cách luyện với video này

Nghe hết video một lần, chưa cần nói, và ghi lại những từ bạn chưa biết.
Nói đuổi từng câu ở tốc độ bình thường, lặp lại mỗi câu đến khi nhịp của bạn khớp với người nói.
Ghi âm giọng mình rồi so với bản gốc, chú ý các từ như merge, disk, tombstone.

Phương Pháp Shadowing Là Gì?

Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.

Phương pháp shadowing: đọc hướng dẫn từng bước đầy đủ →

Luyện nói tiếng Anh bằng Shadowing qua video: The Secret Sauce Behind NoSQL: LSM Tree

Chọn chế độ luyện tập

Tải Ứng Dụng

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

Từ vựng và ghi chú luyện nói cho bài học này

Từ vựng quan trọng trong video

Cụm động từ bạn sẽ nghe

Ngữ pháp trong video

Phát âm cần chú ý

Cách luyện với video này

Phương Pháp Shadowing Là Gì?