2

私はJava開発者です。Javaを使用して巨大なデータをmysqlに保存するための最良の方法を知りたいです。

巨大：毎秒20万のトークメッセージ。

ここではインデックスは必要ありません

ユーザーがメッセージを作成したらすぐにデータベースにメッセージを保存する必要がありますか？遅すぎますか？

4

5 に答える 5

1

私の提案もMongoDBです。NoSQLパラダイムは、ニーズに完全に適合しているためです。以下はJavaでのMongoDBのフレーバーです-

BasicDBObject document = new BasicDBObject();
document.put("database", "mkyongDB");
document.put("table", "hosting");

BasicDBObject documentDetail = new BasicDBObject();
documentDetail.put("records", "99");
documentDetail.put("index", "vps_index1");
documentDetail.put("active", "true");

document.put("detail", documentDetail);

collection.insert(document);

このチュートリアルは、始めるのに役立ちます。MongoDBはgithubからダウンロードできます。

MongoDBの最適化については、この投稿を参照してください。

于 2012-07-24T02:52:08.787 に答える
1

1日あたり10億回の書き込みは、約12,000/秒です。各メッセージが約16バイトであると仮定すると、これは約200k/秒です。読み取りを気にしない場合は、このレートでディスクに簡単に書き込むことができます。おそらく1行に1つのメッセージです。読み取りアクセスパターンによって、ここで何をする必要があるかが決まる可能性があります。

MySQLを使用している場合は、可能であれば、行ごとに複数のメッセージを組み合わせることをお勧めします。テーブルをパーティション化すると、ワーキングセットをメモリに保持するのに役立ちます。トランザクションごとに、おそらく1000行のレコード数をコミットする必要があります。テストと調整を行う必要があります。このページが役立ちます。

http://dev.mysql.com/doc/refman/5.0/en/insert-speed.html

おそらく、大量の書き込みワークロードを念頭に置いて作成され たCassandraも確認する必要があります。

于 2012-07-24T02:30:47.090 に答える
0

MySQLを絶対に使用する必要がありますか、それとも他のDBも利用できますか？MongoDbまたはCouchDBは、この種のニーズに最適です。他のDBオプションを利用できる場合は、それらを確認してください。

MySqlを完全に使用する必要がある場合は、関連するすべてのテキストメッセージが単一のjsonとして子に送信されるのと同様の処理を実行しました。毎回追加し、マスターを別のテーブルに保持します。したがって、最小で1つのマスターレコードと1つの子レコード、およびメッセージが特定の数（このシナリオでは30）を超えると、より多くの子レコードが実装され、30以上を保持する2番目の子レコードにクエリを実行します。

お役に立てれば。

参考までに、他のいくつかの理由とニーズのためにCouchDBに移行しています。

于 2012-07-24T01:20:27.173 に答える
0

この問題には、少なくとも2つの異なる部分があります。

  1. データベースに保存するためのメッセージの処理

  2. メッセージに使用するストレージの種類

メッセージを処理するには、水平方向にスケーラブルなシステムが必要になる可能性があります（つまり、メッセージをすばやく処理するためにマシンを追加できます）。これにより、大量のメッセージのバックログが蓄積されなくなります。これらのメッセージを同期的に書き込もうとしないでください。メッセージを受信したら、データベースに書き込むために処理するキューに入れてください（ここでは、JMSのようなものが思い浮かびます）。

データストレージに関しては、MySQLはリレーショナルデータベースですが、大量のデータを保存するだけでなく、実際にリレーショナルデータ処理を行っているようには思えません。MongoDB、Cassandra、CouchDBなどのNoSQLデータベース（他の人もここで提案しているように）を調べることをお勧めします。それぞれに長所と短所があります（それぞれのWebサイトや他の場所でそれぞれの詳細を読むことができます）インターネット）。

于 2012-07-24T02:44:11.120 に答える
0

通常のアクセスでは、少なくとも1つのチャットセッションのすべてのテキストを取得する必要があります。

行数が多く、データはそれほどリレーショナルではありません。これは、非リレーショナルデータベースに適しています。

それでもMySQLを使用したい場合は、パーティションを使用してください。書き込み中はバッチ挿入を使用し、読み取り中はクエリに十分なパーティションプルーニングヒントを提供します。EXPLAIN PARTITIONSパーティションがプルーニングされているかどうかを確認するために使用します。この場合、1つのチャットセッションのチャットラインを1つの行に結合することを強くお勧めします。これにより、行ごとに1つのチャット回線と比較して、行数が大幅に削減されます。

保存するデータの日数については言及していません。

別のメモ：1秒あたり20万件のメッセージを要求するには、ユーザーの観点からアプリがどの程度成功する必要がありますか？アクティブなチャットセッションでは、1人のユーザーから5秒ごとに約1つのメッセージが生成される場合があります。計算を簡単にするために、1秒にします。つまり、20万人のオンラインユーザーの能力を構築しているのです。これは、少なくとも数百万人のユーザーがいることを意味します。

スケールを早く考えるのは良いことです。ただし、エンジニアリングの努力が必要です。また、リソースには限りがあるため、タスク（パフォーマンス/ UXなど）ごとに慎重に割り当ててください。たとえば、UXにより多くの時間を費やすと、ROIが向上する可能性があります。数百万のユーザー領域に到達すると、新しい扉が開きます。あなたはエンジェルまたはVCによって資金提供されているかもしれません。それを持っているのは良い問題だと考えてください。

私の2セント。

于 2012-07-24T04:46:01.627 に答える