Mongodb にはオートシャーディングが付属しているので、テーブルを 1 億を超えるレベルのテーブルに分割する必要がありますか?
给我你的怀抱2017-05-02 09:28:37
まあ、この回答は読者を誤解させるものであるため、私はそれに反対票を投じました。
データベースの種類に関係なく、インデックスの作成には膨大なコストがかかります。これはテーブル全体のデータを走査することを意味するためです。大きな負担をかけずにインデックスを作成するにはどうすればよいでしょうか?そのため、この状況を適切に軽減できる {background: true} オプションがあります。負荷が高すぎるクラスターでインデックスを作成する場合は、オンライン システムの動作への影響を避けるために、ノードを 1 つずつ削除してインデックスを作成し、オンラインに置く「ローリング」インデックス作成方法を使用することをお勧めします。 。
ロックの問題に関しては、3.0 以降、WT エンジンはドキュメント ロック (行ロック) をサポートします。
インデックスのクエリにかかるコストが膨大になるのは、おそらくインデックスが適切に確立されていないためです。具体的な例を挙げて説明します。
データが1億件を超える場合、落とし穴が多いかどうかを具体例を挙げて議論してください。
天蓬老师2017-05-02 09:28:37
Mongodb は自動シャーディングおよびパーティショニング アーキテクチャをサポートしており、これを使用して水平方向に拡張されたデータベース クラスター システムを構築し、各シャーディング ノードにデータベース テーブルを保存できます。
データベースシャーディングの代わりにmongodbシャーディングを参照してください[1]: https://yq.aliyun.com/article...
给我你的怀抱2017-05-02 09:28:37
テーブルは月ごとに分割できます。 Name_03 Name_04 名前は変更されません。クエリ対象のテーブルの名前はプログラム内のタイムスタンプに従って動的に変更されます。
PHPz2017-05-02 09:28:37
MongoDB には、データベースのロック (低バージョン) とテーブルのロック (中バージョン) という問題があり、ファイルを保存するためのシャードが存在する場合でも、インデックス作成とインデックス クエリのオーバーヘッドが依然として大きいと思います。 ！ ！ ！ ！データが 1 億を超えると、まだまだ落とし穴がたくさんあります。