Выбираем БД для Highload-проекта
Главное требование, предъявляемое к базе данных для Highload-проекта, заключается в отсутствии потери информации. К сожалению, даже проверенные решения могут давать сбои. Как же сохранить избыточность во время отключения любого сервера на техническое обслуживание? К примеру, хранить информацию как минимум на трех серверах.
Второе требование к такой БД — способность к использованию современного железа. Давайте представим, что спустя 10 лет в процессорах будет 100 ядер, оперативная память интегрируется в сами чипы, цена флэш-памяти существенно снизится и т. д. и т. п. Но вот что не изменится, так это скорость света. К примеру, сетевой пакет из Европы в США идет порядка 100 мс (RTT), что уже весьма близко к теоретическому пределу. Это значит, что будущие дата-центры могут представлять собой кластеры с быстрой внутренней сетью, соединенные по всему миру каналами связи с high latency links (высокой задержкой). А современная база данных должна поддерживать синхронную репликацию внутри дата-центра и асинхронную репликацию между дата-центрами.
Теперь, когда мы приблизительно знаем, что нам нужно, давайте выполним краткий обзор БД, которые могут быть эффективны при работе с высоконагруженными проектами.
Коммерческие SQL-базы
Наиболее известные представители — Oracle Database и Microsoft SQL Server. Хорошие продукты, проверенные временем. С учетом in-memory tables и column stores максимально используют возможности современного железа. Поддерживают технологии кластеризации и богатую функциональность языка SQL (правда, у каждой БД свой диалект). Также эти 2 базы данных можно лицензировать по принципу «цена за ядро процессора», однако в некоторых случаях, если проанализировать нагрузку и сделать прогноз по росту, стоимость бывает несоразмерно большой. Но есть альтернативы.
SQL-базы с открытым кодом
Как тут не вспомнить MySQL и PostgreSQL — наиболее известных представителей данной группы? Эти БД — оптимальный выбор в большинстве случаев. Поддерживают кластеризацию, могут использоваться в больших проектах, возможны миграции с одной на другую. Из минусов — ручной шардинг и, как результат, отсутствие автоматической ребалансировки кластера.
NoSQL
Модное NoSQL-движение переживает период зрелости. И основные игроки хорошо известны, и свои сторонники имеются. NoSQL-базы данных создавались при бурном развитии интернета, поэтому и проектировались они для решения соответствующих задач, к примеру, для хранения и обработки миллионов и даже миллиардов неструктурированных документов. У многих решений декларируется «eventual consistency» — отказ от строгого «C» в CAP-теореме. Некоторые NoSQL-решения понижают доступность («A»), декларируя «CP», та же Cassandra.
Облачные БД
Собственно говоря, про данную категорию можно написать отдельный обзор. У каждого из главных PaaS-игроков (Google, Amazon и Microsoft) существуют 6-8 различных предложений, предназначенных для хранения структурированных данных (а также много сервисов для хранения BLOBS). Соответственно, вы можете подобрать готовое решение под любой тип нагрузки. Но стоит учитывать наличие зависимости от конкретного вендора — вы не сможете просто взять их технологию и развернуть ее на своем железе, поэтому, если захотите уйти от вендора (например, повысились цени или снизилась надежность), проект миграции может быть весьма длительным. У того же Dropbox ушло более двух лет на переезд в собственное хранилище из облака Amazon.
NewSQL-базы данных
Язык SQL популярен, а железо развивается. Все это в совокупности привело к появлению распределенных БД с языком запросов SQL. Например, геораспределенная система Google Spanner, гарантирующая глобальный порядок всех транзакций (linearizability). Для решения данной задачи в планетарном масштабе требуется синхронизация времени на серверах БД по всему миру. Google применяет для этого атомные часы.
Да, для обычных смертных атомные часы могут быть роскошью, поэтому авторы Spanner создали аналогичную БД, но с меньшими гарантиями на порядок транзакций. Впрочем, этих гарантий вполне достаточно для большинства программных приложений. Речь идет, конечно же, о CockroachDB (от англ. «таракан»). Уже по названию ясно, что БД олицетворяет живучесть кластера в случаях сбоев железа или нарушения связей между дата-центрами. Пожалуй, CockroachDB — один из весьма перспективных вариантов.
Move code to data
Нередко бизнес-логика находится на сервере приложений, который получает клиентские запросы и обращается для обработки этих запросов за данными к серверу БД. Если данных много, то их передача по сети от сервера БД занимает немалое время. Разумеется, возникают вполне естественные стремления перенести всю обработку внутрь базы данных. В результате возникают и технологии типа Apache Hadoop, позволяющие такие задачи программировать. Кстати говоря, обыкновенные реляционные базы данных тоже позволяют писать логику запросов внутри, то есть на хранимых процедурах, однако многие разработчики их не любят ввиду неудобства отладки.
Существует идея совмещения БД и серверов приложений для near real-time OLTP-нагрузок. В результате появляются соответствующие технологии, тот же Tarantool. Тут подкупает «cooperative multitasking» — архитектура без блокировок, правда, писать такие приложения сложнее. К сожалению, многих останавливает язык программирования Lua — пусть он и популярен у разработчиков игр, однако он развивается не так быстро, как хотелось бы, да и не во всех командах есть люди с реальным опытом его применения.
Статья подготовлена по материалам блога компании Pyrus.
