非常に大きなテーブルを構成する方法

Question

これは概念的な質問です。それは、単純なクエリでさえ長い時間（適切に索引付けされる）を必要とする非常に大きなテーブルを使用することに触発されています。私はテーブルが成長し続けるより良い構造があるのだろうかと思っていました。

大きいとは、毎日10,000以上のようなものによって毎日成長する10,000,000件以上のレコードを意味します。このようなテーブルは、2.7年ごとに10,000,000の追加レコードを記録します。最近の記録は最もアクセスが多いが、古いものは利用可能である必要があると言いましょう。 私はそれをスピードアップするための2つの概念的なアイデアを持っています。

1）すべてのデータを保持するマスター表を、日付順に逆順に保持します。その年のデータのみを保持する年ごとに別々のビューを作成します。次に、クエリを実行して、クエリが3年のスパンからわずかなレコードのみを取得すると予想される場合、私は3つのビューを結合してそれらを選択するためにユニオンを使用できます。

2）別のオプションは、毎年別のテーブルを作成することです。その後、再びユニオンを使用してクエリを結合します。

誰にも他のアイデアや概念はありますか？私はこれがFacebookが直面している問題だと知っています。だからあなたはどうやってそれを扱ったと思いますか？私は100,000,000,000レコードを含む単一のテーブル（status_updates）を持っているのではないかと思います。

Answer 1

主RDBMSプロバイダは全て同様のパーティションテーブルとパーティションビューの観点から概念（ならびに両者の組み合わせ）を有する

データは、現在複数の概念テーブルにまたがって分割されるの一方の即時の利点は、ありますしたがって、クエリ内のパーティションキーを含むクエリは、キーが存在しないパーティションを自動的に無視することができます。

RDBMS管理の観点から、データを別々のパーティションに分割すると、パーティションバックアップ/リストア/インデックス作成などを行うことができます。これにより、停止時間を短縮するだけでなく、全体を削除するだけで、はるかに高速なアーカイブを可能にします一度に1つのパーティションに分割します。

nosql、map reduceなどの非リレーショナル・ストレージ・メカニズムもありますが、最終的にどのように使用され、ロードされ、データがアーカイブされるのかは、使用する構造の決定の原動力になります。

大規模なシステムの規模では1000万行はそれほど大きくはありません。パーティション化されたシステムは、数十億行を保持できます。

Answer 2

多くの場合、1つのテーブルを作成してデータベース分割を使用することをお勧めします。

または、アーカイブされたデータと結合されたデータのアーカイブを作成し、ほとんどの機能が参照しているテーブル内のアクティブなデータのみを保持することができます。あなたは良いアーカイブ状態を持っている必要があります（それは自動化されています）、データを失うか、物事を効率的に動かすことができません。これは通常、維持することがより困難です。

Answer 3

2番目のアイデアは、パーティション化のようです。

私はそれがどのように動作するかよくわからないが、パーティションのサポートは、MySQLであり - そのマニュアルには、以下を参照してください。Chapter 17. Partitioning

Answer 4

をあなたが何を言ってるのか、水平パーティショニングやshardingです。

Answer 5

この表にはスケーラビリティに優れたアプローチがあります。連合は正しい方法ですが、よりよい方法があります。

データベースエンジンが「セマンティカルパーティショニング」をサポートしている場合、1つのテーブルを複数のパーティションに分割できます。各パーティションは、ある程度の部分範囲（1年に1つのパーティション）をカバーします。 DDLを除き、SQL構文の何にも影響しません。そして、エンジンは隠された組合論理とそれが持っているすべての並列ハードウェア（CPU、I/O、ストレージ）でパーティション化されたインデックススキャンを透過的に実行します。

たとえば、Sybaseは、結合の制限であるため、最大255個のパーティションを許可します。しかし、クエリではキーワード "共用体"は必要ありません。