Tarantool — гибкий инструмент для разработки высоконагруженных систем хранения данных. На нём пишут очереди, кеши и мастер-хранилища с разной топологией.Часто разработчики начинают работать с Tarantool, имея большой опыт работы с SQL, и пытаются применять привычные подходы из реляционных баз данных. В результате приложения становятся «хрупкими», теряют данные или деградируют в производительности.

Меня зовут Игорь, и сегодня я покажу, как антипаттерны влияют на производительность и стабильность приложений, и с какими пятью провальными решениями при разработке на Tarantool я столкнулся, работая с крупными продами. А также предложу способы избегания этих проблем.

Это текстовая версия доклада, который я рассказывал на HighloadFoundation 2022.

Map-reduce, который убивает select(nil)

Если вы когда-нибудь писали приложения на Tarantool, вы точно сталкивались с этой проблемой. Много продов легло из-за того, что разработчики забыли передать аргумент в вызов space:select().

Почему это так опасно: space:select() — аналог SELECT * в SQL. Он не отдаёт управление другим функциям, которые работают в Tarantool, пока не выберет все записи из спейса. Отменить эту команду после запуска не получится. И если вы случайно сделали select(nil) на большом спейсе, то получите full scan, который еще и выгружает данные в Lua-память, ограниченную двумя гигабайтами. Есть два варианта развития событий — либо закончится память, либо Tarantool на очень долгое время перестанет отвечать на запросы. select(nil) — гарантированный способ положить экземпляр Tarantool.

Как себя обезопасить? Во-первых, в select можно передавать параметр, который ограничит количество отбираемых записей, например, вот так:

space:select(nil, {limit = 1000})

Но лучше всего будет в этой ситуации использовать итератор pairs():

space:pairs():take_n(1000):totable()

Такой подход приучает разработчика явно указывать количество записей, которые нужно вытащить из спейса. А ещё итератор можно обернуть в функцию, которая будет периодически отдавать управление другому коду. Вот пример такой функции на Github.

Пагинация через смещение

Рано или поздно нам понадобится прочитать значительное количество данных из спейса, например, с помощью пагинации. Помня про space:pairs(), мы можем написать такой код:

space:pairs():drop_n(1000):take_n(1000):totable()

Кажется, что этот код должен пройтись по записям, начиная с 1000 и заканчивая 2000. Но на самом деле он пройдёт по записям 0-2000 и отбросит первые 1000. Если такой код попадёт в цикл, который должен считывать все данные из спейса, мы получим full scan. Он будет работать все хуже и хуже на каждой итерации и очень скоро превратится в select(nil).

Как правильно. В pairs() есть опциональные аргументы: ключ, по которому производится сравнение, и таблица с опциями, в которые можно передать { iterator = 'GE' }. Он позволит отобрать 1000 записей начиная с last_key.

space:pairs(last_key, { iterator = 'GE' }):take_n(1000):totable()

Фильтрация в cluster join

Даже после того, как мы починим все single node-запросы, перед нами останется проблема кластерных запросов. Давайте представим, что у нас есть БД SQL, в которой мы можем сделать такой запрос:

SELECT working_group, MIN(start_date)
FROM department JOIN employee
ON employee.employeeId = department.employeeId 
AND department.departmentId IN $departmentIds
WHERE employee.jobType = 1 OR employee.position = 'senior'
GROUP BY working_group

Попробуем переписать его на Tarantool:

function get_employee_aggregation(bucket_id, groupId, departmentIds)
    return yield_every(500, fun.iter(departmentIds)):reduce(function(acc, departmentId)
        yield_every(500, department.index.employment_date:pairs({groupId, departmentId}, 
            {iterator = 'REQ'})):each(function(y) 
                yield_every(500, employee.index.working_group:pairs({bucket_id, y.employeeId}, 
                {iterator = 'EQ'}))
                :filter(function(x) return x.jobType == 1 or or x.position == 'senior') end)
                :each(function(x)
                    if not acc[y.working_group] then
                        acc[y.working_group] = { 
                            working_group = y.working_group, 
                            start_date = x.start_date, 
                        }
                    end
                end)
            end)
        return acc
    end, {})
end

