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

Original author: Adam D'Angelo
  • Translation

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
Share post

Comments 34

  • UFO just landed and posted this here
      +6
      Дядька Адам говорит, что в общем-то он и сам не знает, какой она должна быть для распределенных RDBMS, но предполагает, что операции над схемами должны быть не атомарны, то есть во время ее обновления разных треды могут получать или новую или старую схему.

      Ему вторит некто Алекс, говоря, что в мускуле она и так свободная, по тому что целостность только предполагается, а не гарантируется.
      • UFO just landed and posted this here
          0
          Видимо имеется ввиду, что установленная стандартом SQL система транзакций слишком жёсткая. Нужно иметь возможность вводить различные уровни транзакций в пределах одного запроса. Например их одной базы получать только подтверждённые данные из завершённых транзакций, а из другой — сырые (текущее состояние базы без учёта транзакций). Плюс, возможность, как это всё описывать на уровне метаданных.
          Тогда можно делить одну базу на некие «непотопляемые отсеки» — наборы таблиц, операции над которыми атомарны, которые будут крутиться на разный физических серверах/кластерах. И можно будет строить очень сложную иерархию серверов.
      0
      Здраво. Но эксперименты с другими типами БД я из-за этого не закончу.
        –7
        выходит, что единственный минус нереляционных бд — это возможная ненадежность разработчика, а в остальном делайте свои сервисы как получится…
        хммм…
        походу цепляются как могут за старую модель
          +1
          ага. ну зачем нужна надежность? ну потеряет фейсбук пару десятков логинов. всего-то. это же меньше 0.1%.
            –6
            те вы хотите сказать, что при падении вашего сервера с бд у вас все гладко восстановиться?
            или при падении сервера с memcache данные фантастическим образом восстановяться в памяти?
              +6
              в memcache ничего такого важного хранить нельзя
                0
                Ну как сказать — важность там ни при чем, это же кэш, в нем можно хранить все, что угодно. Вопрос только в том, что _источником_ любых важных данных должен быть не mc.
              0
              Репликацию в NoSQL никто не отменял. А упасть, как показывает практика может всё. Взять недавнюю историю твиттера.
              To remedy the locked table, we force-restarted the database server in recovery mode, a process that took more than 12 hours (the database covers records for more than 125 million users — that’s a lot of records). During the recovery, the users table and related tables remained unavailable. Unfortunately, even after the recovery process completed, the table remained in an unusable state. Finally, yesterday morning we replaced the partially-locked user db with a copy that was fully available

              Больше 12 часов потратили, базу так поднять и не смогли, подняли из копии. Сколько твиттов при этом умерло — нам думаю не расскажут.
              Отталкиваться в любом случае нужно от потребностей (в т.ч. и по надежности) и выбирать соответствующие инструменты. Не стоит идеализировать не RDBMS не NoSQL.
                0
                непарься, видимо тут SQL головного мозга )
            0
            >единственное, для чего она там нужна — это поиск по входящим сообщениям
            сколько шума было из за cassandra а оказалось они её почти не используют
              +4
              у фейсбука даже это «всего-лишь» — порядка 150-200 серверов.
                0
                Из многих тысяч.
              0
              Рекомендую к прочтению — MongoDB или как разлюбить SQL
                +4
                MongoDB не панацея. Да это может быть довольно эффективным решением на небольших кластерах. А когда речь идет о 1000 узлов, уже совершенно другой уровень монго в текущем его виде на мой взгляд еще большей геморрой чем в ручную шарденая sql база. Я думаю, сыроваты еще NoSql решения.
                  0
                  панацеи впринципе не может быть.
                  тыкните плиз в то место где монго слабоват.
                  1000 узлов обосновано тем, что они используют mysql.
                    0
                    Группировка к примеру не работает на распределенных базах.
                    MapReduce пока работает в single-thread режиме, что не позволяет утилизировать более одного ядра и распараллелить как следует задачу. А вся соль MapReduce в том, что эти операции можно легко распараллеливать.
                +2
                А вообще, Реляционных СУБД не существует в данный момент (тех которые отвечают всем 13 правилам Кодда). В них есть лишь некоторые из них. Ближе всех Oracle и PostgreSQL.

                > Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.
                Думаю, товарищ конкретно путает понятия «реляционность» и SQL.

                Если г-дин Адам таки утверждает что JOIN это зло в РСУБД, то мне таки интересно что он понимает под реляционностью, между чем реляции (связи)?

                Нет никакой проблемы реализовать foreign key'и в MongoDB и других БД, просто там это не нужно, потому что опять же нам не нужен JOIN, как мы уже выяснили.
                  +2
                  JOINы нельзя сделать между серверами, по этому разбивая данные по разным серверам нужно подойти к этому с умом, чтобы там, где джойны нужны, они были. Собственно за это «с умом» отвечает прослойка, которую придумали дядьки из FriendFeed
                    0
                    Такая разбивка на мой взгляд весьма глупое занятие, ведь можно упереться в толщину одного сервера. Хотя во многих случаях прокатит. Однако, это та же фигня что и server-side javascript в mongodb, с той лишь разницей что в mongodb это намного гибче.
                      0
                      Теоретически да, на практике у него еще куча репликантов и сам сервер не дохленький, посмотрите пункт 4.
                      Или, например, на то как это делает eve-online
                      0
                      если не ошибаюсь то JOINы между серверами все-таки можно делать, только вот скорее всего MySQL не умеет этого делать. Распределенные системы на MSSQL как минимум это позволяет. А уж думаю Oracle ему не уступает.
                      0
                      Под термином «реляционная» подразумевается не связь между таблицами, а сами таблицы (от математического термина отношение)
                      +4
                      в одном проекте, который сильно вырос из физических возможностей MySQL поступил очень просто — часть таблиц лежит на одном сервере, часть на другом.
                      Часть таблиц используют встроеные partitions, часть разбивается ручками на разные таблицы.
                      При этом одна «формирующая» таблица может быть разбита на две-три, так чтобы ключики «лучше встали»
                      И конечно же разбитые таблицы будут на разных серверах…

                      Делается на самом деле очень просто — класс который выбирает нужную базу и требуемое имя таблицы на основе селектора — где-то 300 строчек

                      Главное это продумать изначально
                        +3
                        Мне вот известно, что Яндекс также экспериментировал с NoSQL. Redis, Cassandra, Mongo. Однако для широкого применения эти технологии не подошли — используется старая самописная система + кое-где SQL базы.
                        И данный подход я считаю правильным. Понаблюдать — понаблюдаем, но с переходом подождем.
                          –3
                          Redis не БД =)
                            +2
                              0
                              Абсолютно. Я много с ним работал, даже написал драйвер для PHP нормальный, а не то убожество что там было.
                              Однако… это лишь жалкое подобие memcache с неуклюжим флушем на диск.
                                0
                                при всем моем уважении к вам как разработчику это совершенно неправда! Мемкешу к нему как к небу, репликация и стор на диск (а теперь и VM) отлично работают.
                                  0
                                  Redis жеж однотредовый, а memcached на pthreads. Чтоб выжрать ресурсы одной тачки с двумя quad-xeon'ами на борту предлагается запустить там 16 редисов на разных портах. Ну не бред ли?
                                    0
                                    в чем проблема? Множество современных решений, мощнейших, однотредовые. Nginx, NodeJS. И, кстати, Redis не совсем однотредовый, может использовать несколько, разнося фоновые операции
                                      0
                                      Nginx вообще-то порождает заданное количество рабочих процессов самостоятельно.

                        Only users with full accounts can post comments. Log in, please.