Видимо в вашем понимании в мире микросервисов все происходит легко, а если приложение монолитное, то все становится резко сложнее.
По факту, с точки зрения развертывания, монолит это один микросервис. Докеру и куберу абсолютно без разницы что у вас в образе. Все техники devops применяются для монолитов точно также, как для микросервисов. Только меньше сервисов надо деплоить\обновлять.
Монолиты очевидно жрут меньше ресурсов. Оверхед приложений\контейнеров\виртуальных машин меньше, так как просто меньше инстансов поднимать. Экономия на объеме данных, IO и трафика для очередей и синхронизации. Не нужны системы сбора и анализа распределенных логов.
Скейлится монолит очень лего. Не хватает ресурсов - добавляем. Как я уже писал выше - сначала scale up, потом scale out. Да, вы будете скейлить одновременно и память и процессоры, потому что программа упрется во что-то одно. Так и хосты для кубера вы также будете скейлить одновременно и по памяти и по процессорам.
У микросервисов есть одно неоспоримое преимущество перед монолитом - высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
у вас в монолите в обработчике очереди паника, сервисы валятся и лежит весь монолит
Во-первых это красивая байка, но во всех современных системах исключения перехватываются и логируются, а фронт продолжает отвечать на запросы, даже если какая-то фоновая задача падает.
Во-вторых в монолитах самих очередей будет меньше, так как они просто не нужны. передача управления делается вызовом функции.
Так что я пока не увидел преимущества монолита перед микросервисом
Ну да, снижение затрат в 10 это не преимущество, а фигня какая-то.
Если факты противоречат моей теории — тем хуже для фактов (с) Гегель
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
Вы же в курсе что тот же фаулер в книге POEAA 2000 года ругал архитектуру основанную на децентрализации данных и business-capabilities?
В этом конкретном случае: стоимость передачи данных между микросервисами оказалась слишком высока, что увеличивало стоимость решения до неприемлемого уровня.
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо.
Как его скейлить?
Также как микросервисы - увеличивать количество инстансов. Вообще горизонтально масштабирование придумали сильно раньше, чем микросервисы.
микросервисы я мог скейлить независимо друг от друга, а монолит?
Вместо 10 экземпляров каждого сервиса ты поднимаешь 10 экземпляров монолитного приложения. Это мало того что меньше сожрет ресурсов, но быстрее работать будет.
мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
При правильной архитектуре у тебя не создаются объекты если нет запросов. Поэтому простаивающие части приложений будут жрать ничего. В отличие от простаивающих микросервисов.
что делать, когда данных много и в один монолит не вмещается?
Это как? Масштабирование хранилища в монолите и микросервисах никак не отличается. Масштабирование вычислений в микросервисах делается также как в монолите - вы просто увеличиваете количество узлов. Монолит в свою очередь экономит вычислительные ресурсы, так как не занимается перекладыванием данных через хранилище. (пример из статьи amazon prime)
увеличивать количество монолитов(ой, не это же первый шаг к микросервисам) или раздувать саму машину?
Сначала scale up, потом scale out. Это все делалось задолго до изобретения микросервисов.
как этот монолит перезапускать без потери качества и данных?
Как обычно one node at a time.
что делать если он упадет?
Поднимать. Опять-таки задолго до изобретения микросервисов изобрели feature flags, VIP switch и другие технологии zero-downtime деплоймента.
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Где почитать как сделать api, который не будет меняться при изменении требований?
При изменении требований у вас будут падать не только тесты, которые покрывают изменившиеся сценарии, но и другие тесты, которые просто вызывают те же api
Именно хрупкость тестов при развитии программ и напрягает при использовании tdd.
Где вы возьмете API, для которого будете писать тесты?
Получается что при изменении требований надо править не только код, который их реализует, но и тесты? В том числе тесты которые упадут просто от изменения API, а не от изменения логики работы.
Про проверки при странных случаях - соглашусь, тесты помогут. Но это не TDD и покрытие таких тестов обычно небольшое.
Конечно зависит. Учитывая что движок реляционной БД пилят люди разбирающиеся в теме гораздо лучше меня, то я буду предполагать что там эта проблема решена. А если что-то не получается, то это я не делаю что-то не так.
Но вообще для встраиваемой базы хранить картинки - непонятная затея. У нее варианты использования сильно отличаются от серверов баз данных.
очередная революционная рейвендиби может не иметь
Это вы уже пытаетесь юлить, чтобы ваши утруждения не выглядели столь неубедительно. Но очевидно речь идет о взрослых СУБД, которых в нашей реальности существует 4-5 штук.
Думаю люди среагировали бы куда мене бурно, если бы эта инфорация была в первом комменте вида "а вы знаели что бд X,Y,Z автоматически это оптимизируют и вам не нужно ничего делать?
Началось все с коммента об ускорении запросов после разделения таблицы на две. Очевидно что дело не в том, как работает база, а в том, что после такого разделения ORM начал генерировать проекцию, которая не включала поле с картинкой в каждый запрос.
В какой-то момент программист, увидев что программа работает медленно, посчитал что это не его вина, а вина БД, а он такой умный сможет решить. И, к сожалению, решил, что увеличило уверенность в себе.
Закончу тем, с чего начал коммент, на который вы отвечали - хороший программист не считает себя умнее других.
Опять таки "в общем случае", когда соотношение чтения записи 100:1 или выше, индексы выгодны. Количество запросов, которые вообще стоит ускорять с помощью индексов, ограничено сверху. Вряд ли вы в своей жизни увидите ситуацию когда индексы делают быстродействие хуже.
В том же общем случае нет смысла делать 1-к-1, так как изменение быстродействия вы не заметите.
Конечно в общем случае у вас запросы нормальные: проекции прописаны, предикаты можно свести к индексам, статистика в порядке, нет вариативности условий по параметрам.
Самое главное качество хорошего разработчика - не считать себя умнее других. Если вдруг мой код, который работает с БД оказывается медленным, то я думаю что это я что-то не знаю или не так сделал, а не база плохо работает.
Я очень сомневаюсь что разработчики движков БД не сталкивались с проблемой хранения блобов в БД и никогда не занимались оптимизацией этого. Поэтому считаю крайне наивными размышления людей о том, что они сейчас сделают связь 1-к-1 чем ускорят программу.
Конечно они её ускорят, но совершенно не по тем причинам, по которым они думают что ускорят.
Я не скажу за все БД, но в MSSQL, MySQL и PostgreSQL блобы размером 10мб будет храниться в отдельных страницах. А если правильные типы подобрать, то оверхед от блобов будет не больше одного указателя в основных страницах таблицы. И почему-то я уверен что в Oracle будет также.
В "общем случае" можно сделать по таблице на поле, но это займет сильно больше места и будет сильно дольше будет работать на любой проекции где больше одного поля.
Прикол в том, что нам зачастую надо ускорять сложные запросы, а не примитивные. Для примитивных вообще можно сделать покрывающие индексы.
Ну это если не читать спецификацию языка
С#, Kotlin и даже, внезапно, Python. Но у последнего сложнее с completeness и redundancy check.
Чем вы ифы замените в таком случае?
Уже появились вакансии Mojo с опытом от 3 лет?
Это вы уже сделали неправильно.
Видимо в вашем понимании в мире микросервисов все происходит легко, а если приложение монолитное, то все становится резко сложнее.
По факту, с точки зрения развертывания, монолит это один микросервис. Докеру и куберу абсолютно без разницы что у вас в образе. Все техники devops применяются для монолитов точно также, как для микросервисов. Только меньше сервисов надо деплоить\обновлять.
Монолиты очевидно жрут меньше ресурсов. Оверхед приложений\контейнеров\виртуальных машин меньше, так как просто меньше инстансов поднимать. Экономия на объеме данных, IO и трафика для очередей и синхронизации. Не нужны системы сбора и анализа распределенных логов.
Скейлится монолит очень лего. Не хватает ресурсов - добавляем. Как я уже писал выше - сначала scale up, потом scale out. Да, вы будете скейлить одновременно и память и процессоры, потому что программа упрется во что-то одно. Так и хосты для кубера вы также будете скейлить одновременно и по памяти и по процессорам.
У микросервисов есть одно неоспоримое преимущество перед монолитом - высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
Во-первых это красивая байка, но во всех современных системах исключения перехватываются и логируются, а фронт продолжает отвечать на запросы, даже если какая-то фоновая задача падает.
Во-вторых в монолитах самих очередей будет меньше, так как они просто не нужны. передача управления делается вызовом функции.
Ну да, снижение затрат в 10 это не преимущество, а фигня какая-то.
Вы же в курсе что тот же фаулер в книге POEAA 2000 года ругал архитектуру основанную на децентрализации данных и business-capabilities?
В этом конкретном случае: стоимость передачи данных между микросервисами оказалась слишком высока, что увеличивало стоимость решения до неприемлемого уровня.
Также как микросервисы - увеличивать количество инстансов. Вообще горизонтально масштабирование придумали сильно раньше, чем микросервисы.
Вместо 10 экземпляров каждого сервиса ты поднимаешь 10 экземпляров монолитного приложения. Это мало того что меньше сожрет ресурсов, но быстрее работать будет.
При правильной архитектуре у тебя не создаются объекты если нет запросов. Поэтому простаивающие части приложений будут жрать ничего. В отличие от простаивающих микросервисов.
Это как? Масштабирование хранилища в монолите и микросервисах никак не отличается. Масштабирование вычислений в микросервисах делается также как в монолите - вы просто увеличиваете количество узлов. Монолит в свою очередь экономит вычислительные ресурсы, так как не занимается перекладыванием данных через хранилище. (пример из статьи amazon prime)
Сначала scale up, потом scale out. Это все делалось задолго до изобретения микросервисов.
Как обычно one node at a time.
Поднимать. Опять-таки задолго до изобретения микросервисов изобрели feature flags, VIP switch и другие технологии zero-downtime деплоймента.
В данном случае вполне оправдано.
Еще нужен минус за "сгенерировано AI"
Где почитать как сделать api, который не будет меняться при изменении требований?
При изменении требований у вас будут падать не только тесты, которые покрывают изменившиеся сценарии, но и другие тесты, которые просто вызывают те же api
Именно хрупкость тестов при развитии программ и напрягает при использовании tdd.
Где вы возьмете API, для которого будете писать тесты?
Получается что при изменении требований надо править не только код, который их реализует, но и тесты? В том числе тесты которые упадут просто от изменения API, а не от изменения логики работы.
Про проверки при странных случаях - соглашусь, тесты помогут. Но это не TDD и покрытие таких тестов обычно небольшое.
их можно не хранить. напрмиер mssql умеет sparse columns
проблема в том, что это искусственный пример. А реалистичных примеров где уместно 1-к-1 хрен найдешь.
В номральных языках есть pattern matching с completeness и redundancy check. Сложно становится накосячить.
Что такое тейблспейс? Зачем на них раскладывать таблицы?
Конечно зависит. Учитывая что движок реляционной БД пилят люди разбирающиеся в теме гораздо лучше меня, то я буду предполагать что там эта проблема решена. А если что-то не получается, то это я не делаю что-то не так.
Вы удивитесь https://www.sqlite.org/fasterthanfs.html
Но вообще для встраиваемой базы хранить картинки - непонятная затея. У нее варианты использования сильно отличаются от серверов баз данных.
Это вы уже пытаетесь юлить, чтобы ваши утруждения не выглядели столь неубедительно. Но очевидно речь идет о взрослых СУБД, которых в нашей реальности существует 4-5 штук.
Началось все с коммента об ускорении запросов после разделения таблицы на две. Очевидно что дело не в том, как работает база, а в том, что после такого разделения ORM начал генерировать проекцию, которая не включала поле с картинкой в каждый запрос.
В какой-то момент программист, увидев что программа работает медленно, посчитал что это не его вина, а вина БД, а он такой умный сможет решить. И, к сожалению, решил, что увеличило уверенность в себе.
Закончу тем, с чего начал коммент, на который вы отвечали - хороший программист не считает себя умнее других.
Опять таки "в общем случае", когда соотношение чтения записи 100:1 или выше, индексы выгодны. Количество запросов, которые вообще стоит ускорять с помощью индексов, ограничено сверху. Вряд ли вы в своей жизни увидите ситуацию когда индексы делают быстродействие хуже.
В том же общем случае нет смысла делать 1-к-1, так как изменение быстродействия вы не заметите.
Конечно в общем случае у вас запросы нормальные: проекции прописаны, предикаты можно свести к индексам, статистика в порядке, нет вариативности условий по параметрам.
Самое главное качество хорошего разработчика - не считать себя умнее других. Если вдруг мой код, который работает с БД оказывается медленным, то я думаю что это я что-то не знаю или не так сделал, а не база плохо работает.
Я очень сомневаюсь что разработчики движков БД не сталкивались с проблемой хранения блобов в БД и никогда не занимались оптимизацией этого. Поэтому считаю крайне наивными размышления людей о том, что они сейчас сделают связь 1-к-1 чем ускорят программу.
Конечно они её ускорят, но совершенно не по тем причинам, по которым они думают что ускорят.
Легко: Укладываем все в одну таблицу.
Я не скажу за все БД, но в MSSQL, MySQL и PostgreSQL блобы размером 10мб будет храниться в отдельных страницах. А если правильные типы подобрать, то оверхед от блобов будет не больше одного указателя в основных страницах таблицы. И почему-то я уверен что в Oracle будет также.
В "общем случае" можно сделать по таблице на поле, но это займет сильно больше места и будет сильно дольше будет работать на любой проекции где больше одного поля.
Прикол в том, что нам зачастую надо ускорять сложные запросы, а не примитивные. Для примитивных вообще можно сделать покрывающие индексы.