Такой код читать очень сложно, а при тестировании и отладке мы обязательно пропустим какой-нибудь corner-case, который выстрелит на проде. Подобный код может начать тормозить или стрелять ошибками 500 без явных причин. Может быть, не хватает передачи управления? Или какой-то из наших инструментов не очень хорошо подходит?


На самом деле мы просто написали неоптимальный код. Кластерные запросы — это сложно, и им можно посвятить отдельную статью. Здесь я покажу пример плохого JOIN’а и способ его исправления.

Пусть у нас есть кластер с двумя спейсами, по которым нам нужно сделать JOIN:

SELECT * FROM
SPACE_1 JOIN SPACE_2
ON SPACE_1.FK = SPACE_2.FK
WHERE …

Наивная реализация такого запроса может быть следующей:

1. Делаем SELECT из каждого узла.
2. Отправляем данные на router.
3. Делаем JOIN.

Какие проблемы у такого решения?

• Большие объёмы данных, которые нужно отправлять по сети.
• Может не хватить памяти для объединения данных.

Как можно починить?

Всё зависит от ваших данных. Например, можно достать из спейса только ключи, по которым выполняется объединение, и отправить их на router. Такие данные быстро передаются по сети и точно поместятся в память. Далее мы их объединяем на экземпляре router и получаем уменьшенное множество ключей.




Теперь эти ключи можно отправить в экземпляр storage и отобрать записи, которые подходят под них, а затем передать записи на router и вернуть клиентам итоговый JOIN.


Это всего лишь один из способов решения проблемы с кластерным объединением. Общие принципы проектирования запросов:

• Хранение связанных данных вместе уменьшит количество походов по сети.
• Фильтрация на storage снизит объём передаваемых данных.
• Агрегация на экземплярах router разгрузит экземпляры storage.
• Сортировка по индексу позволяет не сортировать данные второй раз.
• Использование temporary-спейсов полезно в случаях, когда нужно объединять большие объёмы данных.

Что посмотреть по теме

• space:select
• CRUD
• create_space
• Примеры

SPOF

Есть множество способов получения единой точки отказа в кластере. Рассмотрим вариант, от которого пострадал я сам, работая с одним из продов.


Представьте себе шардированный кластер, в котором есть отдельно стоящий узел. На нём хранятся словари — редко изменяемые данные, которые требуются для формирования ответов клиентам. Каждый запрос в кластере требует обращения к словарю:

SELECT * 
FROM SPACE JOIN DICTIONARY 
WHERE ...

Какие проблемы у такого решения?

Слишком много сетевых походов на один cluster JOIN. А если Dictionary не выдержит нагрузку, ведь каждый запрос в кластере требует обращения к этим данным? При увеличении количества запросов мы увидим, как Dictionary начнёт «мигать» и отвечать ошибками 500 на самые нетребовательные запросы. Ведь если нагрузка на остальные экземпляры storage распределена равномерно, то на Dictionary приходится гораздо больше запросов.


Как можно починить?

Например, объединить router и словари в один экземпляр Tarantool. Это избавит от необходимости ходить по сети лишний раз и сильно удешевит запросы.


Если у вас уже есть единая точка отказа, то можно повысить доступность словарей:

• поднять дополнительные реплики и балансировать запросы между репликами;
• если нужно писать словарные данные:

Что почитать по теме

• Документация vshard-роутера
• Масштабирование кластеров на Cartridge
• Примеры

Неструктурированные данные

Tarantool — очень гибкий инструмент, он позволяет хранить данные как форматированными, так и без формата. Давайте разберём ситуацию, когда нужно хранить массив данных, в который мы часто вносим изменения, и сравним два варианта: с форматом и без.

box.space.storage1:format({
    {name = 'key', type = 'string'},
    {name = 'data', type = 'any'},
    -- data: {name: string, value: number}
})

Чтобы поменять конкретное значение в массиве data, нужно пройтись по всем значениям в массиве:

local tuple = box.space.storage1:get('key')
for i = 1, 1000 do
    local v = tuple.data[i]
    if v.name == 'name' then
        v.value = v.value + 1
    end
    tuple.data[i] = v
end
box.space.storage1:put(tuple)

Этот код выполнялся у меня 0,397735 секунды — для высоконагруженных систем слишком много. Давайте посмотрим, как можно исправить ситуацию, и разобьём массив данных на структурированные кусочки:

