2

私はかなり高負荷のプロジェクトを持っており、MySQL で約 10M のレコードを実行しており、1 秒あたり約 500 のリクエストに制限されています。データはかなりユニークで、キャッシュ ヒット率はわずか 3% 程度です。各行には約 10 個のフィールドがあり、そのうちの 2 つにインデックスが付けられています。私のクエリの 99% は、リクエストに 2 つのインデックス フィールドを使用しています。

NoSQL を試してみることにしましたが、MongoDB は非常に簡単でした。シンプルなカスタム スクリプトを使用して、データの移動は非常に簡単でした。データベース スキーマはまったく同じままで、同じ 2 つのインデックス フィールドをレプリケートしました。それから試してみることにしましたが、かなりショックを受けました。MongoDB は、クエリへの応答が非常に遅かったのです。応答率は、mysql の 500 と比較して、1 秒あたり 5 から 10 リクエストまでさまざまでした。

なぜこれが起こっているのですか？それは正常ですか？この特定のケース (1,000 万レコード、キャッシュ ヒット率の低い多数の一意の要求) では、MongoDb が Mysql よりも優れていると期待できますか? ポイントを逃したような気がします。

いくつかの仕様で更新

私がテストしていたサーバーは、4GB RAMのクアッドコアxeonです

MySQL テーブルは (フィールド名が変更されました):

  CREATE TABLE `table` (
  `recordid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `var1` varchar(200) DEFAULT NULL,
  `var2` char(32) DEFAULT NULL,
  `var3` bigint(20) unsigned DEFAULT NULL,
  `var4` smallint(5) unsigned DEFAULT NULL,
  `var5` datetime DEFAULT NULL,
  `var6` int(10) unsigned NOT NULL,
  `var7` int(10) unsigned NOT NULL,
  `var8` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`recordid`),
  UNIQUE KEY `recordid_UNIQUE` (`recordid`),
  KEY `keyvar7` (`var7`),
  KEY `keyvar6` (`var6`)

典型的なクエリは次のとおりです: SELECT var2, var4, var5, var6 from table where var7=xxx and var6=yyy

インデックス付きフィールドとインデックスなしフィールドを使用してクエリを比較することにより、MongoDB が同じインデックスを適切に複製したことを手作業で検証しました。

UPDATE2 MongoDB .getIndexes() 応答

  > db.table.getIndexes();
[
    {
        "v" : 1,
        "key" : {
            "_id" : 1
        },
        "ns" : "table.table",
        "name" : "_id_"
    },
    {
        "v" : 1,
        "key" : {
            "var6" : 1
        },
        "ns" : "table.table",
        "name" : "var6_1"
    },
    {
        "v" : 1,
        "key" : {
            "var7" : 1
        },
        "ns" : "table.table",
        "name" : "var7_1"
    }
]
4

4 に答える 4

5

MongoDB は魔法のクエリ アクセラレータではありません。mongo に切り替えたからといって、サイトが 10 倍の負荷に耐えられるわけではありません。

あなたの数字から判断すると、リソースの飽和が起こっていると思われます。MySQL は確かに 500 QPS をはるかに超えて実行できます。

何がボトルネックだったか知っていますか？RAM が必要以上に少なく、ディスクからデータを取得する必要があり、ディスクが飽和状態になることは間違いありません。この時点で、より多くの鉄を取得する (またはデータを削除する) 場合を除き、DB 技術は役に立ちません。

mongo のパフォーマンスの低さについては、詳細がないとわかりません。

于 2012-06-13T20:47:19.413 に答える
1

例のように 2 つの要素に対してクエリを実行する場合は、とで複合インデックスをSELECT var2, var4, var5, var6 from table where var7=xxx and var6=yyy使用します。var7var6

構造が固定されていて、リレーショナル データベースと同じスキーマを使用している場合、多くのメリットが得られるとは思えません。しかし、あなたはそれを悪化させることができるかもしれません;-)

于 2012-06-13T22:10:59.050 に答える
0
  • すべてのインデックスが正しく設定されていますか? 複合インデックスを含む？

  • コレクションは実際にインデックス化されていますか?

    例 Collectionname.indexes ; コレクション名.create_indexes

  • データを分割したり、複数のスレーブを使用して負荷を分散したりできますか?

  • システムにはどれくらいの RAM がありますか?
于 2012-06-13T21:05:47.483 に答える
0

多くの巨大な Web プロジェクトが Facebook などのように mysql に固執していることをよく考えてください。そのため、新しい DB がニーズに関してテストされている限り、それを行うべきではありません。私が最もお勧めするのは、DB の最新のバックアップを取得して mysql に戻り、memcached システムを DB に適応させることです。大量のトラフィックを処理します。

しかしもちろん、プロジェクトのタイプが Web であるか何らかのアプリケーションであるかは指定していません。MongoDB は mysql よりもはるかに遅いです。
移転の詳細をお知らせいただければ、より多くの情報を提供することができます。

于 2012-06-13T20:57:50.547 に答える