0

次のオプションを検討しています。

  1. senseidb [http://www.senseidb.com] これには固定スキーマとデータ ゲートウェイが必要です。そのため、データをプッシュする簡単な方法はありませんが、データ ストリームを提供します。データが構造化されておらず、あらゆる種類のログに共通する属性がほとんどない

  2. riak[http://wiki.basho.com/Riak-Search.html]

  3. vertica - コスト要因?

  4. Hbase(+Hadoop エコシステム +lucene) - ここでの主な短所は単一のマシン上にあり、これはあまり意味がなく、これを中心に構築されるフリーテキスト検索機能については確信が持てません

主な要件は次のとおりです。 1. アーカイブのために何千もの着信要求を維持すると同時に、エンド ユーザーがフリーテキスト検索を実行できるようにするリアルタイム インデックスを構築する必要があります。

  1. ストレージ (ログ アーカイブ + インデックス) は最適化する必要があります
4

3 に答える 3

1

特殊なログ ストレージとインデックス作成が多数ありますが、必ずしもログを通常のデータ ストアに詰め込む必要があるかどうかはわかりません。

多額の資金を持っている場合、Splunkを打ち負かすのは困難です。

オープン ソースのオプションを希望する場合は、ServerFault のディスカッションを参照してください。logstash + ElasticSearch は非常に有力な選択肢のようで、ログと同様にかなり大きくなるはずです。

于 2012-07-19T06:19:30.290 に答える
0

2 ～ 3 TB のデータは、「中間」のケースのように聞こえます。それがすべてのデータである場合、BigData / NoSQL ベンチャーに参入することはお勧めしません。
全文検索機能を備えた RDBMS は、優れたハードウェアで実行する必要があると思います。2 ～ 3 TB のデータを処理できるように、時間をかけて積極的にパーティショニングを行うことをお勧めします。パーティショニングがなければ、あまりにも多くなります。同時に、データが日ごとに分割される場合、MySQL のデータ サイズは問題ないと思います。
以下のコメントを考慮すると、データ サイズは約 10 ～ 15 TB であり、レプリケーションの必要性を考慮すると、この数は x2 ～ x3 になります。また、データサイズから数十パーセントと見積もるインデックスのサイズも考慮する必要があります。おそらく効率的な単一ノード ソリューションは、主にライセンス コストが原因で、クラスタリングよりも高価になる可能性があります。
私の理解では、既存の Hadoop/NoSQL ソリューションは、ほとんどの場合、インデックスを作成するドキュメントの数が原因で、すぐに要件を満たすことができません。場合によっては、各ログはドキュメントです。(http://blog.mgm-tp.com/2010/06/hadoop-log-management-part3/)
ということで、一定期間のログをまとめてまとめて、1 つのドキュメントとして威嚇することが解決策になると思います。
これらのログ パッケージの保存には、HDFS または Swift が適切なソリューションになる可能性があります。

于 2012-07-06T08:02:11.220 に答える
0

これらの実装について考えたことはありますか。問題を解決するには、Lucene と Hadoop を統合すると役立つ場合があります。

http://www.cloudera.com/blog/2011/09/hadoop-for-archiving-email/ http://www.cloudera.com/blog/2012/01/hadoop-for-archiving-email-part- 2/

そのため、メールの代わりに、ユース ケースでログ ファイルとパラメーターを使用してインデックスを作成できます。

于 2012-07-04T18:12:27.937 に答える