我是從一篇介紹LSM原理的文章的擴展閱讀部分，找到這篇文章的。前者的作者稱，后者對LSM的原理做了非常精彩的介紹。我讀了以后，深以為然：文章沒有長篇大論，也沒有深奧的數學符號，從一個現實問題，引出了LSM出現的動機和基本原理。作者在最后說到：我們一不小心，又發明了一次LSM。所以，我把這篇文章翻譯成中文。本文并不是對原文的直譯，我有意刪除了其中的一些部分。網絡上有另一篇中文譯文，基本上算是原文的直譯，也可以參考。
SSTable
假設我們需要對大量(G或者T數量級)的數據，用不同的程序多次進行處理。就像我們需要對同一批數據跑多個Map-Reduce任務一樣。由于數據量太大，從存儲設備讀寫數據占據了絕大部分的處理時間。因此，我們并不考慮隨機讀寫。我們將用流的方式讀取數據，處理完之后，再以流的方式把數據寫入到外部存儲。這樣，我們就可以平攤掉I/O的帶來的性能損耗。這個很顯然。
SSTable(Sorted String Table)，是一個包含了任意有序鍵(key-value)值對的文件。key和value可以是任意的二進制對象，key重復沒關系，key和value也沒有必要進行字節填充。順序掃描一次這個文件，我們就可以在內存中建立起一個索引(index)。如果文件太大，無法在內存中放下全部索引，為了快速的讀取數據，我們可以單獨建立一個保存了key:offset(key在文件中的偏移量)的索引文件。就像下圖一樣。
SSTable和BigTable
SSTable寫到外部存儲后，文件基本上就不能變了。插入和刪除都會改變到文件的結構，需要大量的I/O操作。也就是，對于靜態索引來說，隨機的讀是很簡單和快的：讀入索引，再進行一次文件I/O，你就可以找到你想要的內容；或者，用memmap把整個SSTable文件映射到內存。
隨機寫要昂貴得多。除非整個SSTable都在內存中，這樣的話，我們只需要幾次指針操作。以SSTable為基礎，如何構造一種機制，使得即使P數量級的數據，也能達到很快的讀寫速度：這也是google的BigTable要解決的。他們怎么搞的？
SSTable和LSM樹
我們想要保留SSTable提供的快速讀取的特點，也想要支持快速寫入。事實上，我們基本已經有了一個思路：如果SSTable在內存當中(記成MemTable)，寫入速度是很快的；即使SSTable在外部存儲上，讀取速度也是很快的。這樣，我們就有了一個解決方案：
- 在內存當中裝載SSTable的索引
- 所有的寫操作在MemTable中進行
- 讀操作優先檢查MemTable是否存在，否則，再在SSTable的index中進行查找
- MemTable會被周期性地寫回到外部存儲
- 有一個定時任務周期性地合并外部存儲上的SSTable
如下圖所示：
我們都做了什么？所有的寫操作都在內存中進行，因此很快。MemTable達到一定大小的時候，就會被刷新到外部存儲上，成為一個SSTable。但是，我們在內存當中維護了SSTable的索引，當我們要進行一次讀操作的時候，我們會先檢查MemTable，如果沒有找到，我們再依次檢查每個SSTable的索引，再加上一次IO，因此也是很快的。我們一不小心，又發明了一次LSM。
更新和刪除
LSM中，不管已經存在的數據有多大，寫入總是很快的：我們只需要在末尾追加一條記錄。對于隨機讀，要么直接從內存中讀取(如果命中了MemTable)，要么只需要一次I/O操作，因此也是很快的。更新和刪除呢，性能如何？
SSTable一旦保存到外部存儲，基本就不能變了。因此，更新和刪除都不會動到這些數據。相反，對于更新操作來說，我們在MemTable中存入新的value，對于刪除操作，我們在MemTable中追加一條刪除的記錄。因為我們是順序檢查所有SSTable的索引的，因此，對于后續的讀操作來說，我們總會找到最新的值，或者刪除的記錄，不會讀到臟數據。
最后，太多的SSTable會占據大量的存儲空間，這不是啥好事，因此，會有一個定時任務來合并SSTable，這樣更新和刪除操作就會覆蓋掉老數據，從而節省了存儲空間。
