Кардинально сжимаем память в NodeJS
Возможно некоторые знают аналогию с краном и плотиной — заткнуть протечку воды в кране на кухне это один инструмент, а вот в плотине — совершенно другой. Иногда нам надо переложить JSON из одного микросервиса в другой. Иногда JSON размером в пару гигабайт и ты ловишь ошибку с максимальным размером строки в V8.
Кейс из жизни — синхронизируем данные из стрима. Стрим очень деревянный, на HTTP в виде эдакого SSE — канал не закрывается, запрос не завершается сам по себе, данные летят по чуть-чуть, привычный нам JSON, по объекту, можно парсить библиотеками для стримов JSON или реализовать что-то своё. Так или иначе получаем набор данных. И всё хорошо. Но при первом подключении мы получаем слепок данных, текущий стейт, а потом летят обновления. И стейт прилетает пачкой в пару гигабайт JSON.
Пройдемся по порядку в вариантах решения проблемы.
Шаг 1 — в лоб
Нам прилетели данные, мы их парсим, создаем модели под сущности, пишем в базу по одному. Неплохо. Неплохо если там сотня объектов. Но вот если их тысяча — долго лить будем, да и какой-то ддос базы получаем. Неприемлемо.
Шаг 2 — балк
Отлично, чего нам писать в базу по одному, обычно мы имеем функциональность балк-записей в базу, запишем пачку за один раз. И это решает проблему, данные летят компактно. Только вот если объектов реально тысяча и они не в пару полей — тяжелый запрос в базу, надо бы как-то порезать. Да и пока пишем — надо ведь свежее прилетающее где-то хранить, нужен какой-то буффер.
Шаг 3 — массив
Хорошо, мы можем положить данные в массив, а потом забирать оттуда данные, пачками, а потом писать в базу. Хороший кейс, не делаем ддоса, свежие данные есть куда положить. Правда к базе можно подключаться пулом потоков, ну и пока мы ждем ответа — можно ещё данных заслать.
Бонус для любителей иммутабельности — если начать пересоздавать массив на каждое изменение, то мы умрем примерно вот на этом шаге. Увы, такие подходы подходят только для малых наборов данных, что свойственно, к примеру, для фронтенда, и это нормально и правильно. Но вот на тысячу толстых элементов у нас быстро закончится память и очистка мусора зашьется удалять старое на лету. Иммутабельность для массивов мы забываем на этом шаге.
Шаг 4 — пул
Хорошо, сделаем пачку циклов, либо рекурсий — будем доставать из буффера данные, балком писать в базу, ждать завершения и доставать ещё данные. Главное при выборе варианта с рекурсией не забыть что объявленая ещё в ES2015 поддержка хвостовых рекурсий так и не была завезена в V8 ноды и надо сделать разрыв для обхода ограничения на глубину рекурсий и потребление памяти из-за стека вызова, самый лучший вариант это setImmediate, потому что с промисами разрыва не будет, а на таймаутах мы получим толстый оверхед очереди таймера, слишком толстый чтобы не взять иммедиэйт. Или просто сделать цикл.
Всё хорошо у нас…, но на миллионе объектов мы получаем лютейшую просадку, что пошло не так?
Нам нужно знать порядок поступления данных — к нам приходит слепок, затем новые данные, это апдейты старых. Нам очень важно знать порядок. А это значит нам надо класть в массив с одной стороны, а вот забирать с другой. И это значит у нас будет pop и shift. И с pop у нас всё хорошо, мы забираем последний элемент, а вот с шифтом всё интереснее. Дело в том чтобы добавить что-то в начало массива — нужно передвинуть весь масив, буквально. Под капотом полетит перемещение каждого элемента вперед и потом добавление нового в начало. Могут быть внутренние оптимизации, но результат всегда один — адские тормоза на миллионе элементов.
Но что же делать? Ведь нам важен порядок, а что мы можем использовать кроме массива? С объектом не выйдет, мапы с итераторами… как ни странно, но работают, однако в определенный момент счетчик внутри ломается и что-то теряется, не так пишется. Только массивы могут нам обеспечить порядок данных, чтобы друг за другом. Можно решить через сдвигание не сразу, завести счетчик, очищать раз в минуту и прочие оптимизации, когда мы откладываем перемещение массива на потом. Они помогают, реально помогают, но не очень, да и память заполняется. У нас нет решения на основе типов данных JS, но, возможно, есть решения другого толка?
Шаг 5 — цепочка
И вот тут к нам приходят алгоритмы базовых собеседований. Чаще всего в жизни оно нам не нужно, но вот в такой задаче — как раз этот самый кейс. Ответ банален и смешон — односвязный список. Просто объект, узел, которых хранит значение и ссылку на следующий узел.
В итоге мы можем хранить ссылку на самый первый узел и самый последний. При приходе новых данных — мы создаем новый узел, берем ссылку на конец, берем этот концевой узел, прописываем ему ссылку на следующий узел как ссылку на наши новые данные, на наш новый узел, ну, а после обновляем нашу ссылку на конец, теперь она будет ссылаться на наши новые данные, свежесозданый узел. И так повторяем для каждого нового пришедшего слепка данных. Ну, а данные для записи в базу достаем из начала, по ссылке на первый узел, после меняем ссылку на начало — теперь это ссылка на следующий узел, которая хранилась в текущем узле. В конце обнуляем сслыку на следующий узел, открепляя взятый в работу узел окончательно. Дальше с ним разберется уже очистка памяти движка ноды, как только произойдет запись в базу и он выпадет из видимости функций записи. Элегантно, просто, эффективно.
В итоге мы никогда не имеем проблем с тем что нужно передвигать большие объемы данных, у нас нет проблем со всякими счетчиками, вообще нет даже такого понятия. Мы просто примитивно манипулируем ссылками на данные, а дальше V8 делает всё сам. Результат — у нас больше нет тормозов.
Но, о боже, к нам пришло пару гигабайт JSONа, сервера обзаводятся новыми планками оперативки, что же нам делать?
Шаг 6 — ключи
Не все знают, но понятие ключ-значение — это лишь удобство. Более того, у нас есть в живую примеры того как эта проблема решается — современные табличные базы данных. Дело в то что хранить ключи… совсем не обязательно. Мы можем хранить значения просто по порядку, массивом, главное точно соблюсти порядок. А вот ключи мы можем не хранить в данных вовсе, лишь знать по бизнес-логике по какому номеру какие данные лежат. Чего уж там — в базу данных мы можем записать данные таким же образом, массивом, такой синтаксис поддерживается, ключи не нужны. Казало бы простая мысль, но осознаешь это не сразу, ведь пришел JSON с ключами… ну… так и сохраним. Однако когда у нас есть буффер и он очень большой — удаление ключей в процессе парсинга экономит память иногда кратно, кейс из жизни — уменьшение потребления оперативки в 2 раза. Да, для этого у нас должна быть схема данных, если это произвольный JSON — не получится, однако, за исключением специфических кейсов, всегда есть определенный формат апи, тем более в базу как-то кладем. Если там есть колонки — значит нам уже есть где поиграться с такой оптимизацией. А ещё лучше — если поставщик данных сразу пришлет данные в виде массивов, но не всегда можно влиять на поставщика.
Бонус
Также мы можем хранить некоторые данные в типизированных буферах, типе данных в ноде для всяких бинарных вещей и, при некоторых кейсах, мы можем этим пользоваться, однако, использование такого может быть и во вред, конвертация туда-сюда может выйти затратной. Так что этот пункт только для узких применений.
Результаты
Таким вот набором шагов мы можем выживать в случае получении пачек данных в гигабайтах и выживать, при этом, без боли, без магии, без костылей — просто правильные структуры данных и алгоритмы. Обычно это нам не нужно, и всё же когда оно нужно — об этом эта статья. Без такой оптимизации работа подобного сервиса не возможна просто физически — не поместится в память, ддос базы, оверхед в перемещении в часах перемалываний. Не реализуема в лоб принципиально. А с нашими шестью шагами — быстро, эффективно, экономно. Красиво.
