「大きなデータベース」とは何ですか？

わかりました、私が知っているばかげた質問ですが、「大規模なデータベース」と中小規模のあいまいなコメントが表示され、それが何を意味するのか疑問に思います。誰かが私たちSQL新人にとって小、中、大のデータベースが何であるかを定義できますか？

小さなデータベースが中程度になったり、中規模のデータベースが大きくなったりするしきい値はありません。一般的に、これらの用語を聞くと、保存されているレコードの総数という点で、特定の桁数を思い浮かべます。

• 小：10の⁵または少ないレコード。
• ミディアム：10 ⁵ 10への⁷を記録。
• 大：10 ⁷ 10への^9つのレコードを。
• 非常に大きい：10 ⁹のレコード以上の数。

ポスターdkretzが示唆したように、各種類のデータベースが持つプロパティの観点からも考えることができます。このように分類すると、次のようになります。

• 小：パフォーマンスは問題ではありません。クエリは、特別な最適化を行わなくても正常に実行されます。インデックスなどの最前線の拡張機能を使用した場合、わずかなパフォーマンスの違いしか見られません。

• 中：データベースには、おそらくその保守とケアにパートタイムで割り当てられている1人以上のスタッフがいます。これらの人々はデータベースの状態に注意を払います。彼らの主な管理責任は、許容できないパフォーマンスの問題を防ぎ、ダウンタイムを最小限に抑えることです。

• 大規模：おそらく、データベースでの作業とパフォーマンスの向上を担当する専任のスタッフがいて、アプリケーションの変更によってデータベースの存続期間中にスキーマが破損しないようにします。データベースの状態とステータスに関するメトリックは綿密に監視されます。最適化を理解して実行するには、かなりの専門知識が必要です。

• 非常に大きい：データベースには、すぐにアクセスできる必要がある膨大な量の情報が格納されています。パフォーマンスの最適化は、各クエリから最後の1オンスの速度を引き出すために絶対に必要であり、それがないと、データベースの使用がはるかに少なくなるか、使用できなくなります。データベースは、洗練された、または革新的なレプリケーションまたはクラスタリング技術を使用しており、現在のテクノロジーの限界を押し広げている可能性があります。

これらは完全に主観的なものであり、誰かが「大」の完全に正当な代替定義を持っている可能性があることに注意してください。

それを理解する1つの方法は、テストクエリを観察することです。

小さなデータベースは、インデックスが重要ではないデータベースです。

中規模データベースとは、適切なインデックスが設定されていない場合にクエリに1秒以上かかるデータベースです。

大きなデータベースとは、クエリの設計、インデックスの変更、および多くのテストサイクルを組み合わせて使用​​することで、クエリの最適化に数時間かかることが多いデータベースです。

大規模なデータベースとは、リレーショナルデータベースの使用をやめなければならないデータベースです。

言い換えると、大量のJOINがあるため、世界中のすべてのインデックスが応答時間の要件を満たすのに役立たない、正規化されたリレーショナルデータベースです。

他の目的でリレーショナルデータベースを放棄しなければならなかった場合は、データベース開発者が貧弱であるか、専門家のDBAがいないか、データベースが非常に大きいかのいずれかです。

「大規模データベース」は確かに曖昧な概念です。この質問への回答には、すでに非常に異なる回答や意見が投稿されています。「小」、「中」、「大」のデータベースを定義するためのいくつかのアプローチは、他のデータベースよりも理にかなっているかもしれませんが、ある時点で、それぞれの定義が正しく、真実で、有効であると思います。

一部の定義は、データベースの設計、プログラミング、使用、保守、および管理にとって重要なさまざまな側面に焦点を当てているため、他の定義よりも理にかなっています。これらのさまざまな側面は​​、使用可能なデータベースにとって本当に重要です。これらすべての側面が、「データベースサイズ」というあいまいな概念の影響を受けることがあります。

それで、これは、特定のデータベースが大きいかどうかを定義できるかどうかは問題ではないことを意味しますか？

確かにそうではありません。つまり、データベースのさまざまな設計/運用/管理の側面を評価しながら、概念をさまざまに適用します。それはまた、この概念が曖昧になるたびに意味します。

