Привет Хабр! Сегодня клиенты Pyrus ежедневно загружают к нам около 60 ГБ данных.
Наша технология хранения информации многократно доказала свою надежность.
Компания развивается, и мы озабочены выбором базы данных на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту, не меняя платформу каждые 2-3 года.
Конкуренция на рынке баз данных острая: существует множество доступных решений, большинство из которых имеют открытый исходный код и/или бесплатны.
Мы ищем «идеальное решение»™ для нашей задачи.
Требования
Основное требование к базе данных — чтобы она не теряла информацию.Удивительно, но многие базы данных не отвечают этому ключевому требованию: даже проверенные временем решения терпят неудачу в простых сценариях (примеры: один раз , два ).
Мы хотим поддерживать резервирование, когда какой-либо сервер отключается на техническое обслуживание.
Это означает, что любая информация должна храниться как минимум на 3-х серверах.
Еще одним требованием к базе данных является возможность использования современного оборудования.
Через 10 лет процессоры будут иметь более 100 ядер, оперативная память будет интегрирована в сами чипы, а стоимость флэш-памяти существенно снизится.
Что не изменится через 10 лет, так это скорость света.
Сетевой пакет из Европы в Америку занимает около 100 мс (RTT), и это время довольно близко к теоретическому пределу.
Таким образом, будущие центры обработки данных представляют собой кластеры мощных вычислительных машин с быстрой сетью внутри, соединенных по всему миру каналами с высокой задержкой.
Современная база данных должна поддерживать синхронную репликацию внутри центра обработки данных и асинхронную репликацию между центрами обработки данных.
При анализе мы руководствовались заявлениями самих поставщиков баз данных, результатами независимых тестов (при их наличии) и реальными сценариями использования (примеров много на сайте).
Мы исключили из рассмотрения встроенные базы данных, поскольку они не имеют автоматической репликации по сети.
Коммерческие базы данных SQL
Наиболее известные представители этого сегмента — Microsoft SQL Server и Oracle Database. Это превосходные, проверенные временем продукты, а благодаря последним инновациям — хранению таблиц и столбцов в памяти — они в полной мере используют возможности современного оборудования.Обе базы данных поддерживают технологии кластеризации и обе обладают богатыми возможностями языка SQL (хотя каждая имеет свой собственный диалект).
Обе базы данных можно лицензировать по модели «цена за процессорное ядро», и тогда цена не зависит от количества пользователей.
Проанализировав нашу рабочую нагрузку и спрогнозировав рост, мы почувствовали, что затраты будут непропорциональными, и решили изучить альтернативы.
Базы данных SQL с открытым исходным кодом
MySQL и PostgreSQL — самые известные представители этой группы — оптимальный выбор для большинства задач.Оба поддерживают кластеризацию, есть примеры использования в крупных проектах и даже миграция из одного в другое в крупных проектах .
Пожалуй, главным минусом для нас является ручной шардинг и, как следствие, отсутствие автоматической ребалансировки кластера.
В нашей системе в качестве ключа шардирования естественно выбрать организацию (группу пользователей) — параметр, определяющий, на каком сервере кластера хранить элемент данных.
Однако некоторые организации остаются небольшими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей.
Распределение нагрузки по такому ключу рано или поздно приведет к перегрузке одних серверов кластера и недогрузке других.
На этом этапе потребуется ребалансировка — то есть разделение узла кластера на два.
Эту работу сложно выполнить на работающем кластере 24x7 без потери надежности.
NoSQL базы данных
Модное в 2000-х годах движение NoSQL сейчас достигает зрелости.Все игроки хорошо известны и имеют своих сторонников.
Эти базы данных, созданные во время быстрого роста Интернета, развивались для решения смежных задач, например.
хранение и обработка миллиардов неструктурированных документов .
Множество решений объявить «конечная согласованность», что означает отказ от строгого «C» в теореме CAP. Мы не можем потерять данные клиентов, поэтому такой компромисс для нас неприемлем.
Некоторые решения NoSQL снижают доступность («A») и объявляют «CP», например Cassandra. Это соответствует нашим целям, но мы были удивлены отсутствие согласованности на уровне строк : две одновременные записи в разных столбцах одной строки могут привести к повреждению данных.
И хотя вы не ожидаете такого уровня сбоев от базы данных, можно найти обходной путь этой проблемы (например, изменение только целых строк), и мы взяли Cassandra на заметку.
Облачные базы данных
Об этой категории можно написать отдельный отзыв.У каждого из основных игроков PaaS (Amazon, Google и Microsoft) есть 6–8 различных предложений для структурированного хранения данных (и многие другие службы хранения BLOBS).
Вы можете выбрать готовое решение для любого типа нагрузки.
Мы отказались от облачного хранилища из соображений хранения личных данных.
Наши клиенты находятся в разных странах, и ни один сервис не предлагает хранение персональных данных во всех странах мира в соответствии с местным законодательством.
Еще одной причиной стала сильная зависимость от конкретного вендора — нельзя взять их технологию и развернуть на своем оборудовании.
Если есть желание уйти от вендора (при росте цен или снижении надежности), проект миграции может оказаться очень долгим.
Dropbox занял более 2 лет перейти из облака Amazon в собственное хранилище.
Базы данных NewSQL
Популярность языка SQL и развитие аппаратного обеспечения породили новое движение — распределенные базы данных с языком запросов SQL. Среди них выделяется Google Spanner, гарантирующий линеаризуемость — глобальный порядок записи всех транзакций.Чтобы решить такую проблему в планетарном масштабе, необходимо синхронизировать время на серверах баз данных по всему миру.
Google использует для этого атомные часы и GPS-приемники в качестве резервной копии.
Однако для простых смертных атомные часы по-прежнему остаются роскошью, поэтому авторы Spanner построили аналогичную базу данных с чуть меньшими гарантиями порядка транзакций, но достаточными для большинства приложений.
Эта база данных называется CockroachDB (от английского «таракан») и ее название отражает живучесть кластера в случае аппаратных сбоев или соединений между дата-центрами.
ТараканДБ обеспечивает полноценные распределённые транзакции и автоматическая ребалансировка кластера при потере узла, что вкупе с привычным языком запросов SQL выгодно отличает его от Cassandra. Из недостатков стоит отметить отсутствие полнотекстовых индексов и относительную молодость решения.
Переместить код в данные
Зачастую бизнес-логика располагается на сервере приложений, который получает запросы клиентов и запрашивает данные у сервера базы данных для их обработки.Когда данных много, их передача по сети с сервера базы данных начинает занимать значительное время.
Это порождает естественное желание перенести всю обработку внутри базы данных и таких технологий, как Apache Hadoop, которые позволяют программировать подобные задачи.
(Обычные реляционные базы данных также позволяют писать логику запросов внутри, в хранимых процедурах, но многим разработчикам они не нравятся, поскольку их неудобно отлаживать.
) В последнее время набирает популярность идея объединения серверов приложений и баз данных для OLTP-загрузок, близких к реальному времени, и появились соответствующие технологии, например, Tarantool. Архитектура «кооперативной многозадачности» без блокировки очень привлекательна, хотя писать такие приложения сложнее.
Нас останавливает язык программирования Lua — он хоть и популярен среди разработчиков игр, но закрыт, развивается медленно и в нашей команде нет людей с реальным опытом его использования.
Заключение
На сегодняшний день мы считаем CockroachDB наиболее перспективным вариантом.Нас впечатляет открытость компании (исходный код базы данных выложен на github) и качество документации (на сайте опубликованы архитектурные и другие ключевые решения, вплоть до низкоуровневого формата хранения данных).
Мы следим за развитием продукта и будем рады обменяться мнениями с коллегами, которые используют эту базу данных в производстве.
А пока мы запускаем пилотный проект и поделимся с вами опытом его использования в боевом режиме.
Теги: #программирование #Администрирование баз данных #Облачные вычисления #Высокая производительность #NoSQL #sql #распределенные системы #NewSQL #CockroachDB #теорема кэпа
-
Гвинея-Бисау
19 Oct, 24 -
Паукообразные
19 Oct, 24 -
Bittorrent Dht Можно Использовать Для Ddos
19 Oct, 24 -
Ubuntu На Toshiba: Подводные Камни
19 Oct, 24
