Первопричины могут быть различны, от кеширования, когда модель кэширует промежуточные вычисления до сбоя в изоляции самой модели, когда происходит переполнение контекстного окна и модель начинает выдавать данные из соседнего, ранние модели особенно этим грешили.
Также, так как модели обучаются на огромных массивах различных интернет-текстов, плохо дообученная модель могла плохо разделять инструкции и сами данные, что приводило или к галюцинациям, либо к тому что она могла выдать реальные данные, на которых была обучена.
На практике, баг мог быть и потому что, многие запросы пользователей объединялись в один так называемый "пакет", что бы разом его обработать на GPU. Если в логике обработки ответов вдруг возникла бы какая-то ошибка, то ответы от одного пользователя могли перепутаться с другим.
Тут тоже прокомментирую про куски чатов: Контекст вашей проблемы не знаю. Но скорее всего это была проблема не БД, а генеративного ИИ и promt injection. Последнее время я такого не встречал (после 3.5 версии), но на тот момент у меня было исследование на эту тему, когда я добивался того, что бы мне куски других чатов становились доступны. Допускаю что такая ситуация могла воспроизвестись и у вас. Но обыкновенный баг с бекенда тоже никто не отменял. Нарушение же принципов ACID, только потому что это реляционная БД, это нууу... что-то феноменально маловероятное.
1) Если мы говорим про ванильный PostgreSQL, то действительно шатные средства отсутствуют. Но это не означает что задача не решаема в принципе, популярный стек: Patroni + Consul (ZooKeeper или etcd), для получения автоматического failover. Или использовать Citus который превратит БД в распределённую систему. Но смысл и сила PostgreSQL, как раз в реляционной модели и ACID. Вокруг PG сложилась обширная экосистема, которая решает сопутствующие проблемы.
2.1) Про размер: дело не только (и не столько) в количестве копий БД, а в самой структуре хранения данных и индексов.
Например:
Для быстрого запроса "получить все заказы пользователя" создаём таблицу orders_by_user_id, где ключ партиции будет поле user_id, а в строке будут хранится все данные заказов.
Для запроса же к тем же данным, например "получить заказ по номеру" необходимо будет создать другую таблицу orders_by_order_id, где снова мы будем хранить все те же данные заказа, но уже в другой партиции. То есть данные заказа физически будут продублированы 2 раза.
2.2) Кроме того PostgreSQL имеет продвинутые механизмы сжатия на уровне страниц для больших полей или NULL-значений. Cassandra же традиционно менее эффективна в сжатии отдельных строк и сжимает данные на уровне дисковой системы. Что не настолько эффективно, как комбинация сжатия страниц и отсутствие дублирования данных.
2.3) В силу специфики самого механизма работы, Cassandra хранит не только само значение, но и дополнительные метаданные: маркеры времени для разрешения конфликтов, TTL или например информацию о кластере внутри партиции.
2.4) Ну и механизм сборки мусора тоже не очень сильно эффективен по сравнению с PG.
То есть по этим пунктам Cassandra очень сильно проигрывает PostgreSQL. Но оно и не удивительно, как я выше написал, это плата за инструмент.
3) Про то что бизнесу всё равно: ему всё равно, пока не приходят счета))
Пережить падение ДЦ, это очень важная задача, но это целый план DR. Так как не ограничивается только работой с БД. Именно для этих целей любое облако, например, просит работать минимум с двумя зонами доступности. И PostgreSQL вполне спокойно работает в таких условиях. Что удобнее и проще, вопрос философский, мой ответ - там где есть достаточные в команде компетенции. У каждого инструмента свои сильные и слабые стороны.
Денормализация данных и поддержка работоспособности в условиях активной разработки и последующего версионирования схем БД для Cassandra, отнюдь не самая тривиальная задача. Фактически нужно подстроить разработку под БД, тоже не все готовы на это пойти.
Плюс большие требования для железа, это будет 1,5-2 раза (субъективно) будет занимать больше места на то же количество информации в сравнении с реляционками. Главный же момент, который отталкивает именно бизнес, это сама парадигма: жертвуя консистентностью в пользу доступности (до этого понимания нужно дорасти).
В целом я с вами согласен, когда ты точно знаешь что строишь геораспределённую систему на несколько континентов, думать о том какие будешь использовать инструменты и подходы конечно же нужно. Посыл был в том, что многие не достигают даже части этой нагрузки, но уже спешат все переоптимизировать, не думая о том, что у всего есть цена. Та же Casandra которую вы упомянули, имеет ряд ограничений по работе с запросами, а в условиях какого-то стартапа просто может не быть возможностей заранее точно понять какие запросы будут нужны (с Сassаndra сам наткнулся в практике на такие проблемы, хотя как к инструменту у меня к ней нет никаких претензий).
Он говорит о том, что фундаментально они понимают, что находятся уже в серой зоне. И хотя на данный момент они могут закрыть всё ресурсами и оптимизацией, в каком-то будущем при текущем росте, предел будет достигнут. Поэтому они уже начали процесс переноса части нагрузки на Cosmos DB, но этот процесс ещё в самом начале, это касается новых пользователей, и это долго и сложно.
Мне бы тоже хотелось это узнать. Я припоминаю, что для PG в Azure самые жирные хосты были следующие, до 96 ядер и память до 672 GB RAM. Но смею предположить, что как раз вот этот момент Azure мог кастомизировать. Так как OpenAI это всё таки премиум клиент. Говоря же о ванильном, это где-то до 128 ядер и память до 2 TB RAM.
Точная цифра не раскрывается, но это миллионы QPS для PostgreSQL. Трафик 24 на 7, круглосуточно, 800 млн. пользователей. Если попробовать прикинуть, в одном запросе от пользователя где-то 10 обращений к бд.
Как пример: Получение истории диалога, проверка подписки и статуса, возможно логгировнаие запроса, проверка статус платежей, какие-то метаданные, профиль и настройки, лимиты и сохранение ответа и прочее.
Допустим возьмем, 10 запросов за сессию. Каждый пользователь раз 10 например в месяц заходит. Итого: 100. Умножаем обращения, запрос, сессии и пользователей. При 800 млн юзеров, это получается 80 миллиардов операций с БД в месяц (на деле конечно сессий и обращений сейчас намного больше).
P.S: Конечно же не всё использует исключительно PG, но если верить публикации, то постгрес один из основных источников пользовательских данных.
Если только не считать их объемы. А таких известных инсталяций я знаю не так много. И вот это как раз удивительно, что оперируя понятными и последовательными действиями и используя проверенный инструмент им удалось достичь приемлемой производительности, с учетом их трафика и задач.
Вы говорите абсолютно верно про накладные расходы. Но случаи и ситуации бывают разные, я описал общее решение, которое позволило бы комбинировать/портировать инфру с минимальными потерями. Если бы я описывал что-то более конкретное, а не общее, то взял бы другой кейс. Никто не мешает видоизменить схему под собственные нужны. Как я уже писал, прагматично подходя к проблеме привязки к провайдеру, можно объединить мощь облачных сервисов с возможностью перенести куда угодно. Итоговая же реализация будет продиктована разными требованиями бизнеса, бюджета и времени.
О том, что kubernetes стал де факто отраслевым стандартом говорим не мы, kubernetes был передан консорциуму The Linux Foundation, который как раз и занимается стандартизацией и продвижением продуктов на базе открытого ПО, так же об этом говорит большая распространённость и поддержка этого инструмента большинством провайдеров, так же, косвенно может служить подтверждением разработка стандартов для kubernetes такими независимыми организациями, как Center for Internet Security и др. И речь шла именно об общих подходах для публичных/гибридных решений на базе открытого ПО, о чем в статье и было упомянуто.
Это один из вариантов DevOps-подхода для построения гибридных решений. Важная деталь в обсуждении методов разворачивания озёр данных — это привязка к поставщику. Kubernetes де факто стал отраслевым стандартом из-за его возможностей к переносу. Если мы используем Kubernetes, такое решение поможет без лишних сложностей развернуть сервис в AWS, GCP, Azure или где-то ещё. Прагматично подходя к проблеме привязки к провайдеру, мы объединяем мощь облачных сервисов с возможностью перенести сервисы куда угодно.
Подобные вопросы часто возникают когда речь заходит про облачные решения. Этот кейс некорректно было бы рассматривать и высчитывать в отрыве от основного процесса. На определённых объемах данных, задействованных решениях и используемых инструментах self hosted становится не прагматично и не целесообразно использовать.
1С давно предоставляет услугу как сервис у себя в облаке. Ну или вам никто не мешает поднять свою виртуалку с любым ПО и оперировать им как частью облака. Я как раз на днях поднимал 1С в облаке — он прекрасно себя чувствует))
Еще о грустном: если я арендую кусочек облака, и хочу перекинуть виртуалку на машину по мощнее, никто мне в облаке ее не сделает.
Это тоже делается в один клик. Все популярные облачные провайдеры этот функционал предоставляют из коробки.
С гарантиями сохранности данных у облаков, вообще говоря, не особо богато, они не этим исходно берут, а то, чем они берут (масштабированием) не всем нужно в силу особенностей ПО заказчика.
С сохранностью данных абсолютное преимущество, более того данные хранятся годами. Я вообще забыл о том что у меня какие-то данные могут потеряться. Репликация, архивные хранилища, доступ из любой части света.
А по поводу, что это стоит денег. Да это всё не бесплатно. Как написали выше — резервируйте мощности и получайте хорошую скидку.
Сервер относится к группе вычислительной техники с повышенными амортизационными рисками. Максимальный рекомендуемый срок полезного использования серверного оборудования составляет три года включительно. О каких 5 годах речь не совсем ясно, зачем бизнесу выкупать заведомо устаревшее оборудование. Я не говорю уже о том, что для облака, переход, например, с Broadwell на Cascade Lake — это не проблема, происходит в один клик и абсолютно не заметно для бизнеса. Тогда как держа сервера на балансе, это бы потребовало усилий и накладных расходов.
Да, есть компании, для которых критически важно держать на балансе собственное железо. С точки зрения повышенной безопасности или в угоду другим политическим моментам.
Облачные технологии обладают рядом неоспоримых преимуществ и являются самым быстрорастущим рынком — бизнес голосует монетой. Использовать ли для бизнеса именно Amazon или лучше перейти на Google Cloud или Yandex Cloud, или выбрать что-то ещё, вопрос индивидуальный.
Первопричины могут быть различны, от кеширования, когда модель кэширует промежуточные вычисления до сбоя в изоляции самой модели, когда происходит переполнение контекстного окна и модель начинает выдавать данные из соседнего, ранние модели особенно этим грешили.
Также, так как модели обучаются на огромных массивах различных интернет-текстов, плохо дообученная модель могла плохо разделять инструкции и сами данные, что приводило или к галюцинациям, либо к тому что она могла выдать реальные данные, на которых была обучена.
На практике, баг мог быть и потому что, многие запросы пользователей объединялись в один так называемый "пакет", что бы разом его обработать на GPU. Если в логике обработки ответов вдруг возникла бы какая-то ошибка, то ответы от одного пользователя могли перепутаться с другим.
Тут тоже прокомментирую про куски чатов: Контекст вашей проблемы не знаю. Но скорее всего это была проблема не БД, а генеративного ИИ и promt injection. Последнее время я такого не встречал (после 3.5 версии), но на тот момент у меня было исследование на эту тему, когда я добивался того, что бы мне куски других чатов становились доступны. Допускаю что такая ситуация могла воспроизвестись и у вас. Но обыкновенный баг с бекенда тоже никто не отменял. Нарушение же принципов ACID, только потому что это реляционная БД, это нууу... что-то феноменально маловероятное.
1) Если мы говорим про ванильный PostgreSQL, то действительно шатные средства отсутствуют. Но это не означает что задача не решаема в принципе, популярный стек: Patroni + Consul (ZooKeeper или etcd), для получения автоматического failover. Или использовать Citus который превратит БД в распределённую систему. Но смысл и сила PostgreSQL, как раз в реляционной модели и ACID. Вокруг PG сложилась обширная экосистема, которая решает сопутствующие проблемы.
2.1) Про размер: дело не только (и не столько) в количестве копий БД, а в самой структуре хранения данных и индексов.
Например:
Для быстрого запроса "получить все заказы пользователя" создаём таблицу orders_by_user_id, где ключ партиции будет поле user_id, а в строке будут хранится все данные заказов.
Для запроса же к тем же данным, например "получить заказ по номеру" необходимо будет создать другую таблицу orders_by_order_id, где снова мы будем хранить все те же данные заказа, но уже в другой партиции. То есть данные заказа физически будут продублированы 2 раза.
2.2) Кроме того PostgreSQL имеет продвинутые механизмы сжатия на уровне страниц для больших полей или NULL-значений. Cassandra же традиционно менее эффективна в сжатии отдельных строк и сжимает данные на уровне дисковой системы. Что не настолько эффективно, как комбинация сжатия страниц и отсутствие дублирования данных.
2.3) В силу специфики самого механизма работы, Cassandra хранит не только само значение, но и дополнительные метаданные: маркеры времени для разрешения конфликтов, TTL или например информацию о кластере внутри партиции.
2.4) Ну и механизм сборки мусора тоже не очень сильно эффективен по сравнению с PG.
То есть по этим пунктам Cassandra очень сильно проигрывает PostgreSQL. Но оно и не удивительно, как я выше написал, это плата за инструмент.
3) Про то что бизнесу всё равно: ему всё равно, пока не приходят счета))
Пережить падение ДЦ, это очень важная задача, но это целый план DR. Так как не ограничивается только работой с БД. Именно для этих целей любое облако, например, просит работать минимум с двумя зонами доступности. И PostgreSQL вполне спокойно работает в таких условиях. Что удобнее и проще, вопрос философский, мой ответ - там где есть достаточные в команде компетенции. У каждого инструмента свои сильные и слабые стороны.
Денормализация данных и поддержка работоспособности в условиях активной разработки и последующего версионирования схем БД для Cassandra, отнюдь не самая тривиальная задача. Фактически нужно подстроить разработку под БД, тоже не все готовы на это пойти.
Плюс большие требования для железа, это будет 1,5-2 раза (субъективно) будет занимать больше места на то же количество информации в сравнении с реляционками. Главный же момент, который отталкивает именно бизнес, это сама парадигма: жертвуя консистентностью в пользу доступности (до этого понимания нужно дорасти).
В целом я с вами согласен, когда ты точно знаешь что строишь геораспределённую систему на несколько континентов, думать о том какие будешь использовать инструменты и подходы конечно же нужно. Посыл был в том, что многие не достигают даже части этой нагрузки, но уже спешат все переоптимизировать, не думая о том, что у всего есть цена. Та же Casandra которую вы упомянули, имеет ряд ограничений по работе с запросами, а в условиях какого-то стартапа просто может не быть возможностей заранее точно понять какие запросы будут нужны (с Сassаndra сам наткнулся в практике на такие проблемы, хотя как к инструменту у меня к ней нет никаких претензий).
Он говорит о том, что фундаментально они понимают, что находятся уже в серой зоне. И хотя на данный момент они могут закрыть всё ресурсами и оптимизацией, в каком-то будущем при текущем росте, предел будет достигнут. Поэтому они уже начали процесс переноса части нагрузки на Cosmos DB, но этот процесс ещё в самом начале, это касается новых пользователей, и это долго и сложно.
Мне бы тоже хотелось это узнать. Я припоминаю, что для PG в Azure самые жирные хосты были следующие, до 96 ядер и память до 672 GB RAM. Но смею предположить, что как раз вот этот момент Azure мог кастомизировать. Так как OpenAI это всё таки премиум клиент. Говоря же о ванильном, это где-то до 128 ядер и память до 2 TB RAM.
Безусловно Azure приложила максимум усилий что бы всё удалось. О чём я и упопянул в послесловии.
Точная цифра не раскрывается, но это миллионы QPS для PostgreSQL. Трафик 24 на 7, круглосуточно, 800 млн. пользователей. Если попробовать прикинуть, в одном запросе от пользователя где-то 10 обращений к бд.
Как пример: Получение истории диалога, проверка подписки и статуса, возможно логгировнаие запроса, проверка статус платежей, какие-то метаданные, профиль и настройки, лимиты и сохранение ответа и прочее.
Допустим возьмем, 10 запросов за сессию. Каждый пользователь раз 10 например в месяц заходит. Итого: 100. Умножаем обращения, запрос, сессии и пользователей. При 800 млн юзеров, это получается 80 миллиардов операций с БД в месяц (на деле конечно сессий и обращений сейчас намного больше).
P.S: Конечно же не всё использует исключительно PG, но если верить публикации, то постгрес один из основных источников пользовательских данных.
Если только не считать их объемы. А таких известных инсталяций я знаю не так много. И вот это как раз удивительно, что оперируя понятными и последовательными действиями и используя проверенный инструмент им удалось достичь приемлемой производительности, с учетом их трафика и задач.
Какая-то маркетинговая вода.
1С давно предоставляет услугу как сервис у себя в облаке. Ну или вам никто не мешает поднять свою виртуалку с любым ПО и оперировать им как частью облака. Я как раз на днях поднимал 1С в облаке — он прекрасно себя чувствует))
Это тоже делается в один клик. Все популярные облачные провайдеры этот функционал предоставляют из коробки.
С сохранностью данных абсолютное преимущество, более того данные хранятся годами. Я вообще забыл о том что у меня какие-то данные могут потеряться. Репликация, архивные хранилища, доступ из любой части света.
А по поводу, что это стоит денег. Да это всё не бесплатно. Как написали выше — резервируйте мощности и получайте хорошую скидку.
Да, есть компании, для которых критически важно держать на балансе собственное железо. С точки зрения повышенной безопасности или в угоду другим политическим моментам.
Облачные технологии обладают рядом неоспоримых преимуществ и являются самым быстрорастущим рынком — бизнес голосует монетой. Использовать ли для бизнеса именно Amazon или лучше перейти на Google Cloud или Yandex Cloud, или выбрать что-то ещё, вопрос индивидуальный.