例：データベースインデックス戦略（データベース設計の側面）は、各テーブルのレコード数（「サイズ」の測定値）、レコードサイズ×レコード数（「サイズ」の別の測定値）、およびクエリ対の影響を受けます。 。作成/更新/削除操作の比率（データベース使用の側面）。

大量のレコードを含むテーブルにインデックスを使用すると、クエリの応答時間が短縮されます。WHERE、ORDER BY、およびrecord-aggregation句の性質によっては、特定のテーブルに複数のインデックスが必要になる場合があります。

作成、更新、および削除操作は、影響を受けるテーブルのインデックス数の増加によって悪影響を受けます。影響を受けるテーブルのインデックスが増えると、RDBMSが実行する必要のある変更が増え、それらの変更を適用するためにより多くの時間とリソースが費やされます。

また、RDBMSがこれらの変更を適用するためにより多くの時間を費やす場合、ロックはより長い時間維持され、他のクエリが同時にシステムに送信される応答時間に影響を与えます。

では、インデックスの量とデザインのバランスをどのように取っていますか？追加のインデックスが必要かどうか、またそのインデックスを追加することでクエリの応答時間に大きな悪影響がないかどうかをどのように判断しますか？回答：負荷/パフォーマンス要件に従ってデータベースをターゲット負荷に対してテストおよびプロファイリングし、プロファイリングデータを分析して、さらに最適化/再設計/インデックスが必要かどうかを検出します。

クエリとクエリごとに異なるインデックス戦略が必要です。作成/更新/削除の稼働率。データベースに大量のクエリがあり、更新されることはめったにない場合は、クエリの応答時間を改善するすべてのインデックスを追加すると、アプリケーション全体のパフォーマンスが向上します。一方、データベースが絶えず更新されているが、大規模なクエリ操作がない場合は、使用するインデックスの数を減らすとパフォーマンスが向上します。

もちろん、他の側面もあります：データベーススキーマ設計、ストレージ戦略、ネットワーク設計、バックアップ戦略、ストアドプロシージャ/トリガー/その他。プログラミング、アプリケーションプログラミング（データベースに対する）など。これらすべての側面は、「サイズ」の明確な概念（レコードサイズ、レコード数、インデックスサイズ、インデックス数、スキーマ設計、ストレージサイズなど）によって異なる影響を受けます。

このトピックは魅力的であるため、もっと時間をかけたいと思います。この小さな貢献が、この魅力的なSQLの世界での出発点となることを願っています。

この定義では、ハードウェアの進歩を考慮する必要があります。

1. 小さなデータベース：ワーキングセットは単一のコモディティサーバーの物理RAMに収まります（現在は約16GB）

2. 中規模データベース：単一のマシン上の単一または複数の（RAIDを介した）コモディティハードドライブに適合します（現在は最大数TB）

3. 大規模なデータベース：データを収めるには、複数のコモディティサーバーにデータを分散させる必要があります（現在は最大数PB）。

非常に大規模なデータベースに関するウィキペディアの記事によると

非常に大きなデータベース（VLDB）は、非常に多数のタプル（データベース行）を含むデータベース、または非常に大きな物理ファイルシステムストレージスペースを占有するデータベースです。VLDBの最も一般的な定義は、1テラバイトを超えるか、数十億行を含むデータベースですが、当然、この定義は時間の経過とともに変化します。

開発ボックスやテストボックスに配置するために「バックアップ」するだけでは不十分なほど大きなデータベースがある場合は、「大きなデータベース」を持っている可能性があります。

ウィキペディアや米国国勢調査データのようなものは「大きな」データベースだと思います。私の個人の住所リストややることは小さなデータベースです。中規模のデータベースはその中間にあります。

必要なサーバーの数によってサイズを定義してみることができます。小さなデータベースはデスクトップで実行するアプリケーションのコンポーネントであり、中規模のデータベースはどこかにある単一のmysql（何でも）サーバーであり、大きなデータベースは何らかのレプリケーション/フェイルオーバーをサポートする複数のサーバーを必要とします。