1

私のシステムには大きな分析モジュールがあり、そのために vertica を使用する予定です。複数のデータベースを管理しないように、アプリの残りの部分 (ドメインのモデルを含む標準の crud アプリ) でも vertica を使用することを誰かが提案しました。

vertica はこの二重のシナリオに適合しますか?

4

5 に答える 5

4

高頻度の UPDATE は、おそらく Vertica が最も遅れをとっているところです。そのようなデータモデルには使用しないでください。

于 2012-08-12T21:32:38.523 に答える
2

Alec - Vertica に関するあなたのコメントに敬意を表して異議を唱えたいと思います。ロードする前にデータを非正規化またはソートする必要はありません。Vertica は、すべてのデータベースでのデータのロードが最速の記録も保持しています。

また、Vertica は RDBMS と同様に複雑な分析を行うことができないと話しています。Vertica は RDBMS であり、他のどの RDBMS よりも高速に分析を行うことができ、何度もそれを証明しています。

あなたの数字に関する限り、私のユース ケースでは、1 秒あたり約 500 万レコードを Vertica クラスターにロードし、数百億のレコードがあります。

Yaron - この情報に基づいて除外する前に、Vertica を確認することを強くお勧めします。

于 2012-08-24T20:34:09.870 に答える
1

試して。ユースケースはそれぞれ異なります。Verticaがすべてのユースケースのソリューションであると仮定すると、すべてのユースケースでMongoDBを使用するのとほぼ同じくらい悪いです。

Verticaは、列指向の高性能分析データベースであり、非常に大きなデータセットを分析し、水平方向にスケーリングするように設計されています。また、費用がかかり、管理が難しく、ドキュメントが不十分です。適切な環境での見返りは、明らかに作業する価値があります。

MySQLは従来のRDBMSであり、行指向であり、構造化データ間の関係をモデル化するように設計されており、単一ノードスケールで適切に機能します（ただし、多くの企業がそれを大成功に後付けしています、模範的な無償、Facebook）。非常によく文書化されており、あらゆるプラットフォーム、言語、またはフレームワークで機能しているようで、誰でも使用できます。

私の推測では、従業員の名簿データベースにVerticaを使用することは、3000ドルのスーツでブルーカラーの仕事に出くわすようなものです。確かに機能しますが、それは仕事に適したツールですか？おそらく、Verticaライセンスをすでに持っていて、アプリケーションに必要なデータアダプター/ ORM / etc ...がすでにある場合は、先に進んで試してみてください。それはまだSQLデータベースなので、そのような状況では正常に機能するはずです。最適なパフォーマンスではなく最小限のプログラミングが目標である場合、なぜVerticaを使用するのでしょうか。より単純なものがより理想的であるように聞こえます。Verticaは、そのために最適化されていないため、通常のCRUDアプリケーション環境でパフォーマンスが向上する場合とそうでない場合がありますが、いつでも両方をテストして確認できます。

于 2012-11-15T21:05:03.663 に答える
1

最近よくあることですが、意味のある答えは、何をする必要があるかによって異なります。一般的な意味で、「ビッグ データ」ソリューションは、RDBMS システムの大量のデータ ボリュームの不足から成長してきました。RDBMS システムのコア機能、つまり複雑な分析に匹敵する「ビッグデータ」ソリューションはありませんが、RDBMS システムは大量のデータを処理するには貧弱な (高価な) ソリューションです。今のところ実用的なソリューションは、ハイブリッド ソリューションでなければなりません。Vertica は、データがロードされると優れたものになる可能性がありますが、(専門家ではありませんが) 最高のパフォーマンスを発揮するには、データの非正規化とロード前の事前ソートが必要だと思います。大量のデータの場合、これにより必要なリソースが大幅に増加する可能性があります。すべてのニーズに 1 つのシステムを使用することには明確な利点がありますが、オプションをオープンにしておくことにも利点があります。

私が取っているアプローチは、新しいデータを保存してインデックス化し、必要に応じてさまざまなレポート/分析エンジンに特定のフィードを提供することです。これにより、生データの収集と保存が複雑な分析処理から分離されます。ご興味がありましたら、詳細をお知らせいただければ幸いです。この分離は、データベース システムに常に存在するコアの問題に対処します。以前は、「すばやく保存してゆっくり報告するか、ゆっくり保存して早く報告するが、両方を行うことはできない」という言葉をよく耳にしました。ここ数年、完全なソリューションを求めて、通常は「高速保存」タスクに対処する多くの NoSQL 製品が生み出されました。一部のシステムでは、メモリまたはキャッシュにデータを格納することで優れたクエリ パフォーマンスを実現することもできますが、これには大量のデータに対して多数のサーバーが必要になります。NoSQL と SQL ソリューションは統合可能であり、統合されると信じています。

状況を説明するために、1 日あたり少なくとも 10 億件のレコードが読み込まれるシナリオを扱っています。たとえば、1 日に 1 億件のレコードを処理している場合 (大きいのは相対的)、おそらく Vertica のアプローチで十分でしょう。それ以外の場合は、オプションを拡張する必要があると思います。

于 2012-08-13T11:09:04.000 に答える