Югабайт спонсировал этот пост.
Практически каждое приложение имеет хранилище данных, будь то для пользовательских данных, захвата событий или транзакций клиентов и взаимодействий. Если это облачное приложение, то один из контейнеров, вероятно, будет базой данных. Помимо разработки и развертывания вашего нового приложения, ваша база данных должна быть готова к росту и потенциальным отключениям.
Приложения Generative AI (Genai) должны проходить один и тот же жизненный цикл приложения при обработке неструктурированных данных и интеграции с большими языковыми моделями (LLMS).
Что произойдет, если приложение должно расти? Купить больший сервер, больше вычислить, больше хранилища? Это то, что делали разработчики, когда началось облако. Эти подходы могут обрабатывать определенные варианты использования после первоначального запуска стартапа, но быстрый рост может привести к выходу из строя инфраструктуры, если она не предназначена для плавного масштабирования и устойчивости с самого начала.
Такое масштабирование и устойчивость требуют распределенных узлов данных, в основном для репликации или шардинга.
Шарки базы данных — это процесс разбивания больших таблиц базы данных на более мелкие куски, называемые осколками. Шард — это горизонтальный раздел данных, который содержит подмножество общего набора данных. Он отвечает за обслуживание части общей рабочей нагрузки. (Источник: Yugabyte)
Наиболее распространенным шардом является горизонтальный; Например, если ваша клиентская база быстро растет, вы можете поставить всех клиентов с именами A — M на один узел, и все, что начинаются с N — Z на другом, а затем направить запросы на узлы по мере необходимости. Первоначально это может показаться разумным, но крайне маловероятно, что вы будете выращивать клиентов одинаково по всему алфавиту. Итак, еще раз, это не масштабируется.
Введите распределенный SQL. Это представляет пользователю одну логическую базу данных SQL, а затем передает запросы через узлы под капотом. В то время как пользователь нацелен на одну систему, фактическое распределение узлов может расти, воспроизводить, иметь географическое представление, сидеть рядом с краем и так далее.
Распределенный SQL сохраняет кислотные транзакции: Атомный Транзакции либо происходят полностью, либо не случаются; последовательность требует, чтобы транзакции всегда подчинялись ограничениям, определенным базой данных; транзакция кажется изолирован от любого другого до завершения; и государство хранится долго После того, как он будет совершен — не только в временной памяти. Это разумно направляет любой запрос через лучшие узлы.
(Источник: Yugabyte)
Стратегия Yugabyte проста: если вы знаете PostgreSQL, то вы уже знаете yugabytedb. Если вы используете Postgres-совместимую реляционную базу данных с открытым исходным кодом, вам не нужно доверять совершенно другой системе.
Но может оказаться, что Smart Distributed Cextution — это самый сильный иск Yugabytedb в революции ИИ, потому что это означает, что он уже предлагает интеллектуальную маршрутизацию решений наряду с масштабируемостью, устойчивостью и геодигиацией в своем продукте.
Yugabytedb недавно запустил поддержку передовой векторной индексации, а также свое собственное первое агентское приложение ИИ, консультант по производительности Yugabytedb Aeon. Поддержка индексации вектора увеличивает возможности, предлагаемые PGVector Postgres Extension для создания современных приложений Genai.
Чтобы получить представление о том, что все это означает для разработчиков, я поговорил с Картиком Ранганатаном, основателем и со-директором Yugabyte.
Чем умнее технологии, тем больше имеет значение база данных
Одним из аспектов «кодирования атмосфера» — термина ажиотажа для прототипирования — заключается в том, что общей моделью хранилища все еще является единой базой данных. Будет ли глобальный мозг, который является LLM, высасывающий веб -использование распределенного SQL?
Ранганатан указал, в каком направлении может быть направлено: «Современные приложения имеют несколько переплетенных аспектов поиска, транзакций, обработки естественного языка (NLP) и средств массовой информации. Я думаю, что агентские системы с внедрением протокола контекста модели (MCP) и A2A помогут подключить и координировать возможности для обеспечения сквозного пользовательского опыта. И более сложный пользовательский опыт работы, обеспечиваемые требования DataBase.
«Вы по -прежнему видите Oracle и SQL Server и DB2 и Postgres как ядро транзакционных данных. Это огромный рынок. Вы соединяете все NOSQL, из которых самый большой, вероятно, что -то вроде MongoDB, они все еще действительно маленькие, тогда также могут быть векторные базы данных, такие как PineCone», — сказал Ранганатан.
«Но главное, когда кто -то строит новое приложение или новое пользовательское опыт, нужно ли нам создавать больше разрастания базы данных?»
Это питается другой идеей: в разработке приложений Genai, где люди не запускают минимальный жизнеспособный продукт (MVP) в день 0, как они обеспечивают возможную масштабируемость и устойчивость? А как вписывается yugabytedb?
«Распределенные системы необходимы для устойчивых и масштабируемых приложений Genai. Их взаимосвязанные узлы обеспечивают избыточность и распределяют рабочие нагрузки, обеспечивая непрерывную работу и способность обрабатывать большие объемы трафика. Поскольку мы сосредоточились на производственном уровне для реляционных приложений SQL, вы получаете это устойчивость с 1-го дня»,-объяснил Ранганатан.
Консультант по производительности и агент
Итак, на консультант по производительности. Есть некоторая естественная совместимость с агентским ИИ, но также и некоторая путаница в моей голове. Очевидно, что транзакции должны быть атомными, но запросы ИИ могут зацикливаться, если цели не достигнуты. Как справляются бродячие подсказки? Подсказываются ли подсказки в области консультанта по производительности тщательно курируются?
Ранганатан указал, что этап транзакции не был единственным фокусом YugabytedB. Консультант по производительности «смотрит на многие другие сигналы», сказал он. «Каково ваше товарное оборудование, облачное нативное оборудование, на котором вы запускаете? Каковы сигналы, которые они выпускают с точки зрения доступа к данным, доступности, или использование ЦП? Мы смотрим на то, сколько соединений устанавливает приложение». Мы смотрим на шаблоны геодиатрализации, чтобы увидеть, откуда приходят соединения и откуда они подключаются ».
«Когда кто -то создает новое приложение или новое пользовательское обход, нужно ли нам создавать больше разрастания базы данных?»
-Картик Ранганатан, основатель и со-директор югабайт
Так что, похоже, это то, что мы называли экспертной системой, заметил я. Он кивнул. «И причина, по которой с точки зрения агента становится интересной, заключается в том, что в облачных архитектурах, например, AWS, AWS, GCP, Kubernetes и т. Д. Проблемы с устранением неполадок в производстве, взаимодействие с ним ».
Я задал более чувствительный вопрос: хранит ли Yugabyte данные для улучшения знаний о системе консультантов по производительности югабайта для будущих учебных целей?
Ранганатан прошел через это уверенно. «Мы не собираем персональные данные или идентифицируемые данные, и мы, очевидно, просим пользователей разрешение брать данные, в зависимости от того, где находятся агенты». Если агенты работают в своих собственных облачных системах, то процесс намного более эффективен.
«Мы собираем много метрик и много конфигураций. Абсолютно. Но нам нужен отпечаток пальца. Персона пользователя и различные сигналы. Нам не нужно знать имя вашего кластера или ряды в запросе». Консультант по производительности перечисляет идентифицируемые корневые причины и дает каждому оценку вероятности.
Наконец, экосистема играет вопрос: пытается ли Yugabytedb стать фактической векторной базой данных для облачных систем?
«Если вы посмотрите на инструмент, написанный для рынка ИИ, есть натуральная пищевая цепь», — объяснил Ранганатан. Вверху находятся библиотеки ИИ. На одном шаге ниже — специализированные векторные базы данных (например, Pinecone). И в -третьих, есть класс баз данных общего назначения, в том числе адаптации PGVector, которые становятся довольно хорошо выполнять векторные вещи.
«С нашим последним выпуском мы переносим его с третьего уровня до первого уровня. Мы держим интерфейс таким же, как PGVector, чтобы каждый мог его использовать. Мы также наполняем его облачными собственными свойствами устойчивости, масштабирования, автоматического осколка и всего этого. Так что вам не нужно беспокоиться об этом, и вы можете просто справиться с ним в облаке, что является нашей целью».
Корни с открытым исходным кодом Yugabytedb остаются сильными
Мне было любопытно узнать мысли Ранганатана о технической тенденции вдали от открытого исходного кода. Например, мы видели, как продукты переходят от общественных лицензий Mozilla к более ограничительной «исходной» лицензии на бизнес-источник.
Как это случилось, он был на домашней территории с этим вопросом. «Мы начали Yugabytedb в начале 2016 года. И когда мы его начали, потенциальные инвесторы сказали, что открытый исходный код не был жизнеспособной бизнес -моделью.
«Это обсуждалось навсегда, потому что я думаю, что трудно понять нюансы монетизации с открытым исходным кодом. Мы продолжаем и подтверждаем нашу позицию, чтобы оставаться открытой. На рынке баз данных модель доходов — это не просто база данных. Она находится в базе данных как управляемая услуга».
Встреча пользователей, где они находятся
Благодаря Cerformance Advisor и Agentic AI -треку, YugabytedB просто согласуется с тем, где уже находятся системы его пользователей: дело с терабайтами потоковых данных, которые питаются все интеллектуальные системы. Правильная информация все еще должна храниться устойчиво, запрашивать и действовать. Как система с открытым исходным кодом, Yugabytedb имеет шанс зарекомендовать себя в основе бума.
Познакомьтесь с Yugabytedb, PostgreSQL-совместимой распределенной базой данных для ваших облачных приложений. Эластичный, масштабируемый и гибкий. Узнайте больше последних из Yugabyte Trending Stories Youtube.com/thenewstack Tech, которые движутся быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид был лондонским профессиональным разработчиком программного обеспечения в Oracle Corp. и British Telecom, а также консультантом, помогающим командам работать более гибким образом. Он написал книгу по дизайну пользовательского интерфейса и с тех пор пишет технические статьи …. Подробнее от Дэвида Истмана
