0

MySQL DB には非常に大きなテーブル (3 つのテーブル、それぞれ 2 ~ 5 GB) はほとんどありません。ルート、スケジュール、容量、場所、価格ルールなどのエンティティを組み合わせる物流アプリケーションを実行しています。これらの巨大なテーブルには、言及されたエンティティからの「結合」データが含まれています。

実行中に JOINS を実行するとパフォーマンスが完全に低下するため、これらのテーブルが必要です。インデックス、キャッシング メカニズム、効率的な準備済みステートメント、適切なトランザクション管理セットアップがありますが、パフォーマンスは十分ではありません (～数千の顧客、～数百または VIP の顧客)。

私たちの顧客は、接続、スケジュール、価格の検索など、ほとんど99% の読み取り専用操作を行っています。その後、 1 ～ 2% の UPDATE/INSERT 操作が行われることがあります。たとえば、旅行や定員の予約などです。

私たちの考えは、SQL を使用しない DB (おそらく MongoDB) を 2 番目のデータベースとして使用し、事前に生成されたすべての読み取り専用データをいくつかのキー値またはツリー構造に配置することです。パフォーマンスが大幅に向上すると信じていますが、このソリューションの注意点は何ですか? そのような仕事について個人的な経験はありますか?

高速プロトタイプを作成する予定ですが、実際に NoSQL を実際に使用した経験はありません。

4

2 に答える 2

2

皆さんは、memcache の kv 構造に精通しているはずですよね? あなたのチームにとって、NoSQL はストレージを備えた memcache と考えることができます。memcache を使用して、データを NoSQL に再構築できます。

そうすれば、すべてが簡単になることがわかります。

一言で言えば、高度な機能を無視して、最初の一歩を踏み出してください。

于 2012-09-11T05:57:33.577 に答える
1

データモデルに多数の結合データがある場合、MongoDBは結合をサポートしていないため、間違いなく正しい選択ではありません。データモデルについてはあまり語っていませんが、ほとんどのデータが他のエンティティに埋め込まれ、個別のコレクションに格納されない方法で変換できる場合は、MongoDBが機能します。シャーディングとレプリカセットのおかげで、特に書き込みアクセスの場合、非常に適切に拡張できます。

または、Memcachedを使用して3つの巨大なテーブルをキャッシュすることを検討しましたか？3 x 5 GB =15GB-サーバーがメモリに保持するのはそれほど多くありません。

于 2012-09-11T08:15:35.000 に答える