Pull to refresh

Масштабируемость реляционных БД

MySQL *
Translation
Original author: Adam D'Angelo

Q:


В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?


A:


Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:
  1. Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]
  2. В действительности, распределенные базы данных вроде Cassandra, MongoDB и CouchDB [3] не очень-то масштабируемы или стабильны. Например, парни из Твиттера пытаются перейти с MySQL'а на Cassandr'у целый год. Конечно, если кто-то расскажет про то, как он использовал любую из этих БД как основное хранилище на 1000 машин в течении года, то я изменю свое мнение.
  3. Плохая идея рисковать свой основной базой ради новой технологии. Это будет катастрофа потерять или испортить базу, причем у вас может и не быть возможности все восстановить. К тому же, если вы не разработчик одной из этих новомодных баз данных и один из тех немногих использующих их в боевом режиме, то вам остается только молиться, что разработчик будет исправлять ошибки и проблемы с масштабируемостью по мере их появления.
  4. В действительности, можно очень далеко уйти на одном MySQL совсем не заботясь о разбиение данных на уровне приложения. Можно легко «отмасштабировать» сервер на кучу ядер и тонны оперативки, ну и не надо забывать про репликацию. К тому же, если перед сервером стоит слой из memchached (который просто масштабируется), то единственное, что делает ваша БД это пишет новые данные. А для хранения больших объектов можно использовать S3 или любую другую распределенную хеш-таблицу. По этому пока вы уверены, что сможете масштабировать базу по мере роста, не нужно взваливать на себя ношу сделать БД масштабируемой еще на порядок больше, чем это действительно нужно.
  5. Большинство проблем возникает в том случае, когда вы пытаетесь разбить данные по большому числу серверов самостоятельно. Но можно использовать промежуточный слой между базой, который отвечает за такого рода разбиение, что, собственно, и сделали во FriendFeed. [4]
  6. Я верю, что реляционная модель это правильный способ структурирования данных в большинстве приложений, контент в которых создают пользователи. Схемы позволяют содержать данные в определенном виде по мере разработки новых версий сервиса, они же служат документацией и позволяют избежать кучи ошибок. Еще 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
Tags:
Hubs:
Total votes 78: ↑74 and ↓4 +70
Views 9.1K
Comments Comments 34