box.space.storage2:format({
    {name = 'key', type = 'string'},
    {name = 'pos', type = 'unsigned'},
    {name = 'name', type = 'string'},
    {name = 'value', type = 'number'},
})

Теперь вместо одного обновления понадобится несколько:

box.begin() -- обернем все в транзакцию
for _, v in box.space.storage2:pairs({'key'}) do
    if v.name == 'name' then
        box.space.storage2:update({v.key, v.pos}, {{'+', 'value', 1}})
    end
end
box.commit()

Время выполнения 0,00036 секунды — это в 10 тыс. раз лучше предыдущего варианта!

Также при работе с неструктурированными данными можно не попасть в размер куска памяти, выделенного Tarantool для этих данных, и получить ошибку «Failed to allocate memory». Если вы с таким столкнулись, это можно исправить с помощью повышения параметра box.cfg slab_alloc_factor.

Что почитать по теме

• space:format
• slab_alloc_factor
• Примеры

Репликация мастер-мастер без триггеров

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


Как можно исправить?

Например, заранее разделить нагрузку между узлами и отправлять данные в экземпляр в зависимости от их первичного ключа. Или, что надёжнее, написать триггер для разрешения конфликта, в котором будем выбирать из конфликтующих записей более подходящую для сохранения. Это может быть запись, которая была создана раньше; или последняя; или та, данные в которой важнее по какому-нибудь параметру.

local my_trigger = function(old, new, _, op)
    if new == nil or old == nil then
        return new
    end
    if op == 'INSERT' then
        if new[2] > old[2] then
            return box.tuple.new(new)
        end
    elseif new[2] > old[2] then
        return new
    end
    return old
end

-- код для добавления триггера
-- позволит обрабатывать все записи, 
-- начиная с момента восстановления из snapshot'а
box.ctl.on_schema_init(function()
    box.space._space:on_replace(function(_, sp)
        if sp.name == 'test' then
            box.on_commit(function()                
                box.space.test:before_replace(my_trigger)
            end)
        end
    end)
end)

Теперь в случае конфликта в WAL попадёт только одна запись:

Что почитать по теме:

• Мастер-мастер репликация в Tarantool
• before_replace триггер
• Примеры

Транзакции перед подключением к реплике

Представьте ситуацию: в кластере перезапускается мастер под нагрузкой, вы проверяете сохранение последних записей и видите, что на мастере и на реплике данные разные. Что произошло?

Например, могло случится следующее: во время перезапуска по какой-то причине удалились xlog-файлы с последними записями, и мастер разрешил запись данных до того, как синхронизировался с репликой. В него сразу же начали писаться данные, а затем по репликационному потоку прилетели старые записи, которые вызвали конфликт из-за совпадающих LSN.


Как можно исправить? После перезапуска мастера необходимо дождаться подключения к реплике. В Tarantool за это отвечает опция box.cfg{replication_connect_quorum = N}, где N — количество реплик, к которым нужно подключиться перед разрешением записи. Чтобы не допустить проблем с началом записи до окончания синхронизации, в качестве N нужно выбрать количество всех узлов в наборе реплик.


Если нужно меньшее значение кворума, можете написать код, который запрещает запись до того, как значения box.info.vclock на всех узлах сойдутся.

Что почитать по теме

• Транзакции в Tarantool
• Репликация в Tarantool
• Примеры

Как не допустить проблем

• Заранее закладывать расширение таблиц и кластера. Объём данных всегда будет расти, а кластеры — расширяться, и архитектура приложений должна это учитывать.
• При разработке держать в уме подводные камни. Писать код без багов пока никто не научился, но можно пытаться их минимизировать.
• Тщательно проводить нагрузочное тестирование, максимально приближенное к реальным условиям эксплуатации. Это позволит выявить очень много проблем.
• Грамотный мониторинг поможет обнаружить возникновение проблем и проанализировать их.

Что дальше

• Узнайте про нагрузочное тестирование на K6
• Изучите мониторинг кластеров Tarantool
• Попробуйте Tarantool Cartridge в песочнице
• Погрузитесь в документацию на официальном сайте
• Задайте вопросы сообществу в Telegram-чате

Скачать Tarantool можно на официальном сайте, а получить помощь — в Telegram-чате.