我正在進行分析任務，我們從大學圖書館獲得了包含近300.000.000行的部分數據集。哪個數據庫引擎適用於大型數據集
每一行包含：
我就把這一切MySQ內L表格，然後我開始詢問我的分析任務，但是簡單的查詢（SELECT * FROM table WHERE ID = something）需要9-10分鐘才能完成。所以我爲所有列創建了一個索引，這使得它明顯更快〜30秒。
所以我開始閱讀類似的問題，人們建議切換到「寬列商店」或「搜索引擎」而不是「關係」。
所以我的問題是，什麼是最好的數據庫引擎使用這些數據？
使用搜索引擎進行搜索是IMO的最佳選擇。
Elasticsearch當然！
聲明：我在彈性工作。 :)
恐怕我不得不倒下你的答案。它沒有包含*爲什麼*彈性對於OP的用例更好，或者* OP將如何使用它來獲得任何優勢。此外，由於您爲Elastic工作，因此建議似乎有偏見和自我服務，並沒有得到客觀原因的支持。我認爲Elastic是一款出色的產品，我對此毫無反應。但沒有技術是魔法。它有適當的用途，但也有其他情況下沒有優勢。 –
我想我只是回答了這個問題「所以我的問題是，什麼是最好的數據庫引擎用於這些數據？」。他用elasticsearch標記了他的問題，這是我來到這裏的唯一原因。確實。我沒有回答他沒有問的問題：「爲什麼？」... – dadoonet
答案當然是「取決於」。在你的例子中，你用一個給定的ID來統計數據庫中的記錄數量。我發現很難相信它會在MySQL中花費30秒，除非你在一些懶散的筆記本電腦上。
由於MySQL功能全面，性能穩定，性能相當出色，因此MySQL已經推出了數量驚人的系統。在文本搜索，羣集等方面，這是糟糕的（或者一直不好）。
像Elasticsearch這樣的系統對於文本來說很不錯，但對於您的系統來說可能不是很合適，這取決於使用情況。在您的模式中，您有一個文本字段（「所有者」），並且您不需要Elasticsearch的文本搜索功能（像誰需要阻止用戶名？）。 Elasticsearch也被廣泛用於日誌文件，這也不需要文本引擎。然而，它與文本塊和羣集很好。
如果這是一個班級作業，我會堅持使用MySQL。
然而，調整MySQL以最佳方式處理300 Mio行並不是微不足道的，而對ES來說，它是花生。 OP給出的時間點就是證明。安裝ES非常簡單，創建索引並比較時間。 – Val
請問這種問題時，運行'SHOW CREATE TABLE mytable'幷包含輸出。這是向我們展示您創建了哪些索引的最明確方式。同樣使用'EXPLAIN SELECT * FROM mytable WHERE ID = 1234 \ G'來分析您的查詢幷包含輸出，它向我們展示了優化器計劃如何使用您的索引。 –