可伸縮數據庫，索引的最佳併發模型？

Question

我很喜歡併發技術，這些技術相對容易實現，並且適用於縮放（多節點）。

如果您知道一些更高級的算法，請提供一些信息。

希望這個話題對別人有用。 謝謝！

更新

我在NoSQL的儲存和模型有趣。

Answer 1

你需要仔細考慮你正在尋找的東西。 「可伸縮」是指數據庫的大小嗎？讀者人數？同時作家的數量？讀者在沒有內在矛盾的作家的情況下的吞吐量？通過「索引」，你的意思是像btree這樣的傳統的完全有序的索引，還是哈希算法呢？還有，讀者和作者想要達到什麼樣的一致性？

以前的評論建議散列，如果你不需要像btree一樣的有序索引，那就很好，因爲散列操作會將密鑰空間分割成單獨的部分，以便同時執行操作避免交互。另一方面，範圍查詢需要某種類型的樹索引，它存在問題，因爲單個更新可以在調整索引時鎖定所有其他查詢。傳統的解決方案http://en.wikipedia.org/wiki/Multiversion_concurrency_control

Answer 2

在數據庫中最大化併發能力的理想方法是使用帶有散列鍵的「稀疏填充」表。這可以通過PK（或可以讓你快速到達PK的代理）即時檢索記錄，並且幾乎可以消除衝突。沒有必要讀取索引以確定記錄在表中「居住」的位置，因爲其位置可以是來自散列PK的計算的。然而，通過這種方式最大限度地提高併發能力，您可能會遭受一些其他折衷，例如無法快速檢索某個特定郵編的所有記錄，或無法按某個日期值立即排序表。快速獲取給定郵政編碼的所有記錄，或通過日期列立即排列行，通常將這些記錄進行物理分組，使它們在磁盤上保持連續，以避免過度的磁盤顛簸。使用散列鍵的人口稀疏的表格可能涉及在獲取記錄的組（例如紐約所有客戶）的組中，而在獲取單個記錄時（客戶＃123456）擅長的情況下，顯着的磁盤顛簸。

編輯：我應該補充說，在這種散列鍵稀疏填充的數據庫中，找到複合主鍵如ZIPCODE * CUSTOMERNUMBER並不罕見，以便給定郵編中的所有客戶最終都存儲在與人口稀少的表格大致相同的區域;這是爲了儘量減少運行郵編驅動報告時的抖動。因此，有方法可以緩解方法的不利影響，同時保持極低的衝突率和無索引所需的記錄提取。

編輯2：假設你想讓電子郵件地址成爲PK，但並不希望將來自AOL或YAHOO或GOOGLE的每個人的記錄聚集在備用填充表的相同區域中，在那裏「膨脹」，就像吞下豬的水蟒一樣。您可以使用左加權主鍵哈希算法來更加強調@左側的值。但是，如果您要使用數字順序PK，則可以使用右加權算法來消除此類凸起。