Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
В on premisis высокий трафик - редкое явление, если речь ведь о внутренней системе предприятия. Если речь о публично доступном продукте, то почти всё зависит от архитектуры ПО. Масштабирование тормозится не монолитностью, а наличием внутреннего состояния.
Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает on premises аналог. Однако, см. предыдущий пункт, каждый стартап считает, что завтра у него будет миллион запросов в секунду
"по умолчанию" используются "бесплатные" компоненты, прежде всего СУБД. Отсутствие знания продвинутых коммерческих продуктов приводит к раннему переходу на горизонтальное масштабирование и в итоге, многократно большим затратам на поддержку, несмотря на первоначальную экономию на лицензиях. Простой пример, производительность SQL Server примерно на порядок выше PostgreSQL (на CRUD ниже), там где можно обойтись одним-двумя узлами, придется делать десять реплик.
засилье Питона на бэкенде, производительность которого ниже на порядок даже Java, удивительным образом совмещается с заявлениями о высокой нагруженности.
Не раскрыта тема "как мы дошли до жизни такой", где стоимость создания и владения инфраструктурой может в разы превыщать стоимость ПО, для которого, собственно, вся эта инфраструктура и существует.
ООП на концептуальном уровне это всего два положения:
все моделируемые сущности суть объекты
объекты взаимодействуют пересылкой сообщений
На логическом уровне реализация ООП отличается от других языков только наследованием реализации (извините за тавтологию), остальное в том или ином виде имеется и в других языках.
Создание первых ООП-языков - середина 1960-х годов (Симула-67 - "Алгол с классами"), как следует из названия, они предназначались для имитационного моделирования (объекты активны), а не для пассивных сущностей вроде счетов и накладных. Второе удачное применение - целиком искусственные миры, вроде элементов графического интерфейса пользователя.
Основные критерии эффективности подходов:
степень связности компонентов (модулей)
степень повторного использования кода
По этим пунктам ООП показывает хороший результат, если не впадать в фанатизм "чистой архитектуры" и трезво оценивать метрики, когда объемы превышают хотя бы 100К строк.
Вы таки определитесь, можно ли оценивать best practies в незнакомой среде, или нельзя (вроде ваших откровений о неприемлемости конкатенации в динамическом сиквеле). И если искать логические ошибки в малознакомой среде не сильно сложнее, то в чем вообще проблема - генерируй и ищи.
Буду проще: старый "Жигуль-копейка" с проржавевшим днищем тоже ездит, если его постоянно проверять и чинить. Является ли это авто надежным - вопрос риторический.
Сами же пишете, что генерирует лажу и нужно постоянно присматривать. Но на незнакомом стеке вы просто эту лажу не распознаете и присматривать не можете. Поэтому иллюзия, что "неплохо применять".
Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
Полагаю, "решения на постгресах поверх чего попало" должны продолжать жить в своем мире
В on premisis высокий трафик - редкое явление, если речь ведь о внутренней системе предприятия. Если речь о публично доступном продукте, то почти всё зависит от архитектуры ПО. Масштабирование тормозится не монолитностью, а наличием внутреннего состояния.
Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
Что именно дороже в горизонтальной масштабируемости у SQL Server за вычетом того, что узлов потребуется в разы меньше?
Да здесь же на хабре поищите, раз сами тесты провести не можете. Раз, два
Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь
Тут несколько направлений, например:
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает on premises аналог. Однако, см. предыдущий пункт, каждый стартап считает, что завтра у него будет миллион запросов в секунду
"по умолчанию" используются "бесплатные" компоненты, прежде всего СУБД. Отсутствие знания продвинутых коммерческих продуктов приводит к раннему переходу на горизонтальное масштабирование и в итоге, многократно большим затратам на поддержку, несмотря на первоначальную экономию на лицензиях. Простой пример, производительность SQL Server примерно на порядок выше PostgreSQL (на CRUD ниже), там где можно обойтись одним-двумя узлами, придется делать десять реплик.
засилье Питона на бэкенде, производительность которого ниже на порядок даже Java, удивительным образом совмещается с заявлениями о высокой нагруженности.
Не раскрыта тема "как мы дошли до жизни такой", где стоимость создания и владения инфраструктурой может в разы превыщать стоимость ПО, для которого, собственно, вся эта инфраструктура и существует.
Не смог сдержать смеха после описания пункта "системный анализ". Однозначно, в хаб "Профюмор" :)
https://habr.com/ru/articles/885980/comments/#comment_27974176
Да, спасибо, подробностей и примеров надо бы добавить. Если еще накидаете буду благодарен. Сам я с темой Раста пока завязал.
В Расте и своих ужасов много. Похоже, подобное заявление имеют право делать только программисты на Си без плюсов :)
При этом в стандартной библиотеке всё еще нет ведения логов, и, помечтаем, сетевых коммуникаций хотя бы на уровне сокетов.
"Оно" нужно там, где объекты активные, прежде всего в задачах симуляции. Меньше всего нужно в информационных системах.
https://blog.arbinada.com/ru/category/01705-clean-architecture.html
Лучше так: "Решай простые задачи"
Ну, и риторическое: "Код, который сложен для одного, может быть простым для другого"
Вы таки определитесь, можно ли оценивать best practies в незнакомой среде, или нельзя (вроде ваших откровений о неприемлемости конкатенации в динамическом сиквеле). И если искать логические ошибки в малознакомой среде не сильно сложнее, то в чем вообще проблема - генерируй и ищи.
Буду проще: старый "Жигуль-копейка" с проржавевшим днищем тоже ездит, если его постоянно проверять и чинить. Является ли это авто надежным - вопрос риторический.
Сами же пишете, что генерирует лажу и нужно постоянно присматривать. Но на незнакомом стеке вы просто эту лажу не распознаете и присматривать не можете. Поэтому иллюзия, что "неплохо применять".