1
我正在處理包含有關船隻信息（測量）的數據庫。船舶發送更新他們的位置，燃料的使用，等於是在數據庫中的條目看起來像這樣如何優化大型數據庫請求
| measurement_id | ship_id | timestamp | position | fuel_use |
| key | f_key | dd-mm-yy hh:ss| lat-lon | in l/km |
這些條目中的一個新的獲取每艘船舶每一秒這樣的條目的添加量數據庫變得非常快。
我正在處理的應用程序需要的不是一秒鐘的信息，而是1分鐘，1天甚至1年的累積數據。例如，一天中的總燃料使用量，一年中的行駛距離，或一個月內每天的平均燃料使用量。
爲了得到這一點，並計算出從這些原始數據是不可行的，你將不得不從服務器獲得31.5萬條記錄來計算一年中的旅行距離。
我認爲是聰明的做法是將條目合併成一個更大的條目。例如，獲得60個測量值，並將它們合併到一個單獨表格中的1分鐘測量項目中。通過平均燃料使用量，並通過總結兩次輸入之間的距離。一分鐘條目會看起來像這樣。
| min_measurement_id | ship_id | timestamp | position | distance_traveled | fuel_use |
| new key |same ship| dd-mm-yy hh| avg lat-lon | sum distance_traveled | avg fuel_use |
這個過程可以重複使用幾小時，幾天，幾個月，幾年。這樣一個星期的查詢可以通過只請求7個查詢來完成，或者如果我想要每小時的詳細信息168個條目。這些看起來像更多可用的數字給我。
新表可以通過查詢原始數據庫每隔10分鐘被填充，這些數據則充滿分鐘表，這反過來又更新時間表等
然而，這似乎是一個很多管理並重復幾乎相同的數據，並且不斷進行相同的操作。
所以我感興趣的是如果有某種方式來構造這些數據。它是否可以按層次排序（在所有秒，幾天，幾分鐘都非常分層之後）還是有其他方法來優化它？
這是我第一次使用這個大小的數據庫，所以我也並不真正知道在互聯網上尋找什麼。
您必須正確設計系統，以便每秒數據不會與摘要數據不同步。小心，是的，使用大粒度緩存平均值是完全有效的。你必須弄清楚更高層次的東西需要看到：例如也許緩存每分鐘的位置邊界框，而不僅僅是平均值。位置。我不是這方面的專家，但你的建議聽起來很合理。索引也會複製/彙總數據，它們對於避免線性搜索至關重要。不同的是你是可能的。將不得不爲您需要的自定義摘要編寫代碼 –