Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 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 догонять.
Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
В on premisis высокий трафик - редкое явление, если речь ведь о внутренней системе предприятия. Если речь о публично доступном продукте, то почти всё зависит от архитектуры ПО. Масштабирование тормозится не монолитностью, а наличием внутреннего состояния.
Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь
Если и тесты генерируют другие "промпты", то есть более дешевая альтернатива - кропить сервера святой водой.
В каждой шутке есть доля шутки :)
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 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 догонять.
Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
Полагаю, "решения на постгресах поверх чего попало" должны продолжать жить в своем мире
В on premisis высокий трафик - редкое явление, если речь ведь о внутренней системе предприятия. Если речь о публично доступном продукте, то почти всё зависит от архитектуры ПО. Масштабирование тормозится не монолитностью, а наличием внутреннего состояния.
Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
Что именно дороже в горизонтальной масштабируемости у SQL Server за вычетом того, что узлов потребуется в разы меньше?
Да здесь же на хабре поищите, раз сами тесты провести не можете. Раз, два
Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь