每頁刷新成千上萬的記錄

Question

我開始考慮我的新項目，我發現了一些速度問題，所以我希望你能幫我選擇一個優雅和優雅的方式來編寫它。

每個用戶在數據庫中都有他訪問過的「地點」的記錄。每個地方都有「學校」 - 在這個特定的地方有許多學校。每所學校都有班級。每個班級可能會在不同的時間結束其「學習年」，因此如果日期> =學年結束，則​​該數字應該增加。

因此，我們有這樣一個數據庫：

「地方」 表：

place | user_id | 
----------------- 
1  | 4  | 
2  | 4  | 

用戶沒有4訪問的地點沒有1和2

「學校」 表：

school | place | 
---------------- 
5  | 2 | 
6  | 2 | 

地點2有兩所學校 - 編號爲5和6.

「級」表：

class | school | end_learning | class_number 
--------------------------------------------- 
20 | 5 | 01.01.2013 | 2 
21 | 5 | 03.01.2013 | 3 
22 | 5 | 05.01.2013 | 4 

學校5具有3類與IDS 20，圖21，22中。如果日期比大於2013年1月1日，第20類的類數目應被增加至3和結束學習日期改爲01.01.2014。等等。

現在我們遇到了問題 - 如果有1000個地方，每個地方有100所學校，每個地方有10個班級，我們有100萬條記錄。這很多。因爲我所提供的僅僅是一個簡單的例子，所以每次用戶刷新頁面時都必須考慮更新整個數據庫，所以我擔心這可能會導致記錄數量的減少。

我也可以序列類到一個字段校表：

school | place | classes 
------------------------------------------------------------------------- 
5  | 2 | serialized class 20, 21, 22 with end_learning field and class number 
6  | 2 | other serialized classes from school 6 

在這種情況下，我得到的少10倍的記錄，但每次我都反序列化數據，檢查日期，如果是低於現在改變它，序列化並保存到數據庫。第二個問題是我必須從db中選擇所有記錄來操作它們，而不僅僅是所有需要修改的記錄。

我也在考慮建立兩個數據庫：一個包含可能需要在未來進行更改的記錄，另一個可能需要在接下來的24小時內（不久的將來）進行更改。每24小時，所有在未來24小時內結束學習的課程都將轉移到「近期未來」分貝，因此每次刷新頁面都可以處理數千條記錄，而不是數十萬條或數百萬條記錄。而不是它在數百萬條記錄（更遠的未來）上工作，每天只創建一次「近期」表。

您對所有這些數據庫模式有何看法？也許你有更好的主意？

Answer 1

我不太明白你概述的業務邏輯或數據模型 - 但我會假設你已經想到了這一點。

首先，像MySQL這樣的RDBMS解決方案確實擅長管理大量記錄，只要您使用的數據是關係數據。據我所知，你將在許多記錄中進行搜索，但只更新一些記錄（用戶只能登記數量有限的課程）;我不認爲這是一個巨大的問題。其次，使用「標準」關係模型幾乎總是比較好，直到你可以證明它不符合你的性能需求，而不是在開始時選擇「異國情調」的解決方案（我將你的序列化和分區解答爲「異國情調」）。大量的時間和精力已經進入優化SQL性能;如果有一個簡單的選擇，它將成爲標準解決方案的一部分。當然，標準關係模型不會擴展的點（例如Facebook大小的流量），或者關係模型不適合的業務領域（文檔，圖表）。但是，所有的替代方案都具有像「標準」MySQL一樣的優點和缺點。

第三，處理可能的性能問題的最好方法就是處理它們。在代碼中。構建一個測試平臺，根據關係模型創建一個模式，用測試數據填充它（例如使用DbMonster），拋出一些負載（例如使用JMeter）並調整模式和查詢以證明您的情況不適合標準方案。如果你真的可以證明你不能在標準的關係數據庫中表現出色，那麼只能去尋找一些奇特的東西。