Югабайт спонсировал этот пост.
Поскольку предприятия вкладывают постоянно растущий процент своего технического бюджета в ИИ, они ожидают, что это обеспечит новаторскую эффективность и более информированную принятие решений. Но есть проблема, которую многие не увидят: задержка.
Чтобы системы искусственного интеллекта были полезными, они должны быть в состоянии быстро получить доступ и обрабатывать данные, независимо от того, генерируют ли они контент, классифицируют данные или принимают решения в режиме реального времени. Каждая миллисекунд имеет значение. Корская причина отставания во многих трубопроводах ИИ не является моделью или вычислительным слоем; Это база данных.
Подключение AI-Latency: почему скорость имеет значение
Чтобы эффективно работать, ИИ требует двух критических этапов: обучение и вывод. Оба сильно зависят от быстрого и надежного доступа к большим объемам данных. Когда модель ИИ принимает решения или генерирует результаты в режиме реального времени во время вывода, задержка становится особенно важной. Любая задержка в получении необходимых данных может замедлить результаты, снизить опыт пользователя или, что еще хуже, вызвать откровенные сбои системы.
Подумайте о системе обнаружения мошенничества, сканирующей транзакцию или помощник по искусственному искусству, генерирующий ответ. Если базовая база данных не может не отставать, модель искусственного интеллекта затягивает. Задержка — это не просто неудобства; Это подрывает все ценностное предложение AI.
Поскольку эти системы масштабируются, проблема составляет. Больше пользователей, больше данных и больше регионов вводят больше потенциальных точек отказа, если только инфраструктура данных не будет создана для распределенного доступа с низкой задержкой.
Когда задержка нарушает ИИ
Последние отключения на генеративных платформах ИИ являются реальным примером, показывающим, как, казалось бы, незначительные задержки в реагировании на базу данных могут привести к огромным сбоям. В другой области автономные транспортные средства зависят от решений в реальном времени, подкрепленных массовыми моделями ИИ. Даже незначительные задержки при доступе к данным датчиков или картам окружающей среды могут повлиять на безопасную навигацию и привести к задержкам или несчастным случаям.
Низкая задержка не просто повышает производительность. Это также гарантирует доверие, безопасность и непрерывность бизнеса.
Максимально использовать ваш уровень данных
При разговоре об искусственном интеллекте легко упустить из виду базу данных. Но это ошибка. Если модель является мозгом, база данных является системой кровообращения. Мозг перестанет функционировать, если данные не движутся достаточно быстро.
Это означает, что для обеспечения быстрого и надежного доступа к данным требуется надежная архитектура, независимо от того, где находятся пользователи, приложения или модели. Именно здесь гео-распределенные базы данных становятся жизненно важными.
Здание для устойчивости ИИ: гео-распределенные архитектуры
Гео-распределение уменьшает расстояние между вашими моделями ИИ и вашими данными физически и в сети. Это включает в себя воспроизведение и поиск данных ближе к тому, где это необходимо. Результатом является неизменно доступный доступ, даже по регионам и зонах доступности.
Вот шесть топологий развертывания, которые поддерживают устойчивые операции по ИИ с низкой задержкой, а также потенциальные компромиссы:
1. Однорегионный мультизоновый кластер
Однорегионный мультизоновый кластер состоит из трех или более узлов, которые работают вместе, и делятся данными в зонах в том же регионе. В то время как эта настройка предлагает преимущества, она также поставляется с такими недостатками, как увеличение задержки чтения и записи для приложений, доступа к данным из-за пределов региона, и ограниченной защитой от общегосударственных перебоев, вызванных событиями, связанными с погодой и стихийными бедствиями. Эта конфигурация лучше всего подходит для ситуаций, когда вам нужна сильная последовательность, высокая доступность и устойчивость в одном регионе, особенно если ваши пользователи или приложения расположены поблизости и могут выиграть от доступа с низкой задержкой.
2. Синхронная репликация
Кластеры, использующие синхронную репликацию, обеспечивают высокую доступность и устойчивость, обеспечивая нулевую потерю данных (RPO) и минимальное время восстановления (RTO). Тем не менее, развертывание в нескольких регионах может увеличить задержку записи, и чтения последователей может жертвовать согласованностью для достижения более низкой задержки.
3. однонаправленная асинхронная репликация
Мультирегионные кластеры с использованием однонаправленной асинхронной репликации обеспечивают аварийное восстановление с целью ненулевой точки восстановления (RPO) и объектива времени восстановления (RTO). Они предлагают сильную последовательность и чтения с низкой задержкой и записываются в области кластера исходных источников, в то время как кластер-раковина поддерживает возможную (временную) согласованность. Однако, поскольку кластер раковины только для чтения и не обрабатывает записи, клиенты, расположенные за пределами исходной области, могут испытывать высокую задержку. Поскольку репликация Xcluster обходит уровень запроса для реплицированных данных, триггеры базы данных не будут выполняться, что может вызвать непредсказуемое поведение.
4. двунаправленная асинхронная репликация
Двунаправленная асинхронная репликация помогает в аварийном восстановлении с ненулевым RPO и RTO, обеспечивая сильную последовательность в кластере обработки записи и возможной последовательности в удаленном кластере, наряду с чтениями и записи с низкой задержкой. Тем не менее, это поставляется с компромиссом: триггеры базы данных не будут стрелять из -за обхода слоев запросов; Уникальные ограничения не применяются, поскольку репликация происходит на уровне регистрации записи (WAL), что рискует несоответствиями данных; и идентификаторы автоматического введения могут вызвать конфликты в активных активных настройках, поэтому вместо этого рекомендуется использование уникальных идентификаторов пользователей (UUIDS).
5. Гео-пребывание с закреплением данных
Геочась с закреплением данных лучше всего подходит для случаев использования, требующих данных, которые проживают в определенных географических регионах, поскольку оно обеспечивает соответствие нормативно-нормативным требованиям, сильную согласованность и доступ к низкой задержке в этом регионе. Он подходит для логически распределенных наборов данных, таких как учетные записи пользователей, специфичные для страны, или локализованные каталоги продуктов. Важно учитывать, что задержка перекрестного региона может возникнуть, когда пользователи получают доступ к своим данным за пределами закрепленной области.
6. Читайте реплики
Читать Replicas предлагают быстрые, счетные чтения с временной шкалой, а низкая задержка записи в первичный кластер, поддерживая общую более высокую последовательность. Тем не менее, реплики не улучшают устойчивость, потому что они привязаны к первичным и не могут обращаться с записями. Задержка записи может оставаться высокой для удаленных клиентов, даже если существует близлежащая реплика для чтения.
Задержка — это не ошибка, но часто это результат архитектурных решений, которые были приняты слишком рано и пересматривались слишком поздно. Чтобы ИИ добился успеха в масштабе, задержка должна рассматриваться на уровне базы данных и определять основную проблему дизайна.
Предприятия, которые инвестируют в инфраструктуру данных с низкой задержкой, будут не только поддерживать работу своих систем ИИ, но и гарантировать, что они быстрее, умнее и по-настоящему преобразующие.
Познакомьтесь с Yugabytedb, PostgreSQL-совместимой распределенной базой данных для ваших облачных приложений. Эластичный, масштабируемый и гибкий. Узнайте больше последних из Yugabyte Trending Stories Youtube.com/thenewstack Tech, которые движутся быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Эндрю Маршалл — вице -президент по маркетингу продуктов для югабайта, производителя Yugabytedb. Его страсть к технологиям и инструментам разработчика охватывает 25 лет, охватывая остановки в таких компаниях, как AWS, Microsoft, Pagerduty и New Relic. Подробнее от Эндрю Маршалла
