Привет Хабр! Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.
Главное требование к БД — чтобы не теряла информацию. Удивительно, но многие базы данных не удовлетворяют этому ключевому требованию: даже проверенные годами решения дают сбои в несложных сценариях (примеры: раз, два). Мы хотим сохранять избыточность во время отключения любого сервера на техобслуживание, Это означает, что любая информация должна храниться минимум на 3х серверах.
Другое требование к БД — способность использовать современное железо. Через 10 лет в процессорах будет более 100 ядер, оперативная память будет интегрирована в сами чипы, а стоимость флеш-памяти заметно снизится. Что не изменится за 10 лет — это скорость света. Сетевой пакет из Европы в Америку идет около 100мс (RTT), и это время довольно близко к теоретическому пределу. Поэтому будущие дата-центры — это кластеры мощных числодробилок с быстрой сетью внутри, соединенные по всему миру каналами связи с высокой задержкой (high latency links). Современная БД должна поддерживать синхронную репликацию внутри дата-центра и асинхронную между дата-центрами.
При анализе мы ориентировались на утверждения самих поставщиков БД, результаты независимых тестов (когда они есть) и кейсы реального использования (много примеров есть на highscalabitility.com). Мы исключили из рассмотрения встроенные (embedded) базы данных, поскольку у них нет автоматической репликации по сети.
Самые известные представители этого сегмента — Microsoft SQL Server и Oracle Database. Это отличные, проверенные временем продукты, а с последними инновациями — in-memory tables и column stores — на полную используют возможности современного железа. Обе БД поддерживают технологии кластеризации, и у обеих богатые возможности языка SQL (хотя у каждой — свой диалект).
Обе БД можно лицензировать по модели “цена за ядро процессора” и тогда цена не зависит от числа пользователей. Проанализировав нашу нагрузку и сделав прогноз по росту, мы посчитали, что стоимость будет несоразмерно большой и решили изучить альтернативы.
MySQL и PostgreSQL — самые известные представители этой группы — оптимальный выбор для большинства задач. Обе поддерживают кластеризацию, есть примеры использования в больших проектах и даже миграции с одной на другую в больших проектах. Пожалуй, основным минусом для нас является ручной шардинг и, как следствие, отсутствие автоматической ребалансировки кластера.
В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей. Распределение нагрузки по такому ключу рано или поздно приведет к переполнению одних серверов в кластере и недозагруженности других. В этот момент потребуется ребалансировка — то есть разделение ноды кластера на две. Эту работу сложно делать на работающем 24x7 кластере без потери надежности.
Модное в 2000-е годы движение NoSQL сейчас переживает период зрелости. Все игроки хорошо известны и обладают своими сторонниками. Созданные при бурном росте интернета, эти БД развивались для соответствующих задач, например, для хранения и обработки миллиардов неструктурированных документов. Многие решения декларируют “eventual consistency”, что означает отказ от строгого “C” в CAP-теореме. Мы не можем терять данные клиентов, поэтому для нас такой компромисс неприемлем.
Некоторые NoSQL-решения снижают доступность (“A”) и декларируют “CP”, например, Cassandra. Это подходит для наших задач, однако мы были удивлены отсутствием row-level consistency: две совпавших по времени записи в разные колонки одной строки могут привести к порче данных. И хотя такого уровня глюков не ожидаешь от БД, вокруг этой проблемы можно найти обходной путь (например, модифицировать строки только целиком), и мы взяли Cassandra на заметку.
Про эту категорию можно написать отдельный обзор. У каждого из основных PaaS-игроков (Amazon, Google и Microsoft) есть 6-8 разных предложений для хранения структурированных данных (и еще много сервисов для хранения BLOBS). Под любой тип нагрузки можно подобрать готовое решение.
Мы отказались от облачных хранилищ по соображениям хранения персональных данных. Наши клиенты находятся в разных странах, а ни один сервис не предлагает хранение ПДн во всех странах мира в соответствии с локальным законодательством. Другой причиной была сильная зависимость от конкретного вендора — вы не можете взять их технологию и развернуть на своем железе. Если появится желание уйти от вендора (при повышении цен или снижении надежности), проект миграции может быть очень долгим. У Dropbox ушло более 2 лет на переезд из облака Amazon в собственное хранилище.
Популярность языка SQL и развитие “железа” породили новое движение — распределенные базы данных с языком запросов SQL. Среди них выделяется Google Spanner, которая гарантирует linearizability — глобальный порядок записи всех транзакций. Чтобы решить такую задачу в масштабах планеты, нужно синхронизировать время на серверах БД по всему миру. Компания Google использует для этого атомные часы, а для резерва — GPS-приемники.
Однако для простых смертных атомные часы пока остаются роскошью, поэтому авторы Spanner построили аналогичную БД с несколько меньшими гарантиями на порядок транзакций, но достаточными для большинства приложений. Эта БД называется CockroachDB (от англ. “таракан”) и своим названием олицетворяет живучесть кластера при сбоях железа или связей между дата-центрами. CockroachDB предоставляет полноценные распределенные транзакции и автоматическую ребалансировку кластера при потере ноды, что, вкупе с привычным языком запросов SQL, выгодно отличает ее от Cassandra. Из недостатков стоит отметить отсутствие полнотекстовых индексов и сравнительную молодость решения.
Часто бизнес-логика располагается на сервере приложений, который получает запросы клиентов и для их обработки обращается за данными к серверу БД. Когда данных много, передача их по сети от сервера БД начинает занимать существенное время. Отсюда появляются естественное желание перенести всю обработку внутрь БД и технологии типа Apache Hadoop, которые позволяют программировать такие задачи. (Обыкновенные реляционные БД также позволяют писать логику запросов внутри, на хранимых процедурах, но многие разработчики их не любят, поскольку их неудобно отлаживать.)
В последнее время набирает популярность идея совмещения серверов приложений и БД для near real-time OLTP-нагрузок, и появляются соответствующие технологии, например, Tarantool. Очень подкупает архитектура без блокировок “cooperative multitasking”, хотя писать такие приложения сложнее. Останавливает язык программирования Lua — хотя он и популярен среди разработчиков игр, но закрытый, развивается медленно и в нашей команде нет людей с реальным опытом его использования.
Сегодня мы считаем CockroachDB самым перспективным вариантом. Нам импонирует открытость компании (исходный код БД выложен на github) и качество документации (архитектурные и другие ключевые решения вплоть до низкоуровнего формата хранения данных опубликованы на сайте). Мы следим за эволюцией продукта и будем рады обмену мнениями с коллегами, которые используют эту БД в production.
А пока мы стартуем пилотный проект и будем делиться с вами опытом использования в боевом режиме.
Требования
Главное требование к БД — чтобы не теряла информацию. Удивительно, но многие базы данных не удовлетворяют этому ключевому требованию: даже проверенные годами решения дают сбои в несложных сценариях (примеры: раз, два). Мы хотим сохранять избыточность во время отключения любого сервера на техобслуживание, Это означает, что любая информация должна храниться минимум на 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.
А пока мы стартуем пилотный проект и будем делиться с вами опытом использования в боевом режиме.
