是否值得嘗試MonetDB？

有沒有人有過使用MonetDB的經驗？目前，我有一個MySQL數據庫太大，查詢速度太慢。根據面向列的範例，插入會更慢（我根本不介意），但是數據檢索變得非常快。我是否有機會通過切換到MonetDB來獲得更多的數據檢索性能？ MonetDB是否足夠成熟？是否值得嘗試MonetDB？

來源

2011-09-15 martincho

任何比較MonetDB與Hyperdex，Aerospike，DynamoDB，Voldermort，VoltDB或ExtremeDB的基準？ – skan

只是想知道你是否試過MonetDB？如果表現對你有好處？ – carfield

您有機會改善應用程序的性能。但是，收益在很大程度上取決於您的工作量，數據庫大小和硬件。 MonetDB根據兩個主要假設進行開發/調整：

您的工作量是分析性的，即您有很多（分組）聚合等等。
更重要的是：您的熱門數據集（您實際使用的數據）適合您系統的主內存。 MonetDB沒有自己的緩衝區管理器，但依靠操作系統來處理磁盤I/O。由於操作系統（特別是windows，但也是Linux）有時對於磁盤交換非常愚蠢，可能會成爲一個問題（特別是對於內存不足的連接）。

至於成熟度，可能會比居住在這個星球上的人更多的意見。就我個人而言，我覺得它已經夠成熟了，但我是開發團隊的成員，因此有偏見。但MonetDB是一個研究項目，所以如果你有一個有趣的應用程序，我們很樂意聽到它，看看我們能否提供幫助。

來源

2011-09-16 10:34:56 Holger

一些進一步的描述：假設我的表有這些字段（name，birth_date，social_security_id，drivers_licence_id，annual_income），我希望能夠做到這一點：select *從DATE1和DATE2之間的名稱>「M」和birth_date的人年收入在10到100之間;而且我希望能夠排序這些字段中的任何一個。如果表格增長的很大，所有這些範圍都會導致性能下降。我覺得MonetDB在這種情況下幫不了什麼忙，但如果機會不大，我會試一試。 – martincho

那麼，我會說這取決於你的中間結果的大小（即，符合每個條件的元組的數量）。如果他們的ID（內部64位整數）適合主內存，你應該沒問題。如果沒有，如果你省略'order by'，它可能仍會表現得體。關於MonetDB的一點需要注意的是，所有的操作都非常有效地實現，但是所有的中間結果都在主內存（或潛在的磁盤）上實現，如果沒有足夠的內存，可能會導致性能下降。我想說你可以試試MonetDB。 – Holger

「適合內存」壓縮還是解壓縮？我的意思是，我是否有足夠的RAM來適應「dbfarm」文件夾的所有內容？（用一張大桌子談論一個數據庫）。謝謝 – GBrian

答案當然取決於你的有效載荷，但我的經驗，到目前爲止似乎表明，一切比我在MySQL已經看到了MonetDB更快。連接是個例外，它不僅看起來很慢，而且在流水線上看起來完全沒有用，所以你最終需要大量的內存來處理大內存。這就是說我在MySQL中加入的經驗並不是很好，所以我猜你的期望可能很低。如果你真的想要良好的連接性能，我可能會推薦SQL Server或類似的東西;對於您在後續評論中提到的其他查詢，MonetDB應該很棒。

例如，如果一個表格中有大約2百萬行，我可以在一列（範圍內有大約800K行）範圍內排列，然後按另一列排序，然後處理並返回有限的結果在25ms內。這些類型的查詢的性能似乎會隨着規模而降低，但這應該讓您體驗到您在該規模上可能會期望的結果。

我要告誡大家，樂觀併發模型可能甩開那些只暴露於悲觀併發（大多數人）。我想研究它之前，想知道爲什麼你的一些提交在併發負載下失敗。

來源

2012-06-02 06:22:07 N8allan

我想說大多數人都熟悉OCC模型，因爲大多數ORM都這麼做。另一方面，悲觀併發性和MVCC大多數人並不熟悉它（MySQL並沒有原始的支持它，大多數非企業Web應用程序都沒有事務，一些ORMS甚至不支持行/表鎖定）。 –

是否值得嘗試MonetDB？

回答

相關問題