Q:
В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?
A:
Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:
- Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]
- В действительности, распределенные базы данных вроде Cassandra, MongoDB и CouchDB [3] не очень-то масштабируемы или стабильны. Например, парни из Твиттера пытаются перейти с MySQL'а на Cassandr'у целый год. Конечно, если кто-то расскажет про то, как он использовал любую из этих БД как основное хранилище на 1000 машин в течении года, то я изменю свое мнение.
- Плохая идея рисковать свой основной базой ради новой технологии. Это будет катастрофа потерять или испортить базу, причем у вас может и не быть возможности все восстановить. К тому же, если вы не разработчик одной из этих новомодных баз данных и один из тех немногих использующих их в боевом режиме, то вам остается только молиться, что разработчик будет исправлять ошибки и проблемы с масштабируемостью по мере их появления.
- В действительности, можно очень далеко уйти на одном MySQL совсем не заботясь о разбиение данных на уровне приложения. Можно легко «отмасштабировать» сервер на кучу ядер и тонны оперативки, ну и не надо забывать про репликацию. К тому же, если перед сервером стоит слой из memchached (который просто масштабируется), то единственное, что делает ваша БД это пишет новые данные. А для хранения больших объектов можно использовать S3 или любую другую распределенную хеш-таблицу. По этому пока вы уверены, что сможете масштабировать базу по мере роста, не нужно взваливать на себя ношу сделать БД масштабируемой еще на порядок больше, чем это действительно нужно.
- Большинство проблем возникает в том случае, когда вы пытаетесь разбить данные по большому числу серверов самостоятельно. Но можно использовать промежуточный слой между базой, который отвечает за такого рода разбиение, что, собственно, и сделали во FriendFeed. [4]
- Я верю, что реляционная модель это правильный способ структурирования данных в большинстве приложений, контент в которых создают пользователи. Схемы позволяют содержать данные в определенном виде по мере разработки новых версий сервиса, они же служат документацией и позволяют избежать кучи ошибок. Еще SQL позволяет обработать данные по необходимости, а не получать тонны сырой информации, которую потом еще нужно дополнительно обрабатывать в приложении. Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.
Ссылки:
[1] Facebook Now Running 10,000 Web Servers
[2] What portions of Facebook use Cassandra today?
[3] How scalable is CouchDB in practice, not just in theory?
[4] How FriendFeed uses MySQL to store schema-less data
