私はデータベース システム設計の初心者です。多くの記事を読んだ後、シャーディングやパーティション化を行わずに 1 つのテーブルを持つ必要がある制限は何なのか、本当に混乱しました。一般的な答えを提供するのが非常に難しいことは承知しています。物事は
などの要因によって異なります。
- 行サイズ
- データ型 (文字列、BLOB など)
- アクティブなクエリの数
- どのような種類のクエリ
＃＃＃索引＃＃＃
- 再読/再書き込み
- 予想される遅延
-
しかし、誰かがこの質問をすると
10 億のデータと数百万の行が毎日追加されたらどうしますか?このような大規模なデータベースの場合、4 回の読み取り、1 回の書き込み、2 回の更新クエリの待ち時間は 5 ミリ秒未満である必要があります。
- 1,000 万行しかないが、更新量と読み取り量が多い場合、何を選択しますか?追加する新しい行の数は関係ありません。高い一貫性と低い遅延が要件です。
-
行数が 100 万未満で行サイズが数千単位で増加する場合、選択は簡単です。しかし、選択に数百万行または数十億行が含まれる場合、事態はさらに複雑になります。
注: 質問では遅延番号について言及しませんでした。お願いします
許容できる遅延の数に基づいて回答してください。また、構造化データについても話しています。
よくわかりませんが、具体的な質問を 3 つ追加できます:
Amazon またはその他の電子商取引注文管理システム用の SQL データベースを選択するとします。注文数は毎日数百万件ずつ増加しています。すでに10億件のレコードがあります。ここで、データ アーカイブが存在しないと仮定します。 1 秒あたり 1000 クエリを超える大量の読み取りクエリ。そして、また書かれています。読み取り:書き込み比率は 100:1
- より小さな数の例を見てみましょう。 abc 用の SQL データベースまたは任意の電子商取引注文管理システムを選択するとします。注文数は毎日数千件ずつ増加しています。すでに 1,000 万件のレコードがあります。ここで、データ アーカイブが存在しないと仮定します。 1 秒あたり 1 万件を超える大量の読み取りクエリ。そして、また書かれています。読み取り/書き込み比率は 10:1
です。
- 3 番目の例: 景品の配布。 1,000万点のグッズをプレゼントいたします。ユーザー1人につきグッズは1つとなります。高い一貫性と低い遅延が目標です。無料配布を待っているユーザーがすでに 2,000 万人いると仮定すると、時間が開始されると、ユーザー全員が無料グッズを手に入れようとするでしょう。
-
注: この質問全体を通じて、次のことを選択すると想定されています。
SQL ソリューション。また、提供された使用例が論理的に意味をなさない場合は、無視してください。数値的な知識を身につけることが目的です。
ベンチマークが何なのかを理解するのを手伝ってくれる人はいますか?現在取り組んでいるプロジェクトの実数値を見ると、非常に多くのクエリを含む大規模なデータベースで、これが観測される遅延であることがわかります。特定のレイテンシーにおける特定の数のクエリに対する選択テーブルの数を正当化するのに役立つものはすべてあります。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
MySQL に関するいくつかの回答。すべてのデータベースはディスク容量、ネットワーク遅延などの影響を受けるため、他のエンジンも同様である可能性があります。
- 行数に関係なく、「ポイント クエリ」(適切なインデックスを使用して行を取得する) には数ミリ秒かかります。
- 実行に数時間、場合によっては数日かかる
- 「シャーディング」は、単一サーバー上で必要な書き込み回数を維持できない場合に必要です。
- レプリケーションを使用し、読み取りをレプリカに送信することで、大規模な読み取りを「無限に」スケーリングできます。
-
-
- データ ウェアハウス アプリケーションの場合、大規模なパフォーマンスを実現するには「概要テーブル」の構築と維持が重要です。 (他のエンジンにはいくつかの組み込みツールがあります。)
-
ネットワーク遅延は主にクライアントとサーバー間の距離に依存します。地球の裏側に到達するには200ミリ秒以上かかります。一方、クライアントとサーバーが同じ建物内にある場合、遅延は 1 ミリ秒未満になります。一方、クエリの実行にかかる時間について言及している場合は、次のような経験則があります: HDD ディスクにアクセスする必要がある単純なクエリの場合は 10 ミリ秒、SSD の場合は 1 ミリ秒です。 -
UUID とハッシュは、データが大きすぎて RAM にキャッシュできない場合、パフォーマンスに非常に悪影響を及ぼします。 -
私は読み取りと書き込みを独立して判断したいため、読み取り/書き込みの比率については言及しませんでした。 -
「1 秒あたり 10,000 回の読み取り」を達成するのは困難です。実際にこれを必要とするアプリケーションはほとんどないと思います。あるいは、同じ目標を達成するためのより良い方法を見つけることもできます。ユーザーはどれくらい早くクエリを発行できますか?もしかしたら1秒に1本くらいでしょうか？同時に接続してアクティブにできるユーザーは何人ですか?何百も。 -
(私の意見) ほとんどのベンチマークは役に立ちません。ベンチマークによっては、あるシステムが別のシステムの 2 倍高速であることが示される場合があります。だから何？一部のベンチマークでは、数百を超える - active 接続がある場合、スループットが低下し、遅延が無限大になる傾向があることが示されています。だから何。アプリケーションをしばらく実行した後に actual クエリをキャプチャすることが、おそらく最良のベースラインです。しかし、その用途はまだ限られています。
ほとんどの場合、分割テーブル (複数のテーブル、パーティション、シャード) よりも単一のテーブルの方が優れています。具体的な例があれば、テーブル設計の長所と短所について話し合うことができます。 -
行のサイズとデータ型 - 大きな列 (TEXT/BLOB/JSON) は「ログに記録されずに」保存されるため、追加のディスク ヒットが発生する可能性があります。ディスク ヒットは、クエリの中で最もコストがかかる部分です。 -
アクティブなクエリ - 数十回実行すると、クエリが互いに競合します。 (食料品店を想像してください。たくさんの買い物客がショッピング カートを押しています。「多すぎる」買い物客で、全員が買い物を終えるまでに長い時間がかかっています。) -
大規模なデータベースにはいくつかの異なるタイプがあり、それぞれにいくつかの異なる特性があります。SELECTを作成することも可能です。したがって、クエリがこのように病的であるかどうかを理解する必要があります。 (これは「遅延」が大きい例だと思います。)PARTITIONing(特に MySQL では) の用途はほとんどありません。詳細: パーティションINDEXはパフォーマンスにとって非常に重要です。1 日に100 万行を挿入しても問題はありません。 (もちろん、一部のスキーマ設計によってはこの問題が発生する可能性があります。) 経験則: 100/秒は問題ないかもしれませんが、1000/秒は可能かもしれませんが、それを超えると難しくなります。 #高速取り込みの詳細SPATIAL、または何らかのテクニックが必要です ここで