люди, которые в 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 ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")
Подобное достаточно просто реализовалось на N-gram лет 20 назад (поиск дубликатов в CRM). Можно даже на реляционных таблицах. Строка, переведенная в N-gram-ы по сути тот же вектор. https://blog.arbinada.com/ru/category/00020.html
Но при этом уже есть отдельные библиотеки и фреймворки с версиями выше 1. Когда их критическая масса созреет, вопрос отпадет сам собой. Из того что я видел вживую, ребята пилят версию 0 за денежки корпорации, но потом корпорация меняет планы выпуска своего оборудования, библиотека больше им не нужна, она остается в гитхабе "сами разбирайтесь, если надо".
Пример Оракла единичен и, скорее, относится к профюмору.
Есть история версий, клиентская база и возможности поддержки (в т.ч. платной). Стандартная логика пользователей такая: 0 - ребята пока пилят что-то на коленке, можно даже им помочь, если есть силы, 1 - появились первые промышленные применения, 2 и далее - продукт оказался нужным и развивается
Описание языка (референс) - текущее состояние с привязкой к компилятору. Стандарт (спецификация) - официально зафиксированный слепок на конкретный момент времени, которому должны соответствовать компиляторы, заявляющие о совместимости "на уровне стандарта ХХХ".
Надо как-то решать эту проблему. Если библиотека готова к промышленной эксплуатации, то версия не должна быть 0.х. Я общался с ребятами, которые делают сетевую среду с брокерами, "сообщники" им просто не дают поставить "единичку".
1.х тоже еще не признак зрелости, но хоть что-то. Оракл в свое время начал выпуск СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией.
Почему авторы не хотят просто провести стандартный тест типа 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 ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")
Подобное достаточно просто реализовалось на N-gram лет 20 назад (поиск дубликатов в CRM). Можно даже на реляционных таблицах. Строка, переведенная в N-gram-ы по сути тот же вектор.
https://blog.arbinada.com/ru/category/00020.html
Интересные у вас представления о брошенных курах, несущих золотые яйца
В вики есть отдельные статьи для "Programming language reference" и "Programming language specification". Спецификация для ЯП синоним стандарта.
Но при этом уже есть отдельные библиотеки и фреймворки с версиями выше 1. Когда их критическая масса созреет, вопрос отпадет сам собой. Из того что я видел вживую, ребята пилят версию 0 за денежки корпорации, но потом корпорация меняет планы выпуска своего оборудования, библиотека больше им не нужна, она остается в гитхабе "сами разбирайтесь, если надо".
Как раз про Раст и разницу между стандартом (спецификацией) и описанием (референсом): "What is the difference between specification and a reference for programming languages?".
Ребята ведь начали пилить RFC, хотя референс есть. Казалось бы, зачем, да? :)
Всего вам доброго
Пример Оракла единичен и, скорее, относится к профюмору.
Есть история версий, клиентская база и возможности поддержки (в т.ч. платной). Стандартная логика пользователей такая: 0 - ребята пока пилят что-то на коленке, можно даже им помочь, если есть силы, 1 - появились первые промышленные применения, 2 и далее - продукт оказался нужным и развивается
Описание языка (референс) - текущее состояние с привязкой к компилятору. Стандарт (спецификация) - официально зафиксированный слепок на конкретный момент времени, которому должны соответствовать компиляторы, заявляющие о совместимости "на уровне стандарта ХХХ".
Надо как-то решать эту проблему. Если библиотека готова к промышленной эксплуатации, то версия не должна быть 0.х. Я общался с ребятами, которые делают сетевую среду с брокерами, "сообщники" им просто не дают поставить "единичку".
1.х тоже еще не признак зрелости, но хоть что-то. Оракл в свое время начал выпуск СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией.
P.S. Никогда никого не "минусую"
Если цель комментария - диалог, то не стоит использовать рекомендательный тон отраслевого регулятора. Рекомендую, по-дружески :)