Выбор надежной БД в высоконагруженном проекте

    Привет Хабр! Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.

    Требования


    Главное требование к БД — чтобы не теряла информацию. Удивительно, но многие базы данных не удовлетворяют этому ключевому требованию: даже проверенные годами решения дают сбои в несложных сценариях (примеры: раз, два). Мы хотим сохранять избыточность во время отключения любого сервера на техобслуживание, Это означает, что любая информация должна храниться минимум на 3х серверах.

    Другое требование к БД — способность использовать современное железо. Через 10 лет в процессорах будет более 100 ядер, оперативная память будет интегрирована в сами чипы, а стоимость флеш-памяти заметно снизится. Что не изменится за 10 лет — это скорость света. Сетевой пакет из Европы в Америку идет около 100мс (RTT), и это время довольно близко к теоретическому пределу. Поэтому будущие дата-центры — это кластеры мощных числодробилок с быстрой сетью внутри, соединенные по всему миру каналами связи с высокой задержкой (high latency links). Современная БД должна поддерживать синхронную репликацию внутри дата-центра и асинхронную между дата-центрами.

    При анализе мы ориентировались на утверждения самих поставщиков БД, результаты независимых тестов (когда они есть) и кейсы реального использования (много примеров есть на highscalabitility.com). Мы исключили из рассмотрения встроенные (embedded) базы данных, поскольку у них нет автоматической репликации по сети.

    Коммерческие SQL-базы данных


    Самые известные представители этого сегмента — Microsoft SQL Server и Oracle Database. Это отличные, проверенные временем продукты, а с последними инновациями — in-memory tables и column stores — на полную используют возможности современного железа. Обе БД поддерживают технологии кластеризации, и у обеих богатые возможности языка SQL (хотя у каждой — свой диалект).

    Обе БД можно лицензировать по модели “цена за ядро процессора” и тогда цена не зависит от числа пользователей. Проанализировав нашу нагрузку и сделав прогноз по росту, мы посчитали, что стоимость будет несоразмерно большой и решили изучить альтернативы.

    SQL-базы данных с открытым кодом


    MySQL и PostgreSQL — самые известные представители этой группы — оптимальный выбор для большинства задач. Обе поддерживают кластеризацию, есть примеры использования в больших проектах и даже миграции с одной на другую в больших проектах. Пожалуй, основным минусом для нас является ручной шардинг и, как следствие, отсутствие автоматической ребалансировки кластера.

    В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей. Распределение нагрузки по такому ключу рано или поздно приведет к переполнению одних серверов в кластере и недозагруженности других. В этот момент потребуется ребалансировка — то есть разделение ноды кластера на две. Эту работу сложно делать на работающем 24x7 кластере без потери надежности.

    NoSQL-базы данных


    Модное в 2000-е годы движение NoSQL сейчас переживает период зрелости. Все игроки хорошо известны и обладают своими сторонниками. Созданные при бурном росте интернета, эти БД развивались для соответствующих задач, например, для хранения и обработки миллиардов неструктурированных документов. Многие решения декларируют “eventual consistency”, что означает отказ от строгого “C” в CAP-теореме. Мы не можем терять данные клиентов, поэтому для нас такой компромисс неприемлем.

    Некоторые NoSQL-решения снижают доступность (“A”) и декларируют “CP”, например, Cassandra. Это подходит для наших задач, однако мы были удивлены отсутствием row-level consistency: две совпавших по времени записи в разные колонки одной строки могут привести к порче данных. И хотя такого уровня глюков не ожидаешь от БД, вокруг этой проблемы можно найти обходной путь (например, модифицировать строки только целиком), и мы взяли Cassandra на заметку.

    Облачные базы данных


    Про эту категорию можно написать отдельный обзор. У каждого из основных PaaS-игроков (Amazon, Google и Microsoft) есть 6-8 разных предложений для хранения структурированных данных (и еще много сервисов для хранения BLOBS). Под любой тип нагрузки можно подобрать готовое решение.

    Мы отказались от облачных хранилищ по соображениям хранения персональных данных. Наши клиенты находятся в разных странах, а ни один сервис не предлагает хранение ПДн во всех странах мира в соответствии с локальным законодательством. Другой причиной была сильная зависимость от конкретного вендора — вы не можете взять их технологию и развернуть на своем железе. Если появится желание уйти от вендора (при повышении цен или снижении надежности), проект миграции может быть очень долгим. У Dropbox ушло более 2 лет на переезд из облака Amazon в собственное хранилище.

    NewSQL-базы данных


    Популярность языка SQL и развитие “железа” породили новое движение — распределенные базы данных с языком запросов SQL. Среди них выделяется Google Spanner, которая гарантирует linearizability — глобальный порядок записи всех транзакций. Чтобы решить такую задачу в масштабах планеты, нужно синхронизировать время на серверах БД по всему миру. Компания Google использует для этого атомные часы, а для резерва — GPS-приемники.

    Однако для простых смертных атомные часы пока остаются роскошью, поэтому авторы Spanner построили аналогичную БД с несколько меньшими гарантиями на порядок транзакций, но достаточными для большинства приложений. Эта БД называется CockroachDB (от англ. “таракан”) и своим названием олицетворяет живучесть кластера при сбоях железа или связей между дата-центрами. CockroachDB предоставляет полноценные распределенные транзакции и автоматическую ребалансировку кластера при потере ноды, что, вкупе с привычным языком запросов SQL, выгодно отличает ее от Cassandra. Из недостатков стоит отметить отсутствие полнотекстовых индексов и сравнительную молодость решения.

    Move code to data


    Часто бизнес-логика располагается на сервере приложений, который получает запросы клиентов и для их обработки обращается за данными к серверу БД. Когда данных много, передача их по сети от сервера БД начинает занимать существенное время. Отсюда появляются естественное желание перенести всю обработку внутрь БД и технологии типа Apache Hadoop, которые позволяют программировать такие задачи. (Обыкновенные реляционные БД также позволяют писать логику запросов внутри, на хранимых процедурах, но многие разработчики их не любят, поскольку их неудобно отлаживать.)

    В последнее время набирает популярность идея совмещения серверов приложений и БД для near real-time OLTP-нагрузок, и появляются соответствующие технологии, например, Tarantool. Очень подкупает архитектура без блокировок “cooperative multitasking”, хотя писать такие приложения сложнее. Останавливает язык программирования Lua — хотя он и популярен среди разработчиков игр, но закрытый, развивается медленно и в нашей команде нет людей с реальным опытом его использования.

    Заключение


    Сегодня мы считаем CockroachDB самым перспективным вариантом. Нам импонирует открытость компании (исходный код БД выложен на github) и качество документации (архитектурные и другие ключевые решения вплоть до низкоуровнего формата хранения данных опубликованы на сайте). Мы следим за эволюцией продукта и будем рады обмену мнениями с коллегами, которые используют эту БД в production.

    А пока мы стартуем пилотный проект и будем делиться с вами опытом использования в боевом режиме.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 23
    • +1
      Спасибо за статью. Взяли на заметку.
      Насчет Tarantool: на какой-то презентации обещали завезти поддержку SQL.
      • +1
        Из общения с разрабоичиками тарантула я лично понял, что они в идеале стремятся к чему-то близкому к cockroachdb, то есть к прозрачному шардированию, рафту и вот этому всему :). Это не может не радовать.
      • +1
        А вы кстати на TiDB не смотрели? Это очень похожее на cockroachdb что-то, судя по тому, что я могу видеть
        • 0
          Нет, близко не смотрели. Они вроде из Китая. И в качестве базового протокола — mySQL вместо PostgreSQL. Спасибо за наводку!
        • +1
          Что вы думаете по поводу in-memory data grid (напр., де-факто отечественный gridgain.com)?
          • +1
            Мы слышали восторженные мнения о GridGain от бизнес-людей, принявших решение о пилоте, но не слышали/читали никаких мнений от разработчиков. Это немного настораживает.
          • +3
            В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей. Распределение нагрузки по такому ключу рано или поздно приведет к переполнению одних серверов в кластере и недозагруженности других. В этот момент потребуется ребалансировка — то есть разделение ноды кластера на две. Эту работу сложно делать на работающем 24x7 кластере без потери надежности.


            1) Я правильно понял вашу мысль, что вы отказались от PostgreSQL из-за того, что попытались использовать неподходящий для вас алгоритм генерации ключа шардирования? Если шардировать по компании вы не можете, можно же использовать что-то иное.

            2) CockroachDB как-то пока не выглядит production ready — habrahabr.ru/post/345990
            • 0
              1) Не совсем. Сложно предсказать характер нагрузки через несколько лет. Поэтому какой бы алгоритм шардирования ни выбрать, рано или поздно придется делать ребалансировку. Хочется выбрать БД, которая умеет делать ребалансировку (менять алгоритм шардирования и соответственно переносить данные) на лету. Если таких не найдется или они будут недостаточно надежны в production — придется вернуться к mySQL/PostreSQL.

              2) Мы делаем ставку на то, что он станет production ready в обозримое время (в ближайший год, например). Это осознанный риск, который мы можем себе позволить — мы никуда не торопимся. А статья скорее повышает доверие к нему — ведь про многие альтернативы аналогичных статей «как я восстановил данные» — не находится.
            • +6
              Простите, очень странное сравнение баз данных и критерии выбора… на пальцах как-то все.

              Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно.


              — тут не понятно, имеется ввиду трафик? Если объем сохраняемых данных — опять не понятно, данные взяты абсолютно, или с учетом всех кластеров\репликаций и т.п.?

              — если, предположить, данные указаны в пределах одного экземпляра БД (мастер-кластера в идеале), получается: 60Гб * 30дней * 12мес = 21,6 Тб, не учитывая потенциальный рост компании, и умножить, к примеру, на х6 (2 мастера, по два слейва на мастер) — 129,6Тб в год, за 10 лет ~1.3Пб… впечатляющий объем.

              самое любопытное — не сказано как сейчас у вас устроено хранение… опять все на пальцах.

              Слишком легкомысленный подход к выбору технологий, как для заявленных объемов.

              В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей.


              Простите, не ясно что за БД у вас используется, но тот-же mysql при грамотной архитектуре приложения и бд, без проблем справится с тесятками-сотнями тысяч пользователей, проблема больших и маленьких шардов странная

              у нас в компании, для статистики, собирается много данных, каждуй минуту сотни записей с 1 устройства, за день со всех устройств (около 800) — десятки тысяч записей, в результате — самая большая таблица: ~450млн.записей, + несколько таблиц от 1млн до 10млн записей, все крутиться на 1 сервере, одна бд мускл, ниче не тормозит, запросы ходят хорошо, запросы которые начинали выполняться долго — оптимизировали, избавляясь от join и т.п., разбивая получения данных вместо 1 сложного запроса — на несколько простых…

              • 0
                Спасибо за комментарий. Подробно описать нашу инфраструктуру — тема отдельного поста, но вкратце отвечая на ваши вопросы:

                60GB — абсолютный объем новых данных, которые нужно ежедневно сохранять (в рабочий день, в выходные поменьше). Бывают пики до 1GB/минуту. Большая часть — неструктурированные данные, которые хранятся отдельно от БД.

                В самой крупной таблице около 300 млн записей, и при текущих объемах все вполне может жить в рамках одного мастер-сервера с несколькими репликациями. И, с учетом роста нагрузки, в пределах 12-24 мес тоже будет жить. Скорость хорошая — большинство запросов к БД работают in memory, на application servers — логические кеши, у фронтового nginx — свой кеш.

                Но рано или поздно структурированные данные перестанут влезать в одну машину и нужно заранее к этому подготовиться. Поэтому сейчас начнем писать все данные в две базы одновременно и посмотрим, насколько надежно работает выбранный CockroachDB.
                Если в течение 3-4 мес все будет без сбоев — начнем потихоньку отключать текущую БД. А если вдруг уровень надежности будет недостаточным — сделаем на PostgreSQL, благо разработчики CockroachDB взяли его диалект для своего языка запросов.

                Согласен, любую задачу шардинга можно решить на mysql/postgresql. Но если ее уже за нас решили разработчики БД, включая автоматическую ребалансировку и восстановление при сбоях, и это работает надежно, почему бы этим не воспользоваться?
                • +1
                  спасибо, немного прояснилось,

                  пожалуй соглашусь: с большой БД самое страшное, когда что-то пошло не так и слейв сломался, или шард или еще что-то… поведение БД в подобных ситуациях, по моему, лишь практически удастся оценить, в теории всегда все гладко и предсказуемо :)
                  • 0
                    Более того, я еще не видел ни одной серьезной production-системы, из которой когда-либо не восстанавливали данные вручную. Рано или поздно сбой случится, и надо быть готовым. Спасибо коллеге youROCK, который протоптал эту дорожку для CockroachDB :)
              • 0

                В штуках типа CockroachDB напрягает магия. То есть шардинг то есть, но больно магический. Плюс конкретно в Cockroach печалят сильные ограничения по сравнению с Postgres, но они вроде работают над этим.

                • +1
                  Шардинг совсем не магический. Он идет с помощью разбиения пространства ключей на диапазоны по 64 Мб. Ключи составляются как /<Таблица>/<тип>/<значение>. Для обычных записей в тип записывается 1, для индексов — 2. В значение пишется значение первичного ключа или индекса соответственно.

                  То есть, грубо говоря, данные шардятся по первичному ключу, а индексы — по значению индекса. Какая тут магия-то :)?
                • +3
                  Lua — хотя он и популярен среди разработчиков игр, но закрытый

                  Кто его закрыл???
                  • –2
                    Вносить изменения в исходный код lua могут только авторы из Папского католического университета Рио-де-Жанейро.
                    • +1
                      Вносить изменения в ядро Linux кому то с улицы тоже не сразу разрешат, но оно от этого не становится закрытым
                      • 0
                        В ядро Linux за последние 30 дней внесли изменения 341 человек: https://github.com/torvalds/linux/pulse/monthly. Довольно многим разрешают.

                        По lua — формально вы правы, я неточно выразился. MIT лицензия — свободная лицензия.

                        Но когда мастер-исходники выложены на github и авторы позволяют сообществу вносить в них исправления — это более открытый подход. Мы таким образом внесли несколько патчей в продукты, которые используем, последний раз — в клиентскую библиотеку NATS.
                  • 0
                    -
                    • 0
                      Здравствуйте Pyrus,

                      Вы написали, что отказались от облачных решений, но не рассматривали ли Вы перед отказом Azure Cosmos DB?
                      Она очень заинтересовала, но информации о ней (кроме как от Microsoft) не так то и много.

                      Буду благодарен если поделитесь своими соображениями, если рассматривали ее.
                      • 0
                        Добрый день, мы пристально Azure Cosmos DB не рассматривали по причине сильной зависимости от одного вендора. Представьте, вдруг она перестала работать — а вам даже позвонить некуда…

                        Однако обещания у них заманчивые. )
                        • 0
                          Здравстувйте Pyrus,

                          Представьте, вдруг она перестала работать — а вам даже позвонить некуда…

                          По такой логике AWS, Azure, Digital Ocean и любым другим поставщикам облачных услуг доверять вовсе нельзя, а надо строить свои дата-центры. Но согласитель — это ведь довольно накладно и очень редко, когда оправдано.

                          Я с Вами не спорю, такая вероятность естественно есть. И от отказа облачного сервиса всегда надо себя обезопасить.

                          Вы не думали над вариантом использования облачной распределенной базы (Cosmos DB или альтернатив) с репликацией в свою собственную(в которую не сложно перенести данные из облачной, к примеру для Cosmos DB кажется наиболее близка ArangoDB) на случай экстренного восстановления?

                          К примеру иметь несколько серверов для репликации, которые будут использоваться в случает отказа основной базы и писать в них чем-то вроде сервисов на Go срабатывающих на CRUD операции.

                          Если не совсем понятно что я пытаюсь описать — могу визуализировать.
                          • 0
                            Облачные сервисы падают регулярно, это нормально. Мы их используем, но не зависим от одного конкретного.

                            Использовать две разных БД — дорого. Основные затраты — на экспертизу разработчиков. Команда должна освоить обе БД в достаточной степени, чтобы обеспечить надежность и производительность.

                            Поэтому мы выбрали БД, которую можно развернуть в любом облаке или дата-центре.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.