Ади Гелван, генеральный директор и соучредитель Speedb, рассказывает на портале TechBeacon о движках данных (data engines) — части программного стека, которая сортирует и индексирует данные.
Команды DevOps знают, что надо делать: создать среду, подготовить инфраструктуру и согласовать все элементы для обеспечения производительности. Учитывая при этом перспективу роста и полностью осознавая, что по мере приближения приложения к производству использование и распределение ресурсов будут расширяться. Возможно, кто-то даже разделяет базы данных на части, чтобы было пространство для расширения. Все это работает, и все довольны.
Однако слишком часто объем требуемых ресурсов оказывается больше, чем предполагалось, и количество поддерживаемых пользователей тоже больше. Метаданные, эти крошечные кусочки данных о данных, растут быстрее, чем ожидалось, но поскольку большинство из них — это небольшие объекты, не занимающие много места в хранилище, прогнозируемая производительность и надежность выглядят хорошо, во всяком случае, на слайдах PowerPoint, представленных руководству. Но данные и метаданные продолжают расти, и команда понимает, что без ее вмешательства не хватит системных ресурсов для самих данных.
Командам необходимо рассмотреть движки данных — часть программного стека, которая сортирует и индексирует данные, — особенно если им требуется повысить производительность приложения и облегчить его масштабирование. Под капотом находится гораздо больше, чем многие думают, и тип структуры данных, используемой для метаданных, может накладывать ограничения, которые трудно преодолеть. Вот некоторые ключевые критерии, которые необходимо учитывать.
Что такое движок данных?
Даже опытные ИТ-ветераны часто бывают удивлены, узнав, какой движок данных используется для слоя под приложением и над хранилищем, и в большинстве случаев не знают о его возможностях и требованиях к его настройке.
Движок данных — это встроенное хранилище «ключ-значение» (KVS), которое сортирует и индексирует данные. Некоторые знают его как движок хранения — ПО, которое выполняет основные операции по управлению хранилищем, прежде всего, создание, чтение, обновление и удаление (CRUD) данных. Поскольку этот уровень выходит за рамки своей традиционной роли движка хранения, для описания более широкого спектра сценариев применения используется термин «движок данных».
За рамками CRUD: чтение vs. запись
Все больше организаций используют движок данных для выполнения «на лету» различных действий над данными, находящимися в процессе передачи. В такой реализации движки данных, такие как RocksDB, часто выполняют внутри приложения операции, выходящие за рамки CRUD. Например, они управляют нагрузками, требующими работы с метаданными, и предотвращают узкие места в доступе к метаданным, которые могут привести к проблемам с производительностью.
Хотя объемы метаданных, казалось бы, невелики, и они занимают небольшую часть хранилища по сравнению с самими данными, необходимость в субмиллисекундной производительности при работе с метаданными означает, что системы не могут допускать значительных узких мест без того, чтобы влияние на работу конечного пользователя не стало очевидным. Эта проблема особенно актуальна при работе с современными рабочими нагрузками, интенсивно использующими метаданные, такими как IoT и расширенная аналитика.
Структуры данных в KVS обычно относятся к одной из двух категорий: оптимизированные для быстрой записи и оптимизированные для быстрого чтения. Для хранения метаданных в памяти движки данных обычно используют древовидные KVS, основанные на журнально-структурированном слиянии (LSM). Структуры, использующие LSM, приспособлены для приложений с интенсивной записью, поскольку они могут очень быстро сохранять данные без необходимости внесения изменений в структуру данных благодаря использованию неизменяемых файлов SST (Sorted String Table). В противоположность этому, структуры данных на основе B-деревьев имеют преимущество в приложениях с интенсивным чтением.
К сожалению, DevOps не может сделать сразу две взаимоисключающие вещи. Хотя существующие структуры данных KVS можно настроить так, чтобы они были достаточно хороши для быстрой записи или чтения приложения, они не могут обеспечить высокую производительность для обеих операций одновременно.
Проблема может стать критической, когда наборы данных становятся большими или когда объемы метаданных вырастают настолько, что превосходят размер самих данных, что становится все более распространенным явлением. Организациям не требуется много времени, чтобы достичь точки, где они начинают выбирать между производительностью, емкостью и стоимостью.
Скользкая дорожка настройки производительности
При возникновении проблем с производительностью команды обычно начинают с перераспределения (решардинга) данных. Вскоре количество наборов данных увеличивается, и разработчики уделяют все больше времени парционированию данных и распределению их по шардам, и все меньше — задачам, которые приносят пользу бизнесу.
Далее команды могут попытаться настроить производительность базы данных, обычно применяя настройки по умолчанию, которые могут не подходить для приложений. Доработка — это итеративный и длительный процесс, причем даже опытным разработчикам бывает трудно достичь идеального баланса.
После настройки эти экземпляры могут испытывать дополнительные, более серьезные проблемы с производительностью при изменении рабочей нагрузки или базовых систем, особенно если приложения отклоняются от системной нормы. Это может создать бесконечный цикл дальнейшей настройки, отнимающий все больше времени разработчиков.
Для пущей убедительности команды могут бросить на решение проблемы дополнительные ресурсы хранения. Однако полученная выгода часто оказывается недолговечной, а затраты на постоянное добавление ресурсов не добавят устойчивости в долгосрочной перспективе.
Архитектура для изменений
Новые движки данных появились в ответ на требования к современным приложениям опережать рост данных. Движки данных нового поколения могут стать ключевым фактором, когда рабочие нагрузки с низкой задержкой и интенсивным использованием данных требуют значительной масштабируемости и производительности, как это часто бывает с метаданными.
Например, один известный поставщик структуры данных in-memory предлагает флэш-опцию интеллектуального объединения больших массивов данных. Благодаря ей команды DevOps могут использовать новые твердотельные накопители на базе энергонезависимой памяти Express вместо более дорогостоящих ресурсов DRAM.
С помощью этих новых движков данных можно значительно повысить производительность и масштабируемость и сделать их предсказуемыми в различных приложениях или в приложениях, где модель доступа меняется с течением времени. Поскольку команды DevOps часто не знают будущих моделей использования, гибкость в обеспечении стабильной производительности в различных условиях является преимуществом.
По мере того как команды DevOps расширяют применение микросервисных архитектур с низкой задержкой, открываются новые возможности движков данных для инноваций — сокращение вмешательства разработчиков и повышение производительности в масштабе при одновременном снижении сложности и затрат.
