Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, 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 и нежелании её иметь
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает on premises аналог. Однако, см. предыдущий пункт, каждый стартап считает, что завтра у него будет миллион запросов в секунду
"по умолчанию" используются "бесплатные" компоненты, прежде всего СУБД. Отсутствие знания продвинутых коммерческих продуктов приводит к раннему переходу на горизонтальное масштабирование и в итоге, многократно большим затратам на поддержку, несмотря на первоначальную экономию на лицензиях. Простой пример, производительность SQL Server примерно на порядок выше PostgreSQL (на CRUD ниже), там где можно обойтись одним-двумя узлами, придется делать десять реплик.
засилье Питона на бэкенде, производительность которого ниже на порядок даже Java, удивительным образом совмещается с заявлениями о высокой нагруженности.
Не раскрыта тема "как мы дошли до жизни такой", где стоимость создания и владения инфраструктурой может в разы превыщать стоимость ПО, для которого, собственно, вся эта инфраструктура и существует.
ООП на концептуальном уровне это всего два положения:
все моделируемые сущности суть объекты
объекты взаимодействуют пересылкой сообщений
На логическом уровне реализация ООП отличается от других языков только наследованием реализации (извините за тавтологию), остальное в том или ином виде имеется и в других языках.
Создание первых ООП-языков - середина 1960-х годов (Симула-67 - "Алгол с классами"), как следует из названия, они предназначались для имитационного моделирования (объекты активны), а не для пассивных сущностей вроде счетов и накладных. Второе удачное применение - целиком искусственные миры, вроде элементов графического интерфейса пользователя.
Основные критерии эффективности подходов:
степень связности компонентов (модулей)
степень повторного использования кода
По этим пунктам ООП показывает хороший результат, если не впадать в фанатизм "чистой архитектуры" и трезво оценивать метрики, когда объемы превышают хотя бы 100К строк.
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, 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 и нежелании её иметь
Тут несколько направлений, например:
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает 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