Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, keyvalue на SQL Server быстрее Redis, можете проверить на досуге.
Распределенные БД имеют разнообразную топологию в зависимости от требований к системе, и при любом раскладе они основаны на репликациях или, не к ночи буде упомянутой N-фазной фиксации. Не нужно делать обобщений и, тем более, ссылаться на "хайлоад", если вы переходите на менее производительные платформы. Ладно, вы пошли на второй круг, так что удачи.
Неподходящие модели данных задачи найдутся всегда, я их приводил в книжке, например с анкетированием на 100-1000 измерений. Если нужна работа с графами, то несмотря на поддержку таковых с версии 2017 в SQL Server, могут найтись более специализированные и лучшие платформы.
Мой поинт в другом: SQL Server превосходит постгрес по всем параметрам, по многим - с большим запасом. Это СУБД, основанные на реляционной модели данных. Поэтому обоснования, принимаемые в расчет - стоимость лицензий (без учета последующих затрат на поддержку) или политические риски.
И еще такой, очень частый ныне: начинали делать из говна и палок, ничего не знали о коммерческих решениях, теперь уже поздно.
стоимость этого решения понимаете?
Ну, а что же вы хотите, и рыбку съесть и ... Нет денег на энтерпрайз решения - у SQL Server 4 вида репликаций "из коробки" в самой базовой версии. Почти 25 лет назад делал на них "геокластер" на два континента. И ничего, работало
Не путайте тёлое с мягким. Для геолокализации нагрузок с 2008 года "из коробки" есть geo cluster. Шардировать же, если мы одинаково понимаем смысл термина, начинают по другим причинам, прежде всего по объемам данных.
Шардирование (распределенное по узлам секционирование) начинается с приближением к отметке "петабайт", что по вашим же словам, не ваш случай. Для начала нагрузка записи снижается (на порядки) прозрачным для приложений секционированием, которое, опять же, в SQL Server "из коробки" с 2005 года, а постгресу еще лет 10-15 догонять.
См. комментарий выше. По поводу "исполняются с той же скоростью" смешно пошутили.
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
В Париже из трех бед две ушли: каршеринг умер на начальной стадии, а самокаты убрали после многочисленных выступлений граждан.
Потому что NoSQL - это ребрендинг СУБД и моделей данных, существовавших до SQL
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Если и тесты генерируют другие "промпты", то есть более дешевая альтернатива - кропить сервера святой водой.
В каждой шутке есть доля шутки :)
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Скорее, претензия к компетентности авторов в теме сиквела. Открываем результат "призера" о3 и видим
то же яйцо, но сбокуту же проблему и ошибку.Открываю первый же запрос o3-mini‑high:
трудносопровождаемый copy-paste код, требующий примерно столько же комментариев, сколько и сам запрос
ошибка при выводе/формировании результата (для величин < 8.005)
Не финтехом единым. ERP или её подобие есть на любом предприятии. Это core system.
Просто вспомните о том, что когда бизнес меняет приложения, то данные мигрируют в новую систему. Потому что данные - основной актив.
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, keyvalue на SQL Server быстрее Redis, можете проверить на досуге.
Распределенные БД имеют разнообразную топологию в зависимости от требований к системе, и при любом раскладе они основаны на репликациях или, не к ночи буде упомянутой N-фазной фиксации. Не нужно делать обобщений и, тем более, ссылаться на "хайлоад", если вы переходите на менее производительные платформы. Ладно, вы пошли на второй круг, так что удачи.
Неподходящие модели данных задачи найдутся всегда, я их приводил в книжке, например с анкетированием на 100-1000 измерений. Если нужна работа с графами, то несмотря на поддержку таковых с версии 2017 в SQL Server, могут найтись более специализированные и лучшие платформы.
Мой поинт в другом: SQL Server превосходит постгрес по всем параметрам, по многим - с большим запасом. Это СУБД, основанные на реляционной модели данных. Поэтому обоснования, принимаемые в расчет - стоимость лицензий (без учета последующих затрат на поддержку) или политические риски.
И еще такой, очень частый ныне: начинали делать из говна и палок, ничего не знали о коммерческих решениях, теперь уже поздно.
Ну, а что же вы хотите, и рыбку съесть и ... Нет денег на энтерпрайз решения - у SQL Server 4 вида репликаций "из коробки" в самой базовой версии. Почти 25 лет назад делал на них "геокластер" на два континента. И ничего, работало
Не путайте тёлое с мягким. Для геолокализации нагрузок с 2008 года "из коробки" есть geo cluster. Шардировать же, если мы одинаково понимаем смысл термина, начинают по другим причинам, прежде всего по объемам данных.
Шардирование (распределенное по узлам секционирование) начинается с приближением к отметке "петабайт", что по вашим же словам, не ваш случай. Для начала нагрузка записи снижается (на порядки) прозрачным для приложений секционированием, которое, опять же, в SQL Server "из коробки" с 2005 года, а постгресу еще лет 10-15 догонять.