2016-03-15 81 views
0

方案如下具體時間緩存經營業務數據整合與歷史記錄的表:有數百個安裝在一些固定的 位置讀卡器如何根據

  1. 假設,還有數千張卡可能通過通過閱讀器 隨機。
  2. 每個讀卡器每小時讀卡數據至少10次。
  3. 在一個讀取期間,讀卡器將多次讀取卡片 取決於卡片停留在讀卡器可以從中讀取數據的字段的長度。因此,當讀卡器讀取卡片時,將生成一個 READ_EVENT,其中包括:reader_id,card_id, times_of_reads,first_seen_time,last_seen_time。
  4. 閱讀器可以立即將READ_EVENT上傳到後端系統。
  5. 如果網絡關閉,讀卡器也可以緩存READ_EVENT,當網絡再次OK 時,它將重新傳輸緩存的數據。

因此,我在DaseBase中有一個READ_EVENT表來保存所有事件。

當緩存READ_EVENT來了,我要檢討所有的歷史數據,以發現是否

  • 這READ_EVENT應該有存在的事件,這意味着 在此表中一個READ_EVENT會像被更新集成「有一個快速的 first_seen_time並將兩個time_of_read加在一起」或者「有一個 以後的last_seen_time和兩個time_of_read在一起」,或者「只需將兩個time_of_read加在一起」。
  • 此READ_EVENT無法與 表中的任何其他事件集成,因此只需將事件插入其中即可。

爲了清楚起見,所述「集成」是指如果這兩個持續時間(從「first_seen_time」到「last_seen_time」)在DB READ_EVENT的和緩存READ_EVENT有一個共同的週期。

這裏有一個問題:

因爲「first_seen_time」 /「last_seen_time」中緩存數據可以是任何時間(昨天,上個月,去年),並且表變得越來越大,這將是非常難以定位應該被集成的READ_EVENT。如何優化數據庫的設計。

+0

很難優化未知的東西。你目前的數據庫設計是什麼,你有什麼具體問題?大桌子本身不是問題。 如果我理解您的要求正確,您想在一個閱讀器上評估一張卡片的所有閱讀事件。一張卡片和一臺讀卡器的平均讀數和最大讀卡次數有多少個不同的讀取事件? – TAM

+0

Hi @TAM,謝謝你的回答。現在在數據庫「READ_EVENT」中只有一個表,這些列是「reader_id,card_id,times_of_reads,first_seen_time,last_seen_time」,並且在不到一個月的時間內從讀者上傳的記錄超過180,000條,因此它會越來越大。因此,當上傳一個緩存數據時,我必須按時間選擇查找表中的哪個記錄應該與它整合,因爲這個緩存的數據所表示的讀取動作可能會在幾天前發生。桌子的增長。 – ricemaster

回答

1

您需要一個或多個索引,具體取決於您的具體要求以及由這些索引產生的數據庫查詢。有了這些指標,記錄的總數將不太重要,因爲對小指數範圍的查詢仍然很快並且產生的記錄不會超過兩個。

假設您有關於reader_id,card_id和last_seen_time的索引。現在您想知道該讀卡器和卡上的當前事件是否可以與之前的事件結合。據我瞭解您的要求,這隻會影響最新的記錄。因此,像

select * 
from read_event 
where reader_id = :reader_id and card_id = :card_id 
order by last_seen_time desc 

,將獲得最新的事件作爲第一個記錄,查詢所以只有一條記錄需要從數據庫中,獨立拿來有多少條記錄包含的內容。

當然,如果記錄數量變得巨大,這可能會成爲一個問題,在純粹的空間或其他使用這些數據的案例方面。現在,從你的數字來看,我們估計每年有300萬條記錄。三年後,你有1000萬。三年後你還需要這些記錄嗎?因此,下一步將根據您的功能要求來決定您需要多長時間記錄每個記錄的舊數據,並根據日常業務的實際需要來對它們進行彙總。但是,只有在實際需求出現時,我纔會這樣做。通常,對數據收集的要求僅隨其使用而發展。因此,如果您過早丟棄數據,可能會出現用例需要的用例。這是不成熟的優化反模式。