Зачем и как ускорять работу с данными

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

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

«Терпеть не стоит, ускорять» или «терпеть, не стоит ускорять»

Любой ИТ-продукт так или иначе работает с данными. Но профили нагрузок и требования к системам в разных сценариях отличаются. Например, пользователи готовы подождать, пока будет отрисован график для презентации, пока приложение банка сформирует отчет о расходах за 5 лет или сервис найдет самый дешевый билет на курорт. Такие операции не имеют критического значения, и ожидание даже в десять секунд вполне допустимо.

Вместе с тем, есть кейсы, когда обработка данных должна выполняться «на лету», а пользователям (или системе) нужен мгновенный результат. Например, к недопустимым можно отнести задержки при:

• печати чеков;
• верификации оплаты услуг;
• аутентификации;
• просмотре банковских операций и баланса;
• подготовке профиля клиента в колл-центре и не только.

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

• защите от всех видов мошенничества (antifraud);
• сборе телеметрии с оборудования (станков, датчиков, приборов);
• машинном обучении;
• работе с видеопотоком (например, в системах распознавания лиц на проходных офисов и заводов);
• управлении электротранспортом и автономными функциями современных автомобильных систем.

В каждом из этих и еще десятках других сценариев задержки влияют на пользовательский опыт, лояльность аудитории, безопасность, бизнес-процессы и в результате сказываются на репутации и успешности компании.

Варианты хранения данных: ищем самый «быстрый»

Для хранения данных в ИТ-системах можно задействовать:

• процессор (может хранить кэш данных);
• оперативную память;
• диски;
• ленты.

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

Самый «быстрый» компонент для хранения — кэш процессора. То есть, если нужна самая быстрая база данных — нужно задействовать кэш процессора.

Далее в топе по скорости среди хранилищ — оперативная память. У нее скорость доступа к данным ниже, чем в кэше процессора, но все равно кратно выше, чем у твердотельных накопителей и, тем более, классических жестких дисков.

Соответственно, диски не могут обеспечить такую же скорость доступа к данным, как оперативная память или кэш.

Но здесь есть нюансы:

• кэши процессора ограничены в размерах;
• данные в оперативной памяти могут быть утеряны в случае сбоя оборудования (например, если - выключат свет);
• диски медленнее, но надежнее и вместительнее других вариантов.

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

• самолет — быстро, но малая грузоподъемность,
• поезд — универсальное решение, но хочется быстрее,
• корабль — медленно, только по воде, но с огромной вместимостью.

Что в итоге

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

Вариантов организации хранения в такой «связке» два.

• Хранить всю базу на медленных накопителях, и только «горячие» данные и индексы - в ОЗУ. Например, можно часть данных и служебную информацию хранить в памяти, а основной массив данных — на дисках. Также в памяти можно закэшировать часть данных, которые запрашивают часто. При этом, если работать нужно со всем массивом хранящихся данных, обеспечивать одинаково высокую скорость доступа к ним не получится.

• Хранить все данные в ОЗУ, а на диск делать копию, чтобы не потерять, если что-то пойдет не так. Оперативная память вмещает меньше информации, чем диск, но при этом доступен максимально быстрый поиск данных в базе данных. Создание копии на диск позволяет минимизировать риски потери данные в случае сбоя на стороне оборудования.

Важно еще понимать, что постоянное линейное вертикальное масштабирование хранилищ невозможно — есть порог исчерпания ресурсов. Соответственно, чтобы обойти эти ограничения, нужно отдавать предпочтение разработке высоконагруженных систем с горизонтальным масштабированием.

Таким образом, приоритетной моделью хранения для систем, где нужен мгновенный доступ к данным, является именно вариант с хранением всей информации в оперативной памяти, то есть резидентные СУБД.

Требования к хранилищу

В решениях, где скорость доступа к данным имеет критическое значение, важна не только модель хранения, выбранные носители и инфраструктура высоконагруженной системы, но и другие параметры — например, надежность, отказоустойчивость, управляемость.

Соответственно, помимо нужной комбинации носителей (оперативная память в сочетании с дисками), искомое хранилище должно соответствовать ряду требований:

• Последовательное выполнение операций (сериализуемость) — в таком случае не будет конкурентного доступа к данным, то есть процессы не будут мешать друг другу и «тормозить» отклик.
• Протоколирование операций на диск — гарантирует сохранение данных даже в случае сбоев.
• Реплицирование данных между несколькими узлами — повышает надежность и обеспечивает возможность работы с данными без простоя даже в моменты недоступности основного хранилища.
• Горизонтальное масштабирование или шардирование — чтобы выйти за ограничения физической инфраструктуры (серверов) по производительности, объему оперативной памяти и др.
• Встроенный язык программирования — чтобы можно было обрабатывать, анализировать и управлять данными непосредственно там, где они хранятся.

Такую комбинацию архитектуры, параметров и функций у себя «под капотом» сочетает Tarantool — технологическая платформа для построения решений по хранению данных.

Who is Mr. Tarantool

Tarantool объединяет экосистему продуктов для хранения данных разных типов и работы с ними. «Ядром» платформы является Tarantool Enterprise Edition — версия Tarantool, ориентированная на крупных клиентов, желающих построить нестандартные решения. Решение представляет собой основу для построения «умного» кэша и единого профиля клиента. Хранит комплексные типы данных с индексами и отношениями. При необходимости Tarantool позволяет использовать встроенный сервер приложений для реализации специфических сценариев обработки данных.

Tarantool предоставляет ряд преимуществ. Среди них:

• Высокая производительность благодаря in-memory технологиям.
• Отказоустойчивость распределенных хранилищ данных.
• Гарантия сохранности данных.
• Удобная установка и настройка кластера за счет интеграции с инструментами CI/CD.
• Удобная работа с хранилищем данных из бизнес-приложений.
• Поддержка от российского вендора. Соответствие требованиям ФСТЭК и наличие в реестре российского ПО.

Таким образом, Tarantool — универсальный инструмент, который может стать заменой для многих продуктов в используемых системах хранения.

Решения экосистемы Tarantool

Помимо платформы, в экосистеме Tarantool доступны коробочные инструменты, позволяющие быстро создать и настроить типовые сценарии для хранения и обработки данных.

Среди них:

• Tarantool DB. Мультипротокольная NoSQL СУБД на основе Tarantool Enterprise Edition. Подходит для проектирования и разработки высоконагруженных информационных систем, а именно высокоскоростных отказоустойчивых транзакционных хранилища данных. В июне 2024 года СУБД включена в Реестр российского ПО.
• Tarantool Queue Enterprise. Инструмент для быстрого создания очередей на базе in-memory платформы Tarantool Enterprise Edition. Подходит для передачи сообщений между компонентами распределенных приложений, потоковой передачи данных в режиме реального времени и других высоконагруженных систем. Решение позволяет использовать два варианта архитектур: SQ — классические очереди с возможностью настройки приоритетов, MQ — распределенные системы очередей со строгим порядком обработки событий. Tarantool Queue Enterprise можно применять в сценариях, где нужны: транспорт между микросервисами, real-time marketing, управление задачами, маршрутизация и балансировка, решения на базе cобытийно-ориентированной архитектуры, обработка заказов и не только.
• Tarantool Column Store. Колоночная транзакционно-аналитическая БД на основе Tarantool Enterprise Edition. Подходит для проектирования высоконагруженных систем для анализа данных в реальном времени. Подходит для применения в системах, которые решают задачи антифрода (защиты от мошенничества), real-time формирования отчетности, real-time marketing, BI, AI/ML, систем рекомендаций, кредитного скоринга.
• Tarantool Graph DB. Графово-векторная БД на основе Tarantool Enterprise Edition. Позволяет создавать высокоскоростные хранилища графов для анализа данных в реальном времени.

Решение адаптировано под системы антифрода, геосервисы, маркетинг реального времени, AI/ML, системы рекомендаций, кредитный скоринг и другие сценарии применения.

Выводы

Постепенно скорость доступа к данным и возможность их обработки «на лету» становится не преимуществом, а критической необходимостью. Особенно в системах, где контакт с пользователем кратковременный и принять решение или сформировать персональное предложение нужно «здесь и сейчас».

Чтобы обеспечить максимальную скорость работы с данными, нужен комплексный подход — как на уровне выбора архитектуры высоконагруженных систем и носителей «под капотом», так и на уровне реализации алгоритмов обработки запросов. То есть нужно хранилище, которое сочетает все соответствующие практики и параметры. И таким решением могут быть продукты экосистемы Tarantool.