これは長い間私の頭の中にある質問の1つです。Facebookや1億人以上のユーザーがいるそのようなウェブサイト/アプリはどのようにデータベースを維持していますか？
すべてを1つのデータベースにまとめることはできないと思います。この場合、異なるセクションを処理する複数のデータベースが必要ですか？次のようなさまざまなセクション：ステータス用のデータベース、写真用のデータベース、ユーザー用のデータベース…</ p>
データベーススキーマをリレーショナルにすることはできますか？
5億人以上のユーザーが増えており、平均して1人のユーザーが10のテキスト更新、50億行（少なくとも）を持っている場合、これはFacebookが実際に処理するデータの10％になるはずです。
Facebookには1800以上のSQLインスタンスがあり、そのうち800以上がmemcachedであるとどこかで読んだことがあります。これらのDBインスタンスは同一である必要がありますか？これらはどのように設計されますか？
巨大なデータベースを持つFacebookやその他の大企業は、データベースのパーティション分割を採用しています。
パーティショニングとは、読み取り/書き込みパフォーマンスを向上させるために、異なるデータベースまたはサーバーに存在する可能性のある複数のサブテーブルにテーブルを分散することです。SQL Serverのパーティション分割は通常、テーブルレベルで行われ、関連するテーブルのグループが分散されている場合、データベースはパーティション分割されていると見なされます。テーブルは通常、水平または垂直に分割されます。
水平分割（シャーディングとも呼ばれます）により、全体的な読み取り/書き込みパフォーマンスが向上します
水平分割には、さまざまな行をさまざまなテーブルに配置することが含まれます。おそらく、郵便番号が50000未満の顧客はCustomersEastに保存され、郵便番号が50000以上の顧客はCustomersWestに保存されます。2つのパーティションテーブルはCustomersEastとCustomersWestですが、すべての顧客の完全なビューを提供するために、両方の上にユニオン付きのビューが作成される場合があります。
水平分割はデータベース設計の原則であり、データベーステーブルの行は、（正規化の場合のように）列ごとに分割されるのではなく、個別に保持されます。各パーティションはシャードの一部を形成し、シャードは個別のデータベースサーバーまたは物理的な場所に配置される場合があります。
このパーティショニングアプローチには多くの利点があります。各テーブルの行の総数が減ります。これによりインデックスサイズが小さくなり、一般的に検索パフォーマンスが向上します。データベースシャードは別々のハードウェアに配置でき、複数のシャードは複数のマシンに配置できます。これにより、データベースを多数のマシンに分散できるようになります。つまり、データベースのパフォーマンスを複数のマシンに分散できるため、パフォーマンスが大幅に向上します。さらに、データベースシャードがデータの実際のセグメンテーションに基づいている場合（たとえば、ヨーロッパの顧客とアメリカの顧客）、適切なシャードメンバーシップを簡単かつ自動的に推測し、関連するシャードのみをクエリできる場合があります。
シャーディングは実際にはこれよりはるかに困難です。これは長い間手作業でコーディングされてきましたが（特に、上記の例のように行に明らかなグループ化がある場合）、これは柔軟性がないことがよくあります。シャーディングのコードサポートを追加するという観点からも、シャーディングする候補を個別に識別するという観点からも、シャーディングを自動的にサポートすることが望まれます。
分散コンピューティングを使用して複数のサーバー間で負荷を分離する場合（パフォーマンスまたは信頼性の理由から）、シャードアプローチも役立つ場合があります。
水平分割と比較したシャード
水平分割は、通常、スキーマとデータベースサーバーの単一インスタンス内で、1つ以上のテーブルを行ごとに分割します。古典的な例のように、最初にインデックスを検索する必要なしに、特定の行がどのテーブルで見つかるかを識別するための明白で堅牢な暗黙の方法があれば、インデックスサイズ（したがって検索の労力）を減らすことで利点が得られる可能性があります'CustomersEast'テーブルと'CustomersWest'テーブルの郵便番号は、それらがどこにあるかをすでに示しています。
シャーディングはこれを超えています。問題のあるテーブルを同じ方法で分割しますが、スキーマの複数のインスタンスにまたがってこれを実行します。明らかな利点は、大きなパーティションテーブルの検索負荷を、同じ論理サーバー上の複数のインデックスだけでなく、複数のサーバー（論理サーバーまたは物理サーバー）に分割できることです。
シャードを複数の分離されたインスタンスに分割するには、単純な水平分割以上のものが必要です。単純なディメンションテーブルを取得するためだけに、データベースのクエリで両方のインスタンスをクエリする必要がある場合、期待されていた効率の向上は失われます。したがって、シャーディングは、パーティショニングを超えて、大きなパーティショニング可能なテーブルをサーバー間で分割し、小さなテーブルはそれらにまとめて複製されます。
これが、シャーディングがシェアードナッシングアーキテクチャに関連している理由でもあります。シャーディングされると、各シャードは完全に別個の論理スキーマインスタンス/物理データベースサーバー/データセンター/大陸に存在できます。他のシャード内の他のパーティション化されていないテーブルへの（シャード間からの）共有アクセスを保持する継続的な必要はありません。
これにより、複数のサーバー間でのレプリケーションが容易になります（単純な水平分割はできません）。また、データセンター間の通信リンクがボトルネックになるアプリケーションの世界的な配布にも役立ちます。
明らかに、スキーマインスタンス間の通知とレプリケーションのメカニズムも必要であるため、パーティション化されていないテーブルは、アプリケーションの要求に応じて厳密に同期されたままになります。これは、シャーディングされたシステムのアーキテクチャにおける複雑な選択です。アプローチは、これらを効果的に読み取り専用にする（更新はまれでバッチ処理される）から、動的に複製されるテーブル（シャーディングの配布の利点の一部を減らすことを犠牲にして）、および多くのオプションにまで及びます。間に。
垂直分割により、データへのアクセスが向上します
垂直に分割されたテーブルでは、列はメインテーブルから削除され、非正規化と呼ばれるプロセスによって子テーブルに配置されます。このタイプのパーティショニングを使用すると、データベースページにより多くの行を収めることができ、テーブルを狭くしてデータアクセスのパフォーマンスを向上させることができます。したがって、1回のI/O操作でより多くの行が返されます。データを垂直方向に分割することにより、非正規化された列を返すために結合に頼らなければならない場合があります。
もちろん、パーティショニングに加えて、データの複数のコピーを利用できるようにするレプリケーションがあります。
リレーショナルデータベーススキーマへの影響
シャーディングはリレーショナルデータベースを破壊します-これは良いことです。シャーディングの背後にある考え方は、特定の基準に基づいてデータを複数のデータベースに分散することです。これは、たとえば主キーである可能性があります。キーが1で始まるすべてのエンティティは、1つのデータベースに移動し、2は別のデータベースに移動します（多くの場合、キーのモジュロ関数が使用されるか、顧客の場所や関数などのビジネスデータに基づくグループになります）。シャーディングにはいくつかの理由があります。主な2つは、クラッシュしたデータベースのパフォーマンスの向上と影響の軽減です。データベースのクラッシュの影響を受けるのは、名前がSで始まる人だけです。
リレーショナルデータベースは、データストレージに関しては数十年にわたって選択されたツールでした。しかし、データを保存するだけではありません。読み取り操作でさえ、いくつかの機能に分割することができます。データベース読み取りクエリには、少なくとも3種類あります。
データグラフ作成クエリ：これらを使用すると、データベース、顧客、住所などからデータを取得できます。
集計クエリ：8月に保存された注文の数、製品カテゴリごとの集計
検索クエリ：ニューヨークに住むすべての顧客を教えてください
シャーディングにより、2番目と3番目のクエリがなくなり、データベースがデータストレージに削減されます。シャードは異なるシステム上の異なるデータベースであるため、システム間でカスタムコードなしでクエリを集約することはできず（クラスターと比較して）、1つのクエリで検索することはできません（複数のクエリのみ–各データベースに1つ）。データベースは、検索と検索が相互にリンクされており、一緒に処理する必要があるという概念につながっています。ほとんどの人は、検索と検索を同じものと考えています。これにより、テクノロジーの開発が妨げられています。Sharding、S3、Dynamo、Memcachedは、最近この認識を変えました。Qi4jの名声からのリッカードはこれを言いました：
エンティティは本当にクールです。インターネットがウェブサイトとGoogleでどのように機能するかのように、ストレージをインデックス作成/クエリから分割することにしました。これにより、非常にシンプルなストレージを実装できるようになります。クエリを処理する必要がないため、作業が非常に簡単になります。
したがって、ストレージと検索は2つの異なるものであり、大規模なWeb関連企業はそれらを異なる方法で処理します。
人々は、ストレージの分割と検索について、しばらくの間話し合っていました。Luceneのような検索エンジンは、データベースからの検索を推進してきました。しかし、主にストアと検索の概念が普及しています。パフォーマンスを向上させ、リスクを低減するためのメカニズムとしてのシャーディングは、多くのWeb企業に移行し、データベースをストレージメカニズムに縮小し、集約（データウェアハウスとレポート）と検索パーツを削除します。それらは、Mondrianのような実際のデータウェアハウスサーバーや、LuceneまたはSesameのようなセマンティックエンジンに基づく検索サービスでより適切に満たすことができます。また、ストレージはリレーショナルデータベースからAmazon Simple DB、JDBM、NoSQLなどのシンプルなストレージに移行する可能性があります。