使用密鑰存儲無限大小的巨大json數據

我需要存儲由地理點組成的地理路徑數據，這些地理點應由唯一鍵進行索引。例如：由其行程編號索引的車輛行駛的路徑。這條路可以是無限長的。使用密鑰存儲無限大小的巨大json數據

截至目前，我正在考慮以JSON對象的形式存儲路徑。我腦海中的選項是Riak和MongoDB。我想用開源技術。如果它支持集羣將會很好。如果一個節點出現故障，我們在應用程序中不會出現任何停機。

MySQL目前是我們的原始數據源（我們將以任何方式轉移到NoSQL DB，但不是現在）。但是，由於數據量巨大（每天有200萬個地理位置條目），因此MYSQL需要很長時間才能根據時間戳過濾數據。 MySQL仍然是我們的主要數據源。我正在尋找的解決方案將作爲基於id的更快路徑檢索的緩存。

在當前MySQL的架構，我有字段有：車輛

system_timestamp, 
gps_timestamp, 
speed, 
lat, 
lot

該表存儲中的所有地理點的車輛是否是在旅行或沒有。這裏的旅程是基於駕駛員是否想跟蹤運動。如果他想跟蹤運動，我們會生成一個唯一的行程ID，並將其與駕駛員的行程開始時間和結束時間相關聯。稍後，根據旅程ID顯示路徑，我們使用行程的開始時間結束時間來過濾來自原始表格的數據。

我想將行程路徑作爲緩存存儲到輔助數據庫中，以便檢索速度很快。

哪個數據庫應該是我的理想選擇？我還有什麼其他選擇？

來源

2016-06-12 Moinuddin Quadri

這似乎是一個有趣的話題，但有些事情我不清楚：1.目前數據如何存儲在MySQL數據庫中？ 2.你究竟想達到什麼目的？這聽起來像一方面你試圖按時間戳過濾，另一方面你想通過ID檢索這些條目。 3.你通過ID和「路徑」實際上意味着什麼？ –

更新了問題中的信息。我在mysql中有兩個表。一個根據時間戳存儲地理點。在另一張桌子上，我有獨特的旅行ID以及旅行的開始和結束時間。在選擇特定行程ID時，時間戳之間可用的所有地理點應以路徑的形式顯示給用戶。我正在考慮緩存此路徑，以便我可以節省檢索時間。 –

我不清楚你需要執行什麼查詢。鑑於trip_id，顯示路徑？給定位置，列出接近它的車輛？給定時間戳，獲取vehicle_ids及其位置？你的問題在實施上過於詳細，而且在目標上還不夠詳細。 –

我打算在這裏出去走一走，說我相信解決性能問題的方法不那麼複雜。我假設你在InnoDB中使用MySQL，並且你正在索引時間戳字段。

如果我是你，我只需將相關的時間戳（系統或gps）轉換爲主鍵。藉助InnoDB，表格數據的物理組織可基於主鍵列進行超快速查找。另外，請確保相關的時間戳列是無符號的非空類型。

現在，我不會在開始時間和結束時間之間查找路徑（正如您現在所做的那樣），而是在包含旅程ID /路徑時間戳對的同一MySQL數據庫中創建一個單獨的表，其中如前所述，「路徑時間戳」是路徑表中的主鍵。主要索引旅行ID。使用您最初爲Riak或MongoDB設想的相同邏輯/機制填充此表。這基本上就是你的「緩存」系統，只使用MySQL。

一個典型的查找將採用trip ID來查找所有關聯的路徑時間戳，從而找到所有路徑數據。

CREATE TABLE IF NOT EXISTS `paths` (
    `system_timestamp` int(10) unsigned NOT NULL, 
    `gps_timestamp` int(10) NOT NULL, 
    `speed` smallint(8) unsigned NOT NULL, 
    `lat` decimal(10,6) NOT NULL, 
    `lng` decimal(10,6) NOT NULL 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

ALTER TABLE `paths` ADD PRIMARY KEY (`system_timestamp`); 


CREATE TABLE IF NOT EXISTS `trips` (
    `trip_id` int(10) unsigned NOT NULL, 
    `system_timestamp` int(10) unsigned NOT NULL, 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

ALTER TABLE `trips` ADD PRIMARY KEY (`trip_id`); 


SELECT * FROM `trips` 
INNER JOIN `paths` ON 
    `trips`.`system_timestamp` = `paths`.`system_timestamp` 
WHERE `trip_id` = 1;

來源

2016-06-13 00:07:22

在我的情況下，表不能根據時間戳索引。讓您更瞭解我們的應用。以20,000輛車每10秒發送10個數據點（每秒1個數據點）爲例。這只是安裝在車內的OBD設備發送的數據。這些數據也由司機的手機以相同的速率發送。旅行的路徑是從兩個彙總數據 –

我明白，數據量是非常大的，我認爲這是一般非規範化屬於某旅的路徑是一個好主意（開始時間和行程結束時間之間）（如你之前描述過）爲了提高性能，但是你想通過切換到NoSQL解決方案實現什麼目標？我認爲你的問題不是技術堆棧錯誤，而是索引太大，可能比緩衝池/機器的RAM大幾倍。基本上，通過正確的硬件資源和正確的表結構，您可以在MySQL中實現相同的功能。 –

順便說一下，道歉離題，但你也可以根據時間戳相關的標準（例如，每天有它自己的表）將主路徑表分成更小的表，並將它們分佈到多臺機器上。這種分片技術在過去爲我工作。 –

使用密鑰存儲無限大小的巨大json數據

回答

相關問題