Видео доклада доступно по ссылке страница отчета .
А для читателей Хабра предлагаю краткий пересказ.
Сначала расскажу, как подойти к выбору техники для высоконагруженного проекта.
- Прежде всего, должно быть понимание того, как это работает. Не только сильные, но и слабые стороны.
- Знание того, как его отслеживать и создавать резервные копии.
Без хороших инструментов для этого использовать эту технологию в производстве рано.
- Рано или поздно системы «падают» (это нормальная, стандартная ситуация) и нужно знать, что делать в этом случае.
MySQL и MongoDB начинали с очень простых и глупых решений, которые просто работают и имеют понятные недостатки.
Тарантул
Для какого варианта использования был создан Tarantool? Представьте, что у вас есть социальная сеть и пользовательские данные разбросаны по сотням серверов MySQL. В то же время пользователи делятся по идентификатору пользователя.Пользователь вводит свой адрес электронной почты и хочет войти.
Очевидным решением является сегментирование пользователей по электронной почте.
Но, у человека есть еще и номер телефона, по которому он тоже хочет зайти.
Соответственно, второе очевидное решение — это какая-то база данных, быстрая, в которой есть переписка email => userId, телефон => userId, и это желательно, чтобы такая база данных была постоянной.
Но на тот момент таких баз данных не было, поэтому одним из вариантов на тот момент было поместить все это в мемкэш.
Но допустим, операция добавления нового поля для поиска userId будет очень сложной.
С мемкэшем довольно много проблем, но, по крайней мере, он может выдерживать большие нагрузки на чтение и запись.
Итак, Тарантул.
Сохраняет все данные в памяти.
И в то же время на диске.
По словам разработчиков, он способен выдерживать 1 миллион запросов в секунду на одно ядро процессора.
Разработано mail.ru. Константин Осипов, один из разработчиков Tarantool, ранее разрабатывал MySQL.
Процесс обработки запросов в Tarantool имеет конвейерную архитектуру.
Многие клиенты запрашивают сервер Tarantool. Все эти запросы сохраняются в очереди в потоке ввода-вывода.
Затем он через определенные промежутки времени передает их на исполнение.
Таким образом, поток выполнения блокируется на достаточно короткое время.
Отдельно стоит упомянуть настойчивость.
Если кто-то использует redis с упорством, то наверняка заметит, что redis «прилипает» на довольно длительный период времени в тот момент, когда идет процесс создания форка.
У Tarantool другая модель.
До версии 1.6.7 часть памяти хранилась в общем регионе и во время форка не копировалась.
И пока раздвоенный дочерний элемент записывается на диск, родитель знает, что этот участок памяти трогать нельзя.
Начиная с версии 1.6.7 от форка вообще отказались.
Они поддерживают, можно сказать, механизм виртуальной памяти в пользовательском пространстве.
Трансляция адресов памяти пользовательского пространства.
Вместо создания процесса разветвления создается поток, который просматривает снимок памяти в пользовательском пространстве и записывает согласованный снимок на диск.
Для каких ситуаций подходит Tarantool:
- У вас много читающих/пишущих клиентов.
- Много мелких операций чтения/записи.
- Когда нужно какое-то центральное хранилище и рабочий набор умещается в памяти.
Tarantool пока не поддерживает шардинг.
- Желание писать хранимые процедуры.
Tarantool поддерживает их в Lua.
- Авторизация, сессии, счетчики.
- При необходимости: автоматический шардинг и отказоустойчивость, Raft/Paxos, длинные транзакции.
- Мало клиентов и минимальные требования к задержке.
Из-за конвейерной архитектуры задержка будет больше минимально возможной.
- Рабочий набор не помещается в память.
Костя Осипов просто сказал о новом движке Vinyl для Tarantool, но рекомендую сначала с ним ознакомиться.
- Ну и мое личное мнение: Tarantool не подходит для задач аналитики.
Несмотря на то, что он хранит все данные в памяти, он не сохраняет их так, как нужно для этих задач.
Кликхаус
Создан Яндексом специально для аналитики.Для таких систем, как Яндекс.
Аналитика, были необходимы следующие базы данных:
- эффективный и линейно масштабируемый.
- Аналитика в реальном времени.
- Бесплатный и с открытым исходным кодом.
Возможные решения:
- MySQL(MyISAM) – быстрая запись, медленное чтение
- Вертика, Эксасол - платная
- Hadoop — на запись работает, но чтение не в реальном времени.
Он уже опробован на производстве Яндекса.
ClickHouse поддерживает только вставку и запрос данных.
Никакого удаления или редактирования.
Данные хранятся в ежемесячных разделах.
В каждом разделе данные упорядочены по возрастанию первичного ключа.
«Первичный ключ» в данном случае не очень корректен, поскольку его уникальность не гарантируется.
Чтобы ускорить поиск по первичному ключу, ClickHouse использует файлы-«выемки», где один раз в определенном количестве записей делаются выемки со значением первичного ключа и местом его расположения.
Это позволяет выполнять запросы по диапазону первичного ключа с небольшим количеством дисковых операций.
Вставка происходит так.
Данные записываются во временный раздел, сортируются.
После этого фоновый процесс при остановке записи на некоторое время объединяет эти разделы.
Возможности ClickHouse:
- SQL ограничен JOIN.
- Репликация и работа в кластере.
Поддерживается, но надо попробовать.
- 17 (возможно, больше) алгоритмов выполнения Group by.
- Материализованные представления, глобальные JOIN.
- Пробы с выборкой.
Когда можно оптимально прочитать только часть данных.
Например, только для конкретного пользователя в Яндекс.
Аналитике.
- Задачи аналитики реального времени.
- Временная последовательность - github.com/yandex/graphouse
- Хранение сырых данных, которые ClickHouse может очень быстро агрегировать.
Показы, клики, журналы и т. д.
- Задачи OLTP (без транзакций)
- Работа с деньгами (без транзакций)
- Хранение агрегированных данных (нет смысла)
- Задачи Map/Reduce (многие из них прекрасно решаются с помощью SQL)
- Полнотекстовый поиск (не предназначен)
ТараканДБ
Предварительные условия для создания такие же, как и для Tarantool. База пользователей распределена по серверам.
И искать нужно, например, по электронной почте или телефону.
Но если Tarantool в нашем примере выступает таким высокоуровневым индексом шардов базы данных, то CockroachDB предлагает хранить всё самостоятельно.
Возможные решения CockroachDB: Облачный ключ Google Авторизатор + ручное шардинг (как мы уже рассматривали с Tarantool) MongoDB, Cassandra — не поддерживают распределенные уникальные индексы.
Изначально CockroachDB создавался как распределенное хранилище ключей-значений, но текущие реалии говорят о том, что новая база данных «ключ-значение» мало кому нужна.
Все хотят SQL. Он поддерживает SQL, JOIN, транзакции, ACID, уникальные индексы, автоматическое сегментирование.
Создано авторами Google Spanner. Написано на Го.
Прошел тестирование Jepsen практически с первого раза.
И он уже используется в производстве Baidu. Как реляционная модель вписывается в хранилище «ключ-значение»? Это можно сделать вручную довольно легко.
Я приведу сильно упрощенную версию.
В CockroachDB все немного сложнее.
Ключи довольно простые — имя таблицы/значение первичного ключа/имя поля.
Вторичные индексы также говорят сами за себя.
Еще один ключ с индексным именем.
В случае неуникального индекса вместе со значением первичного ключа.
Данные хранятся довольно тривиальным способом, но мне он кажется очень правильным.
Глобальная отсортированная карта «ключ-значение» разделена на регионы, размер которых база данных пытается поддерживать примерно в 64 МБ.
Каждый из этих регионов реплицируется на несколько узлов и один из этих узлов для региона является Raft-лидером, т.е.
вся запись (вероятно и чтение тоже) идет в него.
Теперь представим, что какой-то узел выпал.
Рафт позволяет быстро выбрать нового лидера для каждого региона.
Таким образом, будет доступно и письмо, и чтение.
Одной из основных особенностей является поддержка распределенных транзакций.
Когда необходимо транзакционно изменить данные на нескольких узлах.
Они реализованы так.
Есть системная таблица со списком транзакций.
При изменении значения ключа рядом с ним добавляется ключ с номером транзакции.
При чтении такого ключа просматривается таблица транзакций, чтобы увидеть, зафиксирована она или нет, и выбирается нужное значение.
Если фиксация прошла успешно, значения заменяются окончательными.
Неудачные транзакции очищаются сборщиком мусора.
В будущем CockroachDB вполне может использоваться в качестве основной базы данных большого проекта.
Сейчас еще рано, так как релиз 1.0 вышел совсем недавно.
Когда не использовать: Как вы могли заметить из описания алгоритма распределенных транзакций CockroachDB, этот процесс не быстрый.
Если проект требует низкой задержки или высокого количества запросов в секунду, оно того не стоит. Запись тоже не самая быстрая.
Если вам не нужна строгая последовательность.
Хотя для распределенной базы данных это довольно важный фактор.
Условно, если вам нужно отправить сообщение от одного пользователя другому, то записи об этом должны появиться как на сервере автора сообщения, так и на сервере человека, которому это сообщение было отправлено, причем желательно сделайте это атомарно.
В заключение хотелось бы сказать, что каждый инструмент нужно выбирать с умом, четко понимая задачи, которые он решает, и его ограничения.
Не слушайте меня и проверьте все сами.
В этом году тоже довольно интересный раздел Хранилище .
Приходите поделиться своим опытом.
Хабраридеры скидка .
Теги: #devconf #CockroachDB #tarantool #clickhouse #Высокая производительность #MySQL #oracle #postgresql
-
Планирование Черновиков В Yahoo
19 Oct, 24 -
Пилотажный Дрон. Как Правильно Сделать Бочку
19 Oct, 24 -
Lte В Омске
19 Oct, 24 -
Проектирование Простых Приложений В Flask
19 Oct, 24 -
Вр - Выпуск №38
19 Oct, 24
