Q：
Facebookは、スケーリングがうまくいかないことを知ってMySQLを使用します（または、ここに特別な魔法がありますか？）。 MySQLを選択した理由は何ですか？ JOINは使用しますか？ また、別のデータベースに切り替える予定はありますか？
A：
Facebookの元CTOであるAdam D'Angeloは、現在、スタートアップQuoraを開発しています。
- アプリケーションレベルでデータを異なるサーバーに分割する場合、MySQLのスケーラビリティはそれほど大きな問題ではありません。 2008年のFacebook [1]では、1800個のMySQLサーバーがあり、2人の管理者のみが必要でした。 もちろん、異なるサーバーからのデータを使用してJOINを作成することはできませんが、NoSQLデータベースではこれもできません。 FacebookがメインリポジトリとしてCassandraを使用しているという証拠はなく、そこに必要な唯一の理由は、受信メッセージを検索することです。 [2]
- 実際、Cassandra、MongoDB、CouchDB [3]のような分散データベースは 、あまりスケーラブルでも安定でもありません。 たとえば、Twitterの連中は1年にわたってMySQLからCassandrに切り替えようとしてきました。 もちろん、誰かがこれらのデータベースのいずれかを年間1000台の車の主記憶装置としてどのように使用したかについて話すならば、私は気が変わります。
- 新しいテクノロジーのコアベースを危険にさらすのは悪い考えです。 ベースを失ったり台無しにしたりすることは災害であり、すべてを復元することはできないかもしれません。 さらに、これらの新しいデータベースの開発者ではなく、戦闘モードでそれらを使用する数少ないデータベースの1つでもない場合は、開発者がエラーやスケーラビリティの問題を修正できるようになります。
- 実際、アプリケーションレベルでデータを分割することを心配することなく、単一のMySQLを使用することができます。 サーバーを大量のコアと大量のRAMに簡単に「スケーリング」できます。レプリケーションを忘れないでください。 さらに、サーバーにmemchachedレイヤー（単純にスケーリングする）がある場合、データベースが行うことは新しいデータの書き込みだけです。 また、大きなオブジェクトを保存するには、S3またはその他の分散ハッシュテーブルを使用できます。 そのため、ベースの成長に応じてベースをスケーリングできることは確かですが、データベースを本当に必要な規模以上にスケーラブルにするという負担を負う必要はありません。
- ほとんどの問題は、自分で多数のサーバーにデータを分割しようとすると発生します。 ただし、ベースの間に中間層を使用することができます。この中間層は、実際にはFriendFeedで行われたこの種の分割の原因となります。 [4]
- リレーショナルモデルは、ユーザーがコンテンツを作成するほとんどのアプリケーションでデータを構造化する正しい方法だと思います。 スキームを使用すると、サービスの新しいバージョンが開発されるときに特定の形式でデータを含めることができます。また、ドキュメントとして機能し、エラーの山を避けるのに役立ちます。 SQLでは、大量の生の情報を受け取るのではなく、必要に応じてデータを処理することもできます。生の情報は、アプリケーションでさらに処理する必要があります。 だれかが最終的に自由なセマンティクスを備えた分散リレーショナルデータベースを開発すると、NoSQLを取り巻くすべての誇大広告はすぐに終わると思います。
参照：
[1] Facebookで10,000個のWebサーバーを実行中
[2] 現在Facebookのどの部分がCassandraを使用していますか？
[3] CouchDBは理論上だけでなく、実際にはどれだけスケーラブルですか？
[4] FriendFeedがMySQLを使用してスキーマレスデータを保存する方法