Команды начинают искать базу данных HTAP, когда приложению требуется ответ, которого у хранилища данных еще нет. База данных для обработки транзакций в реальном времени (OLTP) фиксирует заказ, задача захвата измененных данных (CDC) копирует его в хранилище через несколько минут, а тем временем проверка на фрод или резервирование запасов, которым требовались эти данные, уже выполнились на устаревших цифрах. Гибридная база данных для транзакционной и аналитической обработки (HTAP) выполняет транзакцию и анализ на одних и тех же актуальных данных, включая строку, записанную мгновение назад, и многолетнюю историю за ней, благодаря чему этап копирования больше не нужен. В этом руководстве объясняется, что такое база данных HTAP и какие возможности она открывает. Затем в нем описываются пять тестов, которые следует провести перед выбором, и объясняется, почему продукты с меткой HTAP показывают в них разные результаты.
База данных HTAP выполняет транзакции и аналитические запросы к одним и тем же данным в единой системе, поэтому запрос может прочитать строку сразу после фиксации записавшей ее транзакции. Чтобы выбрать подходящее решение, проведите пять тестов на вашей собственной рабочей нагрузке: свежесть данных после фиксации, задержка транзакций под аналитической нагрузкой, параллелизм для произвольных (ad hoc) запросов, фиксируются ли чтение и управляемая им запись вместе, а также совокупная стоимость с учетом хранения истории.
Тест
Что измерять
Почему это важно
Что фиксировать
1. Свежесть
Время от фиксации транзакции до момента, когда аналитический запрос увидит строку при пиковой нагрузке на запись
Решение, принятое во время задержки, опирается на устаревшие данные
Задержка на уровнях p50 (медиана) и p99 (99-й перцентиль) при пиковой и двукратной пиковой нагрузке
2. Изоляция
Задержка транзакций с аналитической нагрузкой и без нее
Аналитика, замедляющая транзакции, в итоге исключается из продукта
p99 задержки транзакций и пропускная способность — отдельно и под нагрузкой
3. Параллелизм
Предустановленные и произвольные (ad hoc) запросы при растущем уровне параллелизма
Приложения и агенты задают вопросы, которые никто не составлял заранее
p99 при целевом уровне параллелизма; точка, в которой задержка начинает расти
4. Согласованность
Две сессии считывают одну и ту же итоговую сумму и выполняют запись на ее основе
Без этого два покупателя могут одновременно зарезервировать последнюю единицу товара
Блокируются ли конфликтующие записи и какова цена этой блокировки
5. Стоимость
Исторические данные в сравнении с недавними; копии, от которых вы отказываетесь
Именно на хранении истории архитектуры in-memory становятся дорогими
Задержка на данных годичной давности, стоимость за ТБ, экономия от отказа от лишних копий
Если вы уже используете базу данных HTAP или распределенную СУБД SQL и рассматриваете возможность ее замены, два раздела ближе к концу статьи освещают вопросы, которые обычно определяют такое решение: насколько сильно придется изменить приложение и как оценить безопасность вендора, который будет его обслуживать.
Что такое база данных HTAP?
Большинство компаний выполняют два типа работы с базами данных. OLTP фиксирует каждое событие по мере его возникновения: заказ, платеж, сделку, вход в систему. Оперативная аналитическая обработка (OLAP) отвечает на вопросы сразу по множеству записей, например, о выручке по регионам за этот квартал или о расходах клиента за три года. На протяжении десятилетий эти два типа выполнялись в разных системах, и аналитическая сторона работала с копией транзакционных данных возрастом от нескольких минут до суток.
База данных HTAP выполняет оба типа работы в одной системе и на одной копии данных. Когда транзакция фиксируется, следующий аналитический запрос уже включает ее — без промежуточных конвейеров и без необходимости синхронизировать вторую копию.
Отказ от копий сберегает средства, поскольку каждый кэш, реплика для чтения и конвейер CDC, существовавшие только для ускорения аналитики, больше не нужны. Более крупный выигрыш — это рабочая нагрузка, которую ни одна из систем не могла бы выполнить по отдельности: решение, которое анализирует актуальные данные вместе с историей и записывает результат на том же этапе. Эмитент карт одобряет или отклоняет платеж прямо во время ожидания клиента, проверив операцию на основе транзакций за последние несколько минут и истории счета. Ритейлер резервирует товар только после подтверждения его наличия. Крупный американский банк, использующий SingleStore, перенес выявление мошенничества с ночной пакетной обработки на момент оплаты картой и теперь выполняет около 70 запросов за 50 миллисекунд в рамках отведенного 1-секундного лимита на одобрение.
Агенты, работающие с бизнес-данными, имеют аналогичные требования. Агенту, перенаправляющему отправление или накладывающему ограничение на аккаунт, необходимо актуальное состояние бизнеса, а его действие меняет это состояние для следующего агента и следующего клиента. Насколько далеко предприятия зайдут в предоставлении агентам полной автономии — вопрос открытый, но действующим агентам потребуется то же самое, что сегодня требуется для проверки на фрод.
OLAP против OLTP: почему эти две нагрузки были разделены
OLTP и OLAP требуют принципиально разного расположения данных. Нагрузка OLTP записывает или обновляет по одной записи за раз и читает отдельные строки по ключу тысячи раз в секунду, что отлично подходит для построчного хранения (row store), сохраняющего все поля записи вместе. Нагрузка OLAP читает несколько колонок по миллионам строк, что подходит для поколоночного хранения (column store), считывающего только указанные в запросе колонки и хорошо их сжимающего. На сервере с вращающимися жесткими дисками, обеспечивающими лишь несколько сот случайных чтений в секунду, крупный отчет вытеснял из кэша страницы, необходимые для транзакций, и замедлял их на все время своего выполнения. Компании разделили эти задачи. База данных OLTP оставалась основной системой учета (system of record), а процесс извлечения, преобразования и загрузки (ETL) или поток CDC копировал изменения в хранилище для анализа. В результате любой аналитический ответ отражал состояние бизнеса на момент последнего копирования.
Оборудование, лежавшее в основе этого разделения, изменилось. Память стала на порядки дешевле в расчете на гигабайт по сравнению с началом 2000-х годов, а твердотельные накопители NVMe обеспечивают сотни тысяч случайных чтений в секунду. Поколоночное хранение, векторизованное выполнение и компиляция запросов сделали незапланированные аналитические запросы достаточно быстрыми для выполнения прямо внутри приложения. Теперь база данных может хранить как строки, так и колонки для одной и той же таблицы и выполнять обе нагрузки на одной копии данных, что и делает возможным принятие описанных выше решений. В наших руководствах по OLAP против OLTP и базам данных HTAP эти определения разбираются более подробно.
Признаки того, что вашей рабочей нагрузке нужна база данных HTAP
Большинство команд находят кандидатов на внедрение HTAP среди обходных решений, которые они уже используют. Четыре из них встречаются чаще всего.
- Кэш или реплика для чтения, существующие только ради скорости. Кто-то разместил кэш перед базой данных или направил дашборд на реплику, потому что основная БД не справлялась с одновременным чтением и записью. Каждое такое решение — это еще одна копия, которая может рассинхронизироваться с основной системой учета.
- Конвейер данных, за задержкой которого следит бизнес. Если инженеру приходит оповещение, когда поток CDC отстает, значит, бизнес уже платит за использование устаревших данных.
- Аналитика, удаленная из продукта. Отчет об использовании для клиентов был вырезан или ограничен вчерашними данными, потому что его запуск на основной БД замедлял оформление заказа.
- Две системы, показания которых расходились. Хранилище данных и система заказов показывали разное количество товаров на складе, либо отчет по рискам и торговая система показывали разный уровень риска, и кому-то пришлось потратить полдня на их сверку.
Некоторые команды пошли еще дальше и построили лямбда-архитектуру, the pattern Nathan Marz described in 2011 , с пакетным слоем для точных результатов по всем данным и скоростным слоем для приблизительных результатов по недавним данным. Это обеспечивает свежие ответы ценой двух путей выполнения кода, вычисляющих одну и ту же метрику, причем они расходятся всякий раз, когда в одном из них возникает баг.
Один вопрос отделяет эти рабочие нагрузки от тех, с которыми потоковый процессор справляется лучше: можете ли вы перечислить каждый вопрос, который приложение задаст до поступления данных, и является ли этот список достаточно коротким, чтобы вычислять каждый ответ по мере прохождения событий? Подсчет неудачных попыток входа для каждого аккаунта за последние пять минут успешно проходит этот тест, поэтому потоковый процессор может поддерживать актуальность счета. Поиск ожидающих заказов клиента, затронутых сегодняшними задержками перевозчика, с объединением по трехлетней истории возвратов, обычно не проходит этот тест, потому что комбинаций клиента, перевозчика и временного окна слишком много, чтобы вычислять их заранее. Для такого вопроса нужна база данных, которая выполняет произвольный запрос к живым данным.
Перед сравнением продуктов запишите, какое решение питают ваши данные и во сколько обходится устаревший ответ. Насколько устаревшими могут стать данные до того, как изменится результат? Требуется ли для запроса объединение актуальных записей с историческими? Сколько людей, сервисов и агентов будут запрашивать данные одновременно? Ответы задают пороговые значения для прохождения последующих тестов.
Что тестировать при выборе HTAP-базы данных
Каждый вендор в этой категории пишет HTAP на странице продукта. Пять измерений на вашей собственной рабочей нагрузке позволят отличить их друг от друга быстрее, чем список функций. Каждый тест ниже описывает, почему это важно, как его запустить, что говорит результат и как с этим работает SingleStore, а в конце приводится показатель, который нужно записать. Показатели задержки используют 99-й перцентиль (p99) — время, в течение которого завершаются 99 из каждых 100 запросов, так как среднее значение скрывает медленные запросы, по которым происходит таймаут.
Сколько времени после фиксации транзакции (commit) аналитические запросы могут видеть эту строку?
Почему это важно. Актуальность — это разрыв между фиксацией транзакции и чтением ее результата аналитическим запросом, и любое решение, принятое в этот промежуток времени, опирается на данные, которые уже устарели. Для аналитики реального времени на дашборде несколько секунд задержки редко имеют значение. Для проверки, которая одобряет или блокирует платеж, те же несколько секунд решают, увидела ли проверка предыдущий платеж.
Как это протестировать. Измерьте сквозную производительность под нагрузкой. Воспроизведите скорость записи в продакшене в часы пик, включая всплески, и опрашивайте аналитическим запросом маркерные строки с временными метками. В простаивающей системе практически любая архитектура показывает задержку близкую к нулю, а собственная метрика приема данных в базе данных может выглядеть отлично, в то время как запросы все еще видят старые данные.
Что говорит результат. Архитектуры, которые реплицируют строки в отдельную колонно-ориентированную копию, имеют задержку, определяемую репликацией, и она имеет тенденцию увеличиваться во время всплесков записи, когда решения по мошенничеству и запасам принимаются наиболее интенсивно. Пока реплика догоняет данные, аналитическое чтение либо ждет, что увеличивает его задержку, либо возвращает более старые данные. Спросите, как именно поступает продукт, как операторы видят задержку и что с ней происходит после перезапуска.
В SingleStore. Транзакции и аналитические запросы читают одни и те же таблицы в рамках одного движка, поэтому строка становится видимой для аналитических запросов в момент фиксации ее транзакции. Здесь нет реплики, которую нужно догонять, поэтому объем записи не увеличивает разрыв. Задержка запросов все равно возрастает под нагрузкой, и тесты 2 и 3 измеряют это.
Запишите: задержку от фиксации до запроса на p50 и p99 в пиковой нагрузке и при удвоенной пиковой нагрузке.
Тормозит ли аналитическая нагрузка транзакции?
Почему это важно. Когда большой отчет замедляет оформление заказа или одобрение платежа, обычным решением является ограничение отчета, и аналитика вытесняется из продукта. HTAP-база данных должна запускать обе рабочие нагрузки, не заставляя делать такой выбор.
Как это протестировать. Запустите транзакционную рабочую нагрузку отдельно и зафиксируйте ее задержку p99 и пропускную способность. Затем запустите рядом аналитическую нагрузку и снова запишите оба показателя. Используйте запросы, которые приложение и аналитики запускают в продакшене — короткие выборочные поиски, а также большие соединения (joins) и сканирования — на данных с продакшн-объемом и распределением (skew). Небольшой синтетический набор данных скрывает состязание за ресурсы, которое проявляется в продакшене. Завершите тест запуском заведомо тяжелого запроса в пиковые моменты записи.
Что говорит результат. Любая HTAP-архитектура платит за изоляцию в том или ином месте. Реплика обеспечивает хорошую изоляцию, поскольку сканирование выполняется на других машинах, но расплачивается за это актуальностью данных и наличием второй копии. Единый движок разделяет аппаратные ресурсы, поэтому результат зависит от управления рабочей нагрузкой: может ли база данных ограничить аппетиты аналитических запросов до того, как это почувствуют транзакции. Скачок p99 транзакций при запуске тяжелого запроса означает, что лимиты отсутствуют или настроены неправильно.
В SingleStore. Обе рабочие нагрузки выполняются в одном движке, поэтому изоляция — это компромисс архитектуры и предмет для мониторинга в тестах. Пулы ресурсов ограничивают память, процессор и параллелизм, доступные для определенного класса запросов, а управление рабочей нагрузкой ставит запросы в очередь при нехватке ресурсов. Настройте их перед тестом; запуск тяжелого запроса покажет, достаточно ли этого.
Запишите: p99 и пропускную способность транзакций отдельно и при запущенной аналитической нагрузке.
Сколько аналитических запросов могут выполняться одновременно при заданном целевом уровне задержки?
Почему это важно. Аналитические запросы бывают двух видов. Предустановленные запросы пишутся заранее и выполняются по расписанию, например запросы на дашборде, поэтому база данных может предварительно вычислить их ответы с помощью материализованных представлений или кэшей. Специальные (ad hoc) запросы создаются аналитиком, приложением или агентом в момент, когда нужен ответ, и предварительные вычисления здесь не помогут, поскольку никто не знал вопрос заранее. Один запрос к приложению или агенту может превратиться в множество ad hoc запросов, а команды начинают запускать целые парки агентов одновременно, поэтому расчет только на текущую нагрузку дашборда, скорее всего, окажется заниженным.
Как это протестировать. Запустите оба вида вместе: предустановленные запросы дашборда плюс ad hoc запросы, написанные во время теста для живых таблиц. Увеличивайте количество одновременных запросов шагами и отмечайте, где начинает расти задержка.
Что говорит результат. Если предустановленные запросы удерживают свою задержку, в то время как ad hoc запросы замедляются, база данных выдает ответы, вычисленные ранее, и сканирует все остальное. Уровень параллелизма, при котором p99 для ad hoc запросов пересекает вашу целевую отметку, является реальной емкостью системы для приложений и агентов.
В SingleStore. Новые записи попадают в память в виде строк и фоновым процессом объединяются в сжатые проиндексированные колонки той же таблицы. Индексы и статистика по сегментам позволяют новому вопросу считывать только те срезы данных, которые выбирают его фильтры, вместо сканирования целых таблиц, что поддерживает низкую стоимость каждого ad hoc запроса по мере роста параллелизма.
Запишите: аналитическую задержку p99 при целевом уровне параллелизма отдельно для предустановленных и ad hoc запросов, а также уровень параллелизма, при котором задержка начинает расти.
Могут ли чтение и порожденная им запись зафиксироваться в одной транзакции?
Why it matters. Many decisions are a read followed by a write that depends on it: count the stock, then reserve a unit; check a trader's exposure, then place the trade. When the read and the write commit in one transaction against one state of the data, two buyers can't both reserve the last unit, and two trades can't each pass a risk check that together they breach. A dashboard doesn't need this guarantee. Any workload that reads and then acts on what it read does, and HTAP comparison pages rarely test for it.
Как это протестировать. Попросите вендора объяснить его гарантии применительно к вашим собственным операциям, в том числе то, что видит приложение во время аварийного переключения. Затем воспроизведите их: напишите небольшую параллельную рабочую нагрузку, в которой две сессии читают одну и ту же сумму и выполняют запись на ее основе, и проверьте, разрешит ли база данных успешное выполнение обеих операций в ситуации, когда должна только одна. Обратите внимание на то, что пришлось сделать приложению для блокировки конфликта, например выбрать уровень изоляции или заблокировать прочитанные строки.
Что показывает результат. Архитектуры, использующие раздельные движки поверх общего хранилища, разделяют данные, но аналитический и транзакционный движки выполняют транзакции отдельно. При низких объемах тестирования конфликт возникает редко. В продакшене он проявляется в виде проданного сверх нормы заказа, превышенного лимита или задачи сверки, которую кто-то запускает каждое утро.
В SingleStore. Транзакции и аналитика выполняются в едином движке, поэтому анализ и инициируемое им обновление фиксируются совместно для одного состояния данных. Проверка рисков и размещение сделки, либо учет запасов и их резервирование — это единый шаг.
Зафиксируйте: предотвращаются ли конфликтующие записи и что пришлось сделать приложению для их предотвращения.
Какова стоимость всей архитектуры с учетом истории?
Почему это важно. Обычное возражение против систем in-memory HTAP — стоимость. Если данные должны храниться в оперативной памяти, хранение истории за несколько лет обходится дорого, и для архитектур, удерживающих там все данные, это возражение справедливо. База данных — это лишь часть затрат. Современный стек несет в себе издержки на конвейеры CDC , кэши и реплики , а также на рабочее время инженеров, затрачиваемое на поддержание копий в актуальном состоянии.
Как это протестировать. Запустите один и тот же запрос на данных прошлой неделя и на данных годичной давности, а затем сравните задержку. Оцените стоимость хранения в расчете на один сохраненный терабайт. Затем перечислите копии, которые база данных HTAP позволила бы вам отключить, указав годовую стоимость каждой из них, и подтвердите полученные цифры на тестируемой рабочей нагрузке.
Что показывает результат. База данных HTAP отключает одни копии и оставляет другие, поэтому учитывайте только те, которые вы бы отключили. Если данные годичной давности работают быстро только потому, что находятся в оперативной памяти, стоимость хранения будет расти вместе с историей. Если старые данные обходятся дешево, но работают медленно, проверьте, действительно ли они нужны для принимаемых вами решений.
В SingleStore. Данные автоматически распределяются по трем уровням. Каждое новое изменение попадает в память и становится видимым в момент фиксации. Недавно использованные данные располагаются на локальных накопителях NVMe для быстрой аналитики и поиска, а полная история хранится в объектном хранилище за малую долю стоимости. Никакие конвейеры или задачи архивирования не перемещают данные между уровнями, а запрос возвращает один и тот же результат независимо от того, на каком уровне находятся данные; меняется только стоимость получения ответа. Затраты зависят от активности, а не от объема данных.
Зафиксируйте: задержку запроса к данным годичной давности по сравнению с тем же запросом к данным прошлой недели, стоимость хранения в расчете на сохраненный терабайт и годовую стоимость каждой копии, которую вы бы вывели из эксплуатации.
Чем отличаются архитектуры HTAP
Продукты, продаваемые как HTAP или как замена ему, используют по меньшей мере пять различных архитектурных подходов, и они по-разному показывают себя в пяти тестах. Какой бы подход ни использовал вендор, спросите, куда попадают записи и как они становятся видимыми для аналитических запросов. Каждый из приведенных ниже подходов подходит для определенных рабочих нагрузок и не справляется с другими.
Один движок с унифицированным хранилищем строк и столбцов. Записи попадают в память в виде строк и в фоновом режиме объединяются в сжатые столбцы той же таблицы, причем обе рабочие нагрузки выполняются в рамках одного движка для единого состояния данных. Это подходит для сценариев, где анализ «живых» данных и принятие мер по его результатам происходят за один шаг. Обе рабочие нагрузки используют одно и то же железо, поэтому данный подход не подходит, если аналитическая нагрузка не регулируется, и здесь ключевым является тест 2. SingleStore использует именно эту архитектуру и владеет патентами на свое унифицированное хранилище строк и столбцов, а также на разделение хранилища и вычислений. Мы подробнее рассматриваем эту архитектуру в разделе «Одна копия, один движок, никаких швов».
Первичная база данных со строковым хранением и столбцовая реплика. Транзакции выполняются на узлах строкового хранения, а репликация поддерживает столбцовую копию на отдельных узлах, поэтому сканирование не может замедлить транзакции. Это подходит для рабочих нагрузок, чьи аналитические запросы могут терпеть задержку репликации или ожидать ее. Подвержен сбоям при всплесках записи, когда реплика отстает, а аналитические чтения либо ожидают, либо возвращают устаревшие данные, а также в плане стоимости, поскольку данные хранятся дважды. Возможность для чтения на реплике разделить транзакцию с записью на первичном узле зависит от конкретного продукта, поэтому запустите тест 4.
База данных со строковым хранением и столбцовым кэшем в оперативной памяти. Некоторые устоявшиеся OLTP-базы данных могут хранить в оперативной памяти столбцовую копию выбранных таблиц. Для приложений, уже работающих на одной из таких баз, это самый дешевый вариант внедрения, однако у него есть три слабых места. Кэш охватывает только те таблицы, которые помещаются в память первичного узла, поэтому запрос, уходящий вглубь истории, выполняется со скоростью строкового хранилища. Аналитическое сканирование использует те же процессоры, что и транзакции, поэтому тяжелый отчет в часы пик сказывается на задержке транзакций. Обе рабочие нагрузки также ограничены емкостью первичного узла, поэтому при превышении объемов записи аналитика упирается в тот же предел.
Раздельные движки поверх общего хранилища. Транзакционный движок выполняет запись в уровень хранения, который сохраняет недавние данные в виде строк и преобразует их в столбцовые файлы в открытом формате, которые аналитические движки читают напрямую. Здесь нет необходимости запускать конвейер, каждый движок масштабируется независимо, а несколько аналитических инструментов могут читать одни и те же файлы. Это слабое место по двум пунктам. Аналитический движок видит запись только тогда, когда она становится доступной в формате, читаемом этим движком, поэтому уточните, сколько времени это занимает в часы пик, и выполните тест 1. Кроме того, транзакционный и аналитический движки выполняют транзакции отдельно, поэтому решение, которое сначала производит анализ, а затем запись, не может зафиксироваться атомарно. Некоторые вендоры сегодня преподносят эту архитектуру как преемника HTAP, и пять тестов — отличный способ сравнить их.
Составной стек. База данных OLTP остается без изменений. CDC передает потоком ее изменения в таблицы Apache Iceberg, поверх которых в качестве индекса работает движок быстрой аналитики. Сторонники такого подхода утверждают, что это обеспечивает HTAP за счет композиции, и для многих рабочих нагрузок это утверждение справедливо: каждая часть масштабируется сама по себе, а история в объектном хранилище обходится недорого. Это лучше всего подходит, когда вопросы известны заранее, а целевой показатель свежести оставляет запас времени для конвейера. У этого подхода есть недостатки в плане свежести, которая определяется задержкой CDC, а также в отношении решений, которые читают из одного движка и пишут в другой, поскольку каждый движок хранит собственную копию и они не могут зафиксироваться атомарно. Мы более подробно рассматриваем этот подход в материале «Почему реальное время и ИИ разрушают классический стек данных».
В этой таблице каждая архитектура сопоставлена с пятью тестами. Рассматривайте ее как отправную точку для вопросов вендорам, поскольку продукты в рамках одной архитектуры различаются.
Архитектура
Свежесть после фиксации
Транзакции при аналитической нагрузке
Спонтанная параллельность
Чтение и запись в одной транзакции
Стоимость истории
Один движок, унифицированное хранилище строк и столбцов
Видно в момент фиксации
Зависит от управления рабочей нагрузкой
Индексированные столбцы
Да
Многоуровневое хранилище в объектном хранилище
Первичный узел со строковым хранением плюс столбцовая реплика
Задержка репликации
Изолированы на отдельных узлах
Зависит от движка репликации
Зависит от продукта
Данные хранятся дважды
Строковое хранилище со столбцовым кэшем в памяти
Зависит от продукта
Использует ресурсы первичного узла
Ограничено одной первичной памятью
Да
Ограничено первичной памятью
Отдельные движки с общим хранилищем
Зависит от того, когда операции записи попадают в аналитический формат
Изолировано в отдельном вычислении
Зависит от аналитического движка
Не между движками
Низкая, в объектном хранилище
Составной стек
Задержка CDC, от секунд до минут
Изолировано в отдельных системах
Быстро для запросов, под которые построен индекс
Низкая, в объектном хранилище
Сколько кода вашего приложения придется изменить?
Если вы уже используете HTAP или распределенную SQL-базу данных, стоимость перехода может определить финальный выбор сильнее, чем любой бенчмарк. Проверьте пять уровней, примерно от самых дешевых до самых дорогих в плане изменений.
- Драйверы и соединения. Если кандидат поддерживает сетевой протокол, который ваше приложение уже использует, существующие драйверы и пулы соединений продолжат работать. SingleStore совместима с сетевым протоколом MySQL, поэтому приложения, созданные на драйверах MySQL, могут подключаться без новых клиентских библиотек.
- SQL-диалект. Совместимость на уровне протокола не гарантирует, что каждая функция и тип данных ведут себя одинаково. Запустите суточный лог реальных запросов приложения против кандидата и посчитайте, что завершается ошибкой или возвращает другие результаты. Этот список и есть оценка миграции; страница совместимости вендора — это лишь отправная точка.
- Макет данных. Распределенные базы данных размещают данные по-разному. Некоторые автоматически делят таблицы на диапазоны; другие распределяют каждую таблицу по выбранному вами ключу шардирования, который определяет, какие соединения (joins) выполняются на одном узле, а какие передают данные по сети. SingleStore использует ключи шардирования, поэтому заложите время на проектирование для самых больших таблиц и наиболее важных соединений при миграции с базы данных, которая автоматически делит диапазоны за вас.
- Поведение транзакций. Уровни изоляции и семантика повторных попыток различаются в разных базах данных, и код, написанный под одно поведение, может незаметно сломаться на другом. Внимательнее всего изучите код, который повторяет попытки при конфликтах или полагается на чтение собственных записей.
- Перемещение данных. Спланируйте начальную загрузку и CDC-поток из текущей системы, чтобы они могли работать параллельно, пока вы проверяете результаты перед переключением. Проверьте, как коннектор ведет себя при перезапуске или изменении схемы, и оставьте пути для отката на случай сбоя переключения.
Совместимость драйверов мало что говорит о планах запросов. Запустите тесты производительности для мигрированных запросов в исходном виде, до того как кто-либо начнет их настраивать или переписывать, иначе концептуальная проверка (PoC) в итоге будет оценивать результаты переписывания. Также назначьте команду, отвечающую за каждое изменение, так как миграция без ответственного обычно застопоривается на первой же необходимости переписать код.
Ваша команда сможет обслуживать ее и обеспечить безопасность?
База данных, которая проходит все тесты производительности, все равно может не подойти команде, которой предстоит ее эксплуатировать. Проверьте, как операторы будут видеть задержку приема данных и диагностировать сбои, и отрепетируйте восстановление перед запуском в продакшен. Управляемые (managed) и самостоятельно управляемые (self-managed) развертывания распределяют эту работу по-разному, поэтому сопоставьте их с вашим штатом сотрудников и необходимым уровнем контроля. SingleStore работает как управляемый сервис SingleStore Helios или в рамках самостоятельного развертывания в вашей среде.
Никакой сертификат не доказывает, что система безопасна. Он лишь показывает, какие средства контроля проверял аудитор и за какой период, а приведенные выше вопросы покрывают все остальное.
