mirror of
https://github.com/Vonng/ddia.git
synced 2024-12-06 15:20:12 +08:00
update PR list and zh-tw content
This commit is contained in:
Gang Yin
parent
90a76f3def
commit
947813d237
@ -152,6 +152,7 @@
|
||||
|
||||
| ISSUE & Pull Requests | USER | Title |
|
||||
| ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| [140](https://github.com/Vonng/ddia/pull/140) | [@Bowser1704](https://github.com/Bowser1704) | ch5: 修正章节Summary中多处不通顺的的翻译 |
|
||||
| [139](https://github.com/Vonng/ddia/pull/139) | [@Bowser1704](https://github.com/Bowser1704) | ch2&ch3: 修正多处不通顺的或错误的翻译 |
|
||||
| [137](https://github.com/Vonng/ddia/pull/137) | [@fuxuemingzhu](https://github.com/fuxuemingzhu) | ch5&ch6: 优化多处不通顺的或错误的翻译 |
|
||||
| [134](https://github.com/Vonng/ddia/pull/134) | [@fuxuemingzhu](https://github.com/fuxuemingzhu) | ch4: 优化多处不通顺的或错误的翻译 |
|
||||
|
||||
@ -152,6 +152,8 @@
|
||||
|
||||
| ISSUE & Pull Requests | USER | Title |
|
||||
| ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| [140](https://github.com/Vonng/ddia/pull/140) | [@Bowser1704](https://github.com/Bowser1704) | ch5: 修正章節Summary中多處不通順的的翻譯 |
|
||||
| [139](https://github.com/Vonng/ddia/pull/139) | [@Bowser1704](https://github.com/Bowser1704) | ch2&ch3: 修正多處不通順的或錯誤的翻譯 |
|
||||
| [137](https://github.com/Vonng/ddia/pull/137) | [@fuxuemingzhu](https://github.com/fuxuemingzhu) | ch5&ch6: 最佳化多處不通順的或錯誤的翻譯 |
|
||||
| [134](https://github.com/Vonng/ddia/pull/134) | [@fuxuemingzhu](https://github.com/fuxuemingzhu) | ch4: 最佳化多處不通順的或錯誤的翻譯 |
|
||||
| [133](https://github.com/Vonng/ddia/pull/133) | [@fuxuemingzhu](https://github.com/fuxuemingzhu) | ch3: 最佳化多處錯誤的或不通順的翻譯 |
|
||||
|
||||
@ -927,7 +927,7 @@ Cypher和SPARQL使用SELECT立即跳轉，但是Datalog一次只進行一小步
|
||||
|
||||
* 使用基因組資料的研究人員通常需要執行**序列相似性搜尋**，這意味著需要一個很長的字串（代表一個DNA分子），並在一個擁有類似但不完全相同的字串的大型資料庫中尋找匹配。這裡所描述的資料庫都不能處理這種用法，這就是為什麼研究人員編寫了像GenBank這樣的專門的基因組資料庫軟體的原因【48】。
|
||||
* 粒子物理學家數十年來一直在進行大資料型別的大規模資料分析，像大型強子對撞機（LHC）這樣的專案現在可以工作在數百億兆位元組的範圍內！在這樣的規模下，需要定製解決方案來阻止硬體成本的失控【49】。
|
||||
* **全文搜尋**可以說是一種經常與資料庫一起使用的資料模型。資訊檢索是一個很大的專業課題，我們不會在本書中詳細介紹，但是我們將在第三章和第三章中介紹搜尋索引。
|
||||
* **全文搜尋**可以說是一種經常與資料庫一起使用的資料模型。資訊檢索是一個很大的專業課題，我們不會在本書中詳細介紹，但是我們將在第三章和第三部分中介紹搜尋索引。
|
||||
|
||||
讓我們暫時將其放在一邊。在[下一章](ch3.md)中，我們將討論在**實現**本章描述的資料模型時會遇到的一些權衡。
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ db_get () {
|
||||
麻雀雖小，五臟俱全：
|
||||
|
||||
```bash
|
||||
$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}' $
|
||||
$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'
|
||||
|
||||
$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'
|
||||
|
||||
@ -118,7 +118,7 @@ $ cat database
|
||||
|
||||
***崩潰恢復***
|
||||
|
||||
如果資料庫重新啟動，則記憶體雜湊對映將丟失。原則上，您可以透過從頭到尾讀取整個段檔案並在每次按鍵時注意每個鍵的最近值的偏移量來恢復每個段的雜湊對映。但是，如果段檔案很大，這可能需要很長時間，這將使伺服器重新啟動痛苦。 Bitcask透過儲存加速恢復磁碟上每個段的雜湊對映的快照，可以更快地載入到記憶體中。
|
||||
如果資料庫重新啟動，則記憶體雜湊對映將丟失。原則上，您可以透過從頭到尾讀取整個段檔案並在每次按鍵時注意每個鍵的最近值的偏移量來恢復每個段的雜湊對映。但是，如果段檔案很大，這可能需要很長時間，這將使伺服器重新啟動痛苦。 Bitcask 透過儲存每個段的雜湊對映的快照在磁碟上來加速恢復，可以使雜湊對映更快地載入到記憶體中。
|
||||
|
||||
***部分寫入記錄***
|
||||
|
||||
@ -193,7 +193,7 @@ $ cat database
|
||||
|
||||
#### 用SSTables製作LSM樹
|
||||
|
||||
這裡描述的演算法本質上是LevelDB 【6】和RocksDB 【7】中使用的鍵值儲存引擎庫，被設計嵌入到其他應用程式中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了類似的儲存引擎【8】，這兩種引擎都受到了Google的Bigtable文件【9】（引入了SSTable和memtable）的啟發。
|
||||
這裡描述的演算法本質上是LevelDB 【6】和RocksDB 【7】中使用的鍵值儲存引擎庫，被設計嵌入到其他應用程式中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了類似的儲存引擎【8】，這兩種引擎都受到了Google的Bigtable文件【9】（引入了術語 SSTable 和 memtable ）的啟發。
|
||||
|
||||
最初這種索引結構是由Patrick O'Neil等人描述的，且被命名為日誌結構合併樹（或LSM樹）【10】，它是基於更早之前的日誌結構檔案系統【11】來構建的。基於這種合併和壓縮排序檔案原理的儲存引擎通常被稱為LSM儲存引擎。
|
||||
|
||||
@ -605,7 +605,7 @@ WHERE product_sk = 31 AND store_sk = 3
|
||||
|
||||
將磁碟視為一組可以覆寫的固定大小的頁面。 B樹是這種哲學的典範，用在所有主要的關係資料庫中和許多非關係型資料庫。
|
||||
|
||||
日誌結構的儲存引擎是相對較新的發展。他們的主要想法是，他們系統地將隨機訪問寫入順序寫入磁碟，由於硬碟驅動器和固態硬碟的效能特點，可以實現更高的寫入吞吐量。在完成OLTP方面，我們透過一些更復雜的索引結構和為保留所有資料而最佳化的資料庫做了一個簡短的介紹。
|
||||
日誌結構的儲存引擎是相對較新的發展。他們的主要想法是，他們系統地將隨機訪問寫入轉換為磁碟上的順序寫入，由於硬碟驅動器和固態硬碟的效能特點，可以實現更高的寫入吞吐量。在完成OLTP方面，我們透過一些更復雜的索引結構和為保留所有資料而最佳化的資料庫做了一個簡短的介紹。
|
||||
|
||||
然後，我們從儲存引擎的內部繞開，看看典型資料倉庫的高階架構。這一背景說明了為什麼分析工作負載與OLTP差別很大：當您的查詢需要在大量行中順序掃描時，索引的相關性就會降低很多。相反，非常緊湊地編碼資料變得非常重要，以最大限度地減少查詢需要從磁碟讀取的資料量。我們討論了列式儲存如何幫助實現這一目標。
|
||||
|
||||
|
||||
10
zh-tw/ch5.md
10
zh-tw/ch5.md
@ -739,11 +739,11 @@
|
||||
|
||||
***可伸縮性***
|
||||
|
||||
能夠處理比單個機器更高的讀取量可以透過對副本進行讀取來處理
|
||||
透過在副本上讀，能夠處理比單機更大的讀取量
|
||||
|
||||
|
||||
|
||||
儘管是一個簡單的目標 - 在幾臺機器上保留相同資料的副本，但複製卻是一個非常棘手的問題。它需要仔細考慮併發和所有可能出錯的事情，並處理這些故障的後果。至少，我們需要處理不可用的節點和網路中斷（甚至不考慮更隱蔽的故障，例如由於軟體錯誤導致的靜默資料損壞）。
|
||||
儘管是一個簡單的目標 - 在幾臺機器上保留相同資料的副本，但複製卻是一個非常棘手的問題。它需要仔細考慮併發和所有可能出錯的事情，並處理這些故障的後果。至少，我們需要處理不可用的節點和網路中斷（這還不包括更隱蔽的故障，例如由於軟體錯誤導致的靜默資料損壞）。
|
||||
|
||||
我們討論了複製的三種主要方法：
|
||||
|
||||
@ -761,7 +761,7 @@
|
||||
|
||||
每種方法都有優點和缺點。單主複製是非常流行的，因為它很容易理解，不需要擔心衝突解決。在出現故障節點，網路中斷和延遲峰值的情況下，多領導者和無領導者複製可以更加穩健，但以更難以推理並僅提供非常弱的一致性保證為代價。
|
||||
|
||||
複製可以是同步的，也可以是非同步的，這在發生故障時對系統行為有深遠的影響。儘管在系統執行平穩時非同步複製速度很快，但是在複製滯後增加和伺服器故障時要弄清楚會發生什麼，這一點很重要。如果一個領導者失敗了，並且你提升了一個非同步更新的追隨者成為新的領導者，那麼最近提交的資料可能會丟失。
|
||||
複製可以是同步的，也可以是非同步的，這在發生故障時對系統行為有深遠的影響。儘管在系統執行平穩時非同步複製速度很快，但是要弄清楚在複製滯後增加和伺服器故障時會發生什麼，這一點很重要。如果一個領導者失敗了，並且你提升了一個非同步更新的追隨者成為新的領導者，那麼最近提交的資料可能會丟失。
|
||||
|
||||
我們研究了一些可能由複製滯後引起的奇怪效應，我們也討論了一些有助於決定應用程式在複製滯後時的行為的一致性模型：
|
||||
|
||||
@ -771,11 +771,11 @@
|
||||
|
||||
***單調讀***
|
||||
|
||||
使用者在一個時間點看到資料後，他們不應該在某個更早的時間點看到資料。
|
||||
使用者在看到某一個時間點的資料後，他們不應該再看到某個更早時間點的資料。
|
||||
|
||||
***一致字首讀***
|
||||
|
||||
使用者應該將資料視為具有因果意義的狀態：例如，按照正確的順序檢視問題及其答覆。
|
||||
使用者應該看到資料處於一種具有因果意義的狀態：例如，按正確的順序看到一個問題和對應的回答。
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user