2011-09-15 6 views
8

誰もMonetDBに関する経験はありましたか?現在、私は大きすぎるMySQLデータベースを持っており、クエリーは遅すぎます。列指向のパラダイムによると、挿入は遅くなりますが(私は気にしません)、データの取得は非常に高速になります。 MonetDBに切り替えるだけで、データ検索のパフォーマンスが向上する可能性はありますか? MonetDBは成熟していますか?MonetDBを試す価値はありますか?

+1

MonetDBとHyperdex、Aerospike、DynamoDB、Voldermort、VoltDB、またはExtremeDBを比較するベンチマークはありますか? – skan

+0

MonetDBを試してみましたか?あなたのパフォーマンスが良い場合は? – carfield

答えて

16

アプリケーションのパフォーマンスを向上させる可能性があります。しかし、その利得は、ワークロード、データベースのサイズ、およびハードウェアに大きく依存します。 MonetDBは、主に2つの仮定の下に調整/開発されています

  1. あなたのワークロードは分析的である、つまり、あなたは(グループ化)集計などがたくさんあります。
  2. ホットデータセット(実際に使用するデータ)は、システムのメインメモリに適合します。 MonetDBには独自のバッファマネージャはありませんが、ディスクI/Oを処理するためにOSに依存しています。 OS(特にウィンドウズでもLinuxでも)は、ディスクスワップに問題があることがあります(特にメモリ不足のジョインの場合)。

成熟に関しては、おそらく、この惑星に住む人々よりも多くの意見があります。個人的には、成熟していると私は思っていますが、私は開発チームのメンバーであり、偏見を持っています。しかし、MonetDBは研究プロジェクトです。面白いアプリケーションがあれば、それについて聞いてみたいと思っています。

+0

さらに詳しい説明:私のテーブルにこれらのフィールド(name、birth_date、social_security_id、drivers_licence_id、annual_income)があるとしましょう。これを行うには、* DATE1とDATE2の間のname> "M"とbirth_dateの人からselect * annual_incomeは10〜100です。そして、私はこれらのフィールドのいずれかを並べ替えることができるようにしたい。テーブルが本当に大きくなると、この範囲はすべてパフォーマンスを低下させます。私はMonetDBがこのケースではあまり助けにならないと感じていますが、小さなチャンスがあれば試してみます。 – martincho

+1

これは、中間結果のサイズ(各条件に適合するタプルの数)によって異なります。 ID(内部の64ビット整数)がメインメモリに収まる場合は、うまくいくはずです。もしそうでなければ、 'order by'を省略するとうまくいくかもしれません。MonetDBに関して注意すべきことは、すべての操作が非常に効率的に実装されていることですが、すべての中間結果が主メモリ(または潜在的にはディスク)に具体化されるため、RAMが不足しているとパフォーマンスが低下する可能性があります。 MonetDBに試してみるといいでしょう。 – Holger

+0

"Fit in RAM"圧縮または非圧縮?つまり、「dbfarm」フォルダのすべての内容に合うようにRAMを確保する必要がありますか? (1つの大きなテーブルで1つのデータベースについて話す)。ありがとう – GBrian

4

当然の答えはあなたのペイロードに依存しますが、私の経験では、これまでについてのすべては、私は、MySQLで見てきたよりもMonetDBで高速であることを示しているように思われます。例外はジョインです。ジョインは、遅く見えるだけでなく、パイプライン処理で完全に無力であるように見えるので、大規模なものを処理するためにメモリのゴブを必要とします。それは、MySQLでのジョインに関する私の経験は、まったく恒星ではないと言いました。あなたの期待が低いかもしれないと思います。本当に良い結合パフォーマンスが必要な場合は、おそらくSQL Serverなどをお勧めします。あなたがフォローアップのコメントで言及したそれらの他のクエリについては、MonetDBはすばらしいはずです。

たとえば、約200万行のテーブルがある場合、1つの列(範囲内に約800K行あり)と別の列による順序付けができ、制限付きの結果が処理されて返されました25msでこれらのタイプのクエリのパフォーマンスは規模によって低下するようですが、それはあなたがその規模で期待しているものを味わうはずです。

私は楽観的同時実行モデルのみが悲観的同時実行(ほとんどの人)にさらされているものを投げる可能性があることを警告する必要があります。私は、あなたのコミットのいくつかが並行負荷の下でなぜ失敗するのか疑問に思う前にそれを研究したいと思います。

+0

ほとんどのORMがそうしているので、ほとんどの人がOCCモデルに精通していると言えます。一方、ほとんどの人はそれに精通していません(MySQLは独自のサポートはしていませんでした。ほとんどの非エンタープライズWebアプリケーションにはトランザクションがなく、一部のORMSは行/テーブルのロックをサポートしていません)。 –

関連する問題