公交調度 - 關係型數據庫或nosql

我試圖存儲公交車的時間表到數據庫中，我想知道哪種數據庫模型適合我的情況。公交調度 - 關係型數據庫或nosql

我有公交運營商，每個運營商有幾條路線，每條路線有幾個轉彎，每個轉彎都有停車等等。轉彎是從一個被稱爲「轉向大師」的地方產生的，其中定義了調度（頻率，停止等）。）在未來N天內。

當用戶在給定的日期嘗試搜索從城市到城市的公共汽車時，我期望提供非常快速的公交搜索。

我正在使用MySQL，停止的數量達到了100.000條左右的記錄，搜索速度很快，但我不確定當數據變得非常大時它是否仍然很快（每個操作員有數千個操作員，轉彎大約有10站，轉彎在接下來的30天左右產生）。

基本上，執行搜索是查看站點（城市/城鎮/地點，時間），並檢查它是否符合用戶搜索條件。

所以，我的問題是：在這種情況下關係數據庫是否最好？或者當數據變得非常龐大時，使用某種NoSQL會更好？

由於提前，

來源

2013-09-28 khoi nguyen

NoSQL數據庫的設計與在不同的或不可預知的方式結構化非結構化數據或數據的工作。您的數據以非常好理解和可預測的方式構建。

是什麼讓您認爲關係數據庫不適合您的應用程序？有很多行並不意味着你的關係查詢將會很慢。應用程序的性能取決於具有適當的索引，但更重要的是，它將取決於您的應用程序邏輯。你用什麼啓發式方法來解決旅行商問題？如何進行路由可能會對系統性能產生比數據存儲選擇更大的影響。

來源

2013-09-28 12:39:17

嗨，謝謝你的回答。我們不必在旅行商問題上工作。我們只列出所有在用戶搜索目的地停留的轉彎並將其全部顯示出來。基本上，我必須在同一個停靠桌上自行加入，以檢查同一轉彎的停靠是否覆蓋用戶的搜索目的地。如果我們在停止表中有n行，我們必須以某種方式循環n！次檢查（種交叉連接）。你有其他想法來改善這一點嗎？非常感謝， –

我也在考慮如何分解數據，以便我可以使用多個線程對每個部分進行搜索，然後將它們組合在一起以獲得最終結果，但仍然沒有任何想法，當使用MySQL。我相信當停止數達到數百萬/億時，即使我們有適當的索引，使用單個查詢時搜索性能也會很慢。 –

@khoinguyen - 關於多個線程：讓數據庫引擎執行查詢優化。幾乎肯定會做得更好，你會嘗試手動完成。如果您無法從數據庫引擎中獲得所需的性能，請嘗試對數據進行分區以獲得性能。重新算法：你應該有一個路由啓發式。參見：http://stackoverflow.com/questions/430142/what-algorithms-compute-directions-from-point-a-to-point-b-on-a-map –

公交調度 - 關係型數據庫或nosql

回答

相關問題