1
我們計劃在我們的Web應用程序中實現一項功能，該功能將爲用戶提供搜索功能，並將所有匹配記錄的ID作爲「列表」保存在DB（MySQL - INNODB）中。結果可能是數百萬。我們希望用戶能夠保存多達1百萬個ID。它必須是實時的（最大5-10秒延遲是可以接受的）。此列表可以稍後用作另一個與現有過濾器結合使用的過濾器。在MySQL中用於大型號的快速插入和搜索的最佳解決方案。行？
我們不需要從客戶端傳遞這些ID，因爲可以在服務器端完成相同的搜索以檢索這些ID。但是，稍後在相同搜索中，搜索結果可能會發生變化，因此無法重新使用這些ID。
我們有幾千個活躍用戶，並不期望很多人創建這樣的大列表，但隨着時間的推移總數沒有。保存在這些列表中的ID可以增長到數億。
服務器比完整數據庫（幾百GB）有更多的RAM。它也使用SSD。
這裏有問題，我們需要解決：
- Saving up to 1 million ids in DB (within few secs)
- Using these IDs as a search criteria with other filters (this additional criteria shouldn't slow down the searches by more than few secs)
這似乎是一些可能的解決方案：
解決方案1：
- 有一個單獨的表用戶標識，列表標識，文檔標識
- 將標識保存在單獨的行中（1列表可能爲100萬行）
- 特定大小後的分區表
好處：此表可以很容易地在JOIN條件中使用，並且索引搜索性能應該很快。
問題：插入會很慢 - 我知道有辦法加速插入，但仍然可能需要比幾秒更長的時間，特別是一旦表增長。
解決方案2：
- 全部保存在一排
- 編號傳送這些ID在參數查詢中使用類似的MapReduce技術大塊快速搜索
優點：的插入會相當快。
問題：使用MapReduce的搜索性能可能會很快，但它可以在服務器上承受很多負載，特別是如果許多用戶開始執行此類搜索。
任何建議是什麼將是最好的方式？有沒有其他可能的方法來迎合這種情況？
如果有人能對此發表評論，我們將非常感激。 –
http://stackoverflow.com/questions/2194914/why-is-mysql-innodb-so-much-slower-at-full-table-scans-than-myisam – Annabelle
是否強制使用MySQL？，因爲你可以使用mongodb來增加你的讀/寫性能。 –