"Хорошая/плохая" - это для дискуссий о футболе. Инженеры оперируют различными критериями, из которых "минимизация внешних зависимостей", "надежная опробованная методика" и "неограниченная временем поддержка" стоят в топе
Один из подходов, позволяющих отгородиться от безумия, пример которого описан в статье. На клиентской части - проходит, на серверной стороне - уже совсем не так весело.
Сомнительный подход, "бери стороннюю реализацию" - так можно сказать про любой компонент. Вспомним, что STL изначально тоже не была частью стандартной библиотеки, и в 1990-х годах существовало множество реализаций. Работа с датами появилась вообще в C++20, хотя казалось бы, важнейшая часть.
Критерием включения в стандартную библиотеку является не пуризм адептов, а необходимость использования в приложениях. Можно ли представить промышленное приложение не ведущее логов? Можно ли за рамками embedded представить приложение, которое не взаимодействует с другими?
Вопросы риторические, я не вижу у адептов чистоты желания их обсуждать, только поводы отбрехаться.
Уход от реальных проблем в политику. На пороге 2025 год, в стандартной библиотеке всё еще нет средств доступа к СУБД, ведению логов и построению сетевых служб.
Позитивный подход: "Я - дилетант, мои коллеги - дилетанты, поэтому команде надо больше общаться, чтобы, как анонимным алкоголикам, не впасть в депрессию не выгореть за пару месяцев"
Для асинхронной обработки в SQL Server есть несколько стандартных механизмов "из коробки": диспетчер задач (SQL agent), события (create event notification и extended events), брокер (Service Broker). Создание триггеров на C# CLR - нерекомендуемая практика, язык Transact SQL достаточно развит, а триггеры поддерживают обработку всего набора данных за один проход. Если вдруг вы уперлись в сложность вычислений, то это верный признак для выноса обработки из СУБД на клиентов (сервисы) Прежде чем планировать миграцию, попытайтесь достичь той же производительности и стоимости поддержки, если это является критерием в вашей организации.
люди, которые в 90-е и 00-е учились по материалам и проходили курсы вендоров в университетах
Такая риторика работает в обе стороны, в зависимости от цели. Например, сейчас много людей, учившихся на MySQL / Postgres, сходу предлагающих решения на том, что знакомо, не задумываясь о предстоящих проблемах, уже решенных коммерческими СУБД лет 20 назад.
В этом есть смысл, если вспомнить, что промышленная СУБД - это тысячи параметров плюс "железо" и инфраструктура. Не обладая специальными знаниями легко получить незначащие результаты.
Есть ли сравнения с коммерческими оптимизаторами? Честно говоря, сравнения с Постгресом не вполне значимы, оптимизатор у него слабый, с ростом соединений на втором-третьем уровне дерева плана выполнения стабильные bad estimations.
P.S. Насколько я помню, например, на оптимизатор DB2 в середине-конце 1990-х в IBM работал фактически небольшой НИИ.
С облаками другая проблема, затраты нефиксированные. Да, можно легко добавить реурсы, но далеко не всегда это нужно. Если БД эксплуатируется в стабильном режиме, то аренда/покупка сервера будет гораздо выгоднее.
Видимо, в этом основная проблема, подход слишком ресурсозатратный. Для сравнения, 2005 год, SQL Server на физических 8 ядрах обслуживает запросы от 1500 пользователей онлайн с приемлемым качеством (небольшой процент плохих планов корректируется руками). Каждое ядро лицензируется и обходится примерно в $3-5К. Если сюда добавить 32 ядра для небольшого улучшения оптимизации, то цена решения может стать неприемлемой.
Видимо, я недостаточно точно задал вопрос. Откинем пока условия промышленной эксплуатации, инфраструктуру и вопросы динамики. Допустим есть пакет запросов и статическая БД заданного объема. На условном SQL Server elapsed time и CPU time будут такими-то на N ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")
"Хорошая/плохая" - это для дискуссий о футболе. Инженеры оперируют различными критериями, из которых "минимизация внешних зависимостей", "надежная опробованная методика" и "неограниченная временем поддержка" стоят в топе
Один из подходов, позволяющих отгородиться от безумия, пример которого описан в статье. На клиентской части - проходит, на серверной стороне - уже совсем не так весело.
Нам нужна хорошая реализация в составе стандартной
Ирония - дочь бессилия
Сомнительный подход, "бери стороннюю реализацию" - так можно сказать про любой компонент. Вспомним, что STL изначально тоже не была частью стандартной библиотеки, и в 1990-х годах существовало множество реализаций. Работа с датами появилась вообще в C++20, хотя казалось бы, важнейшая часть.
Критерием включения в стандартную библиотеку является не пуризм адептов, а необходимость использования в приложениях. Можно ли представить промышленное приложение не ведущее логов? Можно ли за рамками embedded представить приложение, которое не взаимодействует с другими?
Вопросы риторические, я не вижу у адептов чистоты желания их обсуждать, только поводы отбрехаться.
Мы получали знания от преподавателей, наставников, из книг и практической работы, а не ежедневной болтовнёй с такими же дилетантами
Уход от реальных проблем в политику. На пороге 2025 год, в стандартной библиотеке всё еще нет средств доступа к СУБД, ведению логов и построению сетевых служб.
Позитивный подход: "Я - дилетант, мои коллеги - дилетанты, поэтому команде надо больше общаться, чтобы
, как анонимным алкоголикам, не впасть в депрессиюне выгореть за пару месяцев"Для асинхронной обработки в SQL Server есть несколько стандартных механизмов "из коробки": диспетчер задач (SQL agent), события (create event notification и extended events), брокер (Service Broker).
Создание триггеров на C# CLR - нерекомендуемая практика, язык Transact SQL достаточно развит, а триггеры поддерживают обработку всего набора данных за один проход. Если вдруг вы уперлись в сложность вычислений, то это верный признак для выноса обработки из СУБД на клиентов (сервисы)
Прежде чем планировать миграцию, попытайтесь достичь той же производительности и стоимости поддержки, если это является критерием в вашей организации.
Почему авторы не хотят просто провести стандартный тест типа TPC-E и сравнить результаты с имеющимися?
Такая риторика работает в обе стороны, в зависимости от цели. Например, сейчас много людей, учившихся на MySQL / Postgres, сходу предлагающих решения на том, что знакомо, не задумываясь о предстоящих проблемах, уже решенных коммерческими СУБД лет 20 назад.
В этом есть смысл, если вспомнить, что промышленная СУБД - это тысячи параметров плюс "железо" и инфраструктура. Не обладая специальными знаниями легко получить незначащие результаты.
Есть ли сравнения с коммерческими оптимизаторами? Честно говоря, сравнения с Постгресом не вполне значимы, оптимизатор у него слабый, с ростом соединений на втором-третьем уровне дерева плана выполнения стабильные bad estimations.
P.S. Насколько я помню, например, на оптимизатор DB2 в середине-конце 1990-х в IBM работал фактически небольшой НИИ.
Я просто задал вопрос. Появление книг и статей может быть косвенным подтверждением.
А как же bullshit jobs, про которые пишут целые книги, и "ghost jobs" - фиктивные вакансии, которыми кишат сайты?
С облаками другая проблема, затраты нефиксированные. Да, можно легко добавить реурсы, но далеко не всегда это нужно. Если БД эксплуатируется в стабильном режиме, то аренда/покупка сервера будет гораздо выгоднее.
Видимо, в этом основная проблема, подход слишком ресурсозатратный. Для сравнения, 2005 год, SQL Server на физических 8 ядрах обслуживает запросы от 1500 пользователей онлайн с приемлемым качеством (небольшой процент плохих планов корректируется руками). Каждое ядро лицензируется и обходится примерно в $3-5К. Если сюда добавить 32 ядра для небольшого улучшения оптимизации, то цена решения может стать неприемлемой.
Видимо, я недостаточно точно задал вопрос. Откинем пока условия промышленной эксплуатации, инфраструктуру и вопросы динамики.
Допустим есть пакет запросов и статическая БД заданного объема. На условном SQL Server elapsed time и CPU time будут такими-то на N ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")