大型主鍵：10億行MySQL + InnoDB？

Question

我想知道InnoDB是否是格式化表格的最佳方式？該表包含一個字段，主鍵，該表每天將獲得816k行（est。）。這將變得非常快速！我正在處理文件存儲的方式（這會更快）？表格將存儲已經處理的Twitter ID的ID號碼？

此外，SELECT min('id')聲明中的任何估計的內存使用情況？任何其他的想法，非常感謝！

Answer 1

唯一的確定答案是嘗試兩個並測試，看看會發生什麼。

通常，MyISAM的寫入和讀取速度更快，但不能同時進行。當您寫入MyISAM表時，整個表會被鎖定以便插入完成。 InnoDB具有更多開銷，但使用行級鎖定，因此讀取和寫入操作可以同時進行，而不會出現MyISAM的表鎖定發生的問題。

但是，如果我的理解正確，你的問題有點不同。只有一列，該列是主鍵，這是MyISAM和InnoDB處理主鍵索引的不同方式的一個重要考慮因素。

在MyISAM中，主鍵索引就像任何其他二級索引一樣。每一行的內部都有一個行ID，索引節點只是指向數據頁的行ID。主鍵索引的處理方式與其他索引不同。

然而，在InnoDB中，主鍵是集羣化的，這意味着它們保持連接到數據頁面，並確保行內容按照主鍵在磁盤上保持物理排序順序（但只在單個數據頁面內可以按任何順序分散。）

因此，我認爲InnoDB可能有一個優勢，那就是MyISAM本質上必須做雙重工作 - 在數據頁面中寫入一次整數，然後再將其寫入索引頁面。 InnoDB不會這樣做，主鍵索引與數據頁面相同，只需寫入一次即可。它只需要在一個地方管理數據，MyISAM不必管理兩個副本。

對於任一存儲引擎，在索引列上執行類似min（）或max（）的操作應該是微不足道的，或者只是檢查索引中是否存在數字。由於該表只有一列，所以書籤查找甚至是必要的，因爲數據將完全在索引本身內表示。這應該是一個非常有效的指標。

我也不會那麼擔心桌子的大小。在一行的寬度只有一個整數的情況下，每個索引/數據頁面可以容納大量的行。

Answer 2

如果這些ID號碼單調增加，而您的寫入只追加數據（永遠不會修改它），那麼使用單個文件可能會快很多。 A SELECT min('id')然後只是讀取文件的第一行，而其他任何內容都是二進制搜索。

Answer 3

我建議你用ID或日期開始partioning表。分區根據某些定義的邏輯將大表拆分爲幾個較小的表（如按日期範圍拆分它），這使得它們更具管理性和內存明智。 MySQL 5.1內置此功能，或者您可以使用自定義解決方案來實現它。

在實現平面文件中的存儲時，會失去數據庫的所有優點 - 不能再執行涉及數據的查詢。

Answer 4

如果你的id列有一個索引，請選擇min（id）應該是O（1），這應該沒有太多的內存要求。

如果你的主鍵在Twitter上，那麼你有一個索引。

Answer 5

有存儲引擎對MySQL的開發區域一個很好的比較：

• MySQL Storage Engine Architecture, Part 1: An Overview
• MySQL Storage Engine Architecture, Part 2: An In-Depth Look
• MySQL Storage Engine Architecture, Part 3: Details and Comparison

從你的描述，我會說的MyISAM會更好，但它在很大程度上取決於應用程序的比較閱讀和寫作模式。

Answer 6

只有一個字段是主鍵，只添加記錄，這並不適合常規數據庫。

首先，您需要存儲兩倍的信息，每個字段都會進入數據表和索引。另一方面，關係數據庫被稱爲一方面，因爲它們將相關數據存儲到一行中;很難看出你的數據是否符合要求:-)如果你還在存儲其他內容，那麼數據庫將是值得的。

您沒有提及數據是否會一次被多個進程訪問 - 如果沒有，那麼您不需要數據庫ACID原則賦予的所有優點。即使你確實需要ACID，如果沒有完整的數據庫，仍然可以實現。

我的第一個雖然會構建自己的B樹或B +樹數據文件來存儲Twitter ID以避免數據重複。我可以看到你做的唯一查詢（基於問題）是：

• select tbl; min（id）;和
• select tbl where id =？

第一個可以通過簡單地在B樹結構之外的另一個文件中存儲最低的O（1）（並且當您得到較低的一個時替換它）。我不確定這個商業案例，除非它很快找出某個Twitter ID不在表格中（所以在這種情況下，你可能也需要max）。

第二個是標準的樹搜索技術，這是數據庫通常在封面下使用的技術。

Answer 7

我也看到一些貿易公司使用tick數據庫ie。 kdb + http://kx.com/