Вакансия:
"-Разработка высоконагруженного бэкенда для медицинского приложения;

базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"

Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:


И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.

Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Здравствуйте, IncremenTop, Вы писали:
> но когда куча микросервисов лазит к одной бд...
а в чём проблема?
и какая альтернатива для медицинских данных, как в этом случае?

Здравствуйте, IncremenTop, Вы писали:

IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной б

А если к разным? А если к одной, но разные схемы с тем чтобы в перспективе можно было разнести на разные физические базы?

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Реляционная база — это хорошо известное средство для хранения данных. Универсальный такой инструмент, который можно успешно применить для большинства случаев. Так что его можно вполне использовать "по умолчанию", и только если у тебя что-то достаточно специальное — искать более оптимальное решение.

И именно для небольших проектов сложности с подбором нестандартного способа хранения наименее оправданны. Бюджет вряд ли большой, а то что реляционная БД тут будет работать несколько хуже чем что-то специализированное — так и проект небольшой, разница может оказаться незаметна вообще.

Здравствуйте, IncremenTop, Вы писали:


IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.

IT>И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Не все архитекторы стремятся сделать "модно молодёжно".
Некоторые делают так, как разумно в их конкретной ситуации с учётом всех требований и ограничений.

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени.
Небольшое количество данных, привязанных ко времени, достаточно просто хранить в реляционных базах.
А большое — нигде неудобно

Тут еще бывает так:
1) Приложение хранит финансовые данные
2) Используется oracle/mssql
3) В коде все запросы к базе в режиме без выставленных транзакций [Тут должен быть блюющий смайлик].

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?

А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

Здравствуйте, vmpire, Вы писали:

V>Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.

Это неудобно в принципе. Удобно это лишь людям, которые пишут логику на хп.

V>Не все архитекторы стремятся сделать "модно молодёжно".

Этот дурень как раз взял худшие стороны со всех подходов.

И модно-молодежно это было лет 10 назад, сейчас уже архитектор, которые знает только реляционные профнепригоден.

IT>>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
V>Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

Прочитай внимательнее, что я написал — не из мира финтеха.

И да — распределенные транзакции применяются очень редко.

V>Небольшое количество данных, привязанных ко времени, достаточно просто хранить в реляционных базах.

Просто в реляционных не получится.

Здравствуйте, torvic, Вы писали:

T>а в чём проблема?

Тестируемость, масштабируемость, сопровождаемость.

За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.

Это как из всех подходов выбрать худшее.

Здравствуйте, IncremenTop, Вы писали:

V>>Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

IT>Прочитай внимательнее, что я написал — не из мира финтеха.

И вне мира финтеха ACID — это очень хорошо/

IT>И да — распределенные транзакции применяются очень редко.

И как это отменяет необходимость acid?

Здравствуйте, Jack128, Вы писали:

J>А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

Возьмем документоориентированные БД — у тебя уже в БД хранится та самая дтошка и на уровне документа как раз поддержка есть.
Никаких джойнов как раз не надо. Даже порой схему не надо разрабатывать, если совсем уж надо быстро.

Здравствуйте, torvic, Вы писали:

T>Здравствуйте, IncremenTop, Вы писали:
>> но когда куча микросервисов лазит к одной бд...
T>а в чём проблема?
T>и какая альтернатива для медицинских данных, как в этом случае?

Да нет проблем. Ключевое в микро-сервисе это то, что к его данным есть доступ только через его апи, а где они лежат — это уже дело второстепенное. Сегодня они могут лежать в одной бд, завтра в другой потом вообще на другом сервере.

Здравствуйте, IncremenTop, Вы писали:

Как то, друг, ты очень сумбурно написал какими то бессвязными кусками.

IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд,

Где куча микросервисов лазит к одной БД?

IT>И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.

Бывает. Некоторые архитекты и не такое учудяют.

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?

Почему нет? РСУБД это удобно. И с чего ты взял что ACID нужен только в финтехе. ACID на самом деле нужен практически везде, просто не везде за него готовы платить.

IT> За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени.

Почему неудобно? Очень удобно. Специализированные time series db ничуть не более удобны, их плюс не в удобстве, а в том что они жрут в хайлоаде меньше ресурсов. Но небольшие проекты это, как правило, и небольшая нагрузка, на которой особой разницы между RDBMS и TSDB по ресурсам нет, а зрелость, развитые средства и богатый функционал первых остается.

Здравствуйте, IncremenTop, Вы писали:

V>>Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.
IT>Это неудобно в принципе. Удобно это лишь людям, которые пишут логику на хп.
Не очень понял, что именно неудобно.

V>>Не все архитекторы стремятся сделать "модно молодёжно".
IT>Этот дурень как раз взял худшие стороны со всех подходов.
Аргументы?

IT>И модно-молодежно это было лет 10 назад, сейчас уже архитектор, которые знает только реляционные профнепригоден.
Никто не говорил, что он больше ничего не знает. Речь шла об оптимальности решания в конкретных условиях.

V>>Небольшое количество данных, привязанных ко времени, достаточно просто хранить в реляционных базах.
IT>Просто в реляционных не получится.
Вот сейчас удивились бы производители реляционных баз, которые туда возможность создания темпоральных таблиц давно ввели.
Да и просто колонку с датой валидности добавить несложно.
Запросы будут подтормаживать, но для небольших объёмов данных это несущественно.

Здравствуйте, IncremenTop, Вы писали:

J>>А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

IT>Возьмем документоориентированные БД — у тебя уже в БД хранится та самая дтошка и на уровне документа как раз поддержка есть.
IT>Никаких джойнов как раз не надо. Даже порой схему не надо разрабатывать, если совсем уж надо быстро.
Ну так можно и просто в файл сложить, зачем тогда вообще база?
Смысл документ-ориентированных баз в возможности операции частями документа и в возможности ограничений его структуры.

Здравствуйте, vmpire, Вы писали:

V>Не очень понял, что именно неудобно.

Как ты будешь писать юнит-тесты?
Как ты будешь поддерживать и сопровождать этот код на sql?

Это удобно лишь при разработке определенным категориям людей, которые все вопросы решают одной хранимкой, которая лазит по базе.

V>Аргументы?

Аргументы, что суть микросервисной архитектуры именно в распределенности — в возможности масштабировать разные части системы. Но вместо этого у нас появляется единая точка отказа, причем в которой еще находится логика. Зачем тогда микросервисы?

V>Никто не говорил, что он больше ничего не знает. Речь шла об оптимальности решания в конкретных условиях.

Оптимальностью не пахнет. Напоминает одного архитектора, который дропнул бэк и написал все на хранимках постгре.


V>Вот сейчас удивились бы производители реляционных баз, которые туда возможность создания темпоральных таблиц давно ввели.

Ну да, ты еще приведи слова Тома Кайта.
Я не спорю, что на SQL можно даже космолеты программировать. Но зачем?

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Шоб вам многоэтажные запросы в монгодб отлаживать.

Здравствуйте, Слава, Вы писали:

С>Шоб вам многоэтажные запросы в монгодб отлаживать.

Я же не извращенец, чтобы на документо-ориентированной реализовывать реляционную.

Здравствуйте, IncremenTop, Вы писали:

С>>Шоб вам многоэтажные запросы в монгодб отлаживать.

IT>Я же не извращенец, чтобы на документо-ориентированной реализовывать реляционную.

Одно их основных преимуществ реляционных БД — это гибкость дизайна. И об этом пишет Дейт, а взял он это из тех времён, когда программы всё ещё писались по делу, и в индустрии были какие-никакие исследования. Суть в следующем — схему в реляционке проще поменять без ошибок, чем сделать то же самое с документно-ориентированной базой.

Здравствуйте, Слава, Вы писали:

С> Суть в следующем — схему в реляционке проще поменять без ошибок, чем сделать то же самое с документно-ориентированной базой.



Т.е. ты на серьезных щщах утверждаешь, что легче менять что-то в сильно-связанной системе, чем в слабосвязанной?

И да — реляционные базы взялись из реализации теории, целью которой было в том числе непротиворечивость и отсутствие избыточности данных, а не универсальный всемогутор. Сейчас особенно актуально последнее, когда все стали внезапно денормализовывать БД.

Здравствуйте, IncremenTop, Вы писали:

С>> Суть в следующем — схему в реляционке проще поменять без ошибок, чем сделать то же самое с документно-ориентированной базой.
IT>Т.е. ты на серьезных щщах утверждаешь, что легче менять что-то в сильно-связанной системе, чем в слабосвязанной?

Да, именно. С условием "сохранить целостность данных". Без этого условия конечно можно менять что хошь.

IT>Сейчас особенно актуально последнее, когда все стали внезапно денормализовывать БД.

Тут в канале гоферов недавно люди обнаружили, что порядок колонок в индексе важен. Примерно поэтому и возник спрос на денормализацию.