Комментарии 15
Один из не упомянутых плюсов shared db: вы можете использовать поддержку целостности данных на уровне одной бд, foreign keys, triggers, вот это все.
Если вам надо добавить табличку, где есть FK на пять других табличек, не надо плясать с бубном как сделать это консистенто.
Если у вас разные сервисы работают с shared db, неплохо бы разделить их на юзеров с соотв. правами. Иногда писать/лочить определенную табличку и не требуется более чем одному сервису, что также уберет ряд проблем.
> если один из них добавит новую колонку в таблицу users с NOT NULL другой будет моментально сломан
В таких случаях надо всегда иметь дефолтное значение. То же самое когда добавляете новые аргументы в функцию/метод. Конечно по фен-шую надо делать анализ кода всех сервисов/проектов, рефакторить и т.д. Однако, коммерческая разработка - это редко про фен-шуй...
Автору следует познакомиться с такими вещами, как:
распределенные БД, обеспечивающие взаимодейсивие между разными экземплярами целевой бд (разные сервисы взаимодействуют со своей копией)
горизонтальная и вертикальная проекция. для локализаци и разграничения прав доступа и нотации предикатов отношений
хранимые процедуры, обеспечивающие единый интерфейс взаимодействия с данными.
acid принцип это единственный правильный принцип для реляционных баз данных. Всё остальное это костыли.
грамотно спроектированная архитектура позволяет избежать таких "детских" ошибок, как приведенные в статье. А все потому, что никто не удосуживается нормаль изучать теорию и практику. зачем? ведь все же просто таблицы, колонки, ячейки.. какие такие физические, логические и пользовательские представления. какие такие домены, что такое отношения и связи.. что такое индексные структуры для чего это вообще.. как и чем живёт субд.. похер. нахерачим таблиц.. и индексов. да побольше. будем трелевать данные через хер пойми что самописное вместо штатного функционала. зачем изучать методы семантического моделирования и оптимизации ведь все и так понятно. а если все начнёт тупить, то конечно.. это технология такая ацтойная.
Если бы вы разрабатывали обычный монолит или сервис со своим хранилищем, то вы просто переименовали бы колонку в
telegram_id, а также поправили код, который с ней взаимодействует.
Врядли кто-то станет так делать, это очень регрессионно и трудозатратно. Для описанной вами задачи проще было бы добавить новую таблицу в которой для userId хранить список его каналов.
один сервис занимается регистрацией пользователей через web, а другой регистрирует через реферальную программу
Я не понял многие доводы, но этот, имхо, где-то за гранью. Два отдельных сервиса для регистрации пользователя? Ну ок, это может быть и правильно в некоторых случаях, но тогда это должны быть эдакие "прокси-сервисы", которые тупо мапят специфику в "настоящий" сервис пользователей. Надеюсь, вы не предлагаете создавать отдельную базу под каждый способ регистрации?
Скорее всего, я просто не допёр или выпустил из текста что-то важеое..
Более простой пример: один сервис пишет данные в таблицу, а второй читает из нее. Изменили схему таблицу и потенциально сломали один из них или оба.
давайте разберём первоначальный пример: вы предлагаете делать отдельные базы под каждый способ регистрации? Если да, то как со всем этим работать? Если нет - зачем тогда это всё?
Что меняется с более простым примером? Проблема просто переносится с уровня БД на уровень АПИ. И отследить её становится гораздо сложнее. Версионность АПИ может помочь, но далеко не всегда.
Я не против самодостаточных микросервисов (какими они и должны быть), но примеры в статье, мягко говоря, странные.
Тут нужно понимать зачем логика для работы на чтение и на запись были разделены в разные деплоймент единицы. Может быть разделение было ошибкой?
Как знать, может и CQRS вам помочь. А может только усугубить.
Интеграционная или shared база данных это архитектурный подход с которым мне часто приходилось сталкиваться, и практически никогда эта встреча не сулила ничего хорошего.
Так это вы ещё не встречались значит с проблемами подходов, которые не используют общую базу.
Суть ведь не меняется. У вас есть одна предметная область, но разные сценарии и требования, которые вызывают конфликты в моделях.
Что вам сулит много хорошего: микросервисы, serverless, акторы? Допустим, микросервисы. Решать придётся точно такие же проблемы:
Менять API микросервиса страшно. Вам так же придется бегать по потребителям и проверять не используют ли они изменяемый API.
Точно так же у вас появится shared микросервис. Если им владеет другая команда, вы получите все перечисленные организационные проблемы.
Отказавшись от shared базы в пользу микросервисов, вам придется так же отказаться от многих плюшек. Опытные DB девелоперы умеют аудит через механизмы СУБД, умеют генерировать динамический SQL, расширять возможности базы, гибко настраивать политики доступа, встраиваться в аналитические системы и прочее.
Объединять потоки коммуникации микросервисов тоже становится невозможно или очень сложно. Например, у вас один сервис GraphQL, другой REST, а третий gRPC. Новая команда аналитики хочет получить доступ к некоторым данным в потоке из этих сервисов. Им вместо банальной выгрузки из базы придется писать адаптеры для всех перечисленных протоколов. Или идти напрямую в хранилища этих сервисов... Oh, wait! Это же нарушение инкапсуляции.
Классические СУБД и архитектура с общей базой данных успешно функционируют уже 40 лет. И не зря. Как минимум инструментально, это позволяет решать многие проблемы наших систем. В то время как другие подходы за иллюзорной простотой могут скрывать проблемы, решение которых может и не существует даже.
Так что пока эти решения не найдём, называть shared базу данных антипаттерном рановато.
Кто б автору про ESB технологии рассказал, про архитектуру данных, проектирование интеграции.....
Большая часть проблем надумана и если подходить к ним с точки зрения что менять страшно и сломаеться, то наверное стоит вообще завязывать с разработкой и архитектурой, ну не всем это дано.
Практически не существует плохой архитектуры, есть только неумение её готовить или попытка натягивания её туда где она ну уж совсем не к месту.
И заголовок бы привели к какому одному поняитию.
Есть интеграция на уровне БД
Есть шаблон общая БД.
И есть интеграционная БД, про которую в статье нет вообще ничего.
Интеграционная БД это сущность схожая по функциональности с BFF, то-есть она предоставляет доступ внешним сервисам к данным не в том виде как они храняться, а в том виде как с ними удобно работать, как правило только на чтение, как правильно это вообще БД на движке отличном от основной БД, ориентированная на решение своей узко спкциализированной задачи.
А зачем работать с запросами? Наверное проще работать с хранимыми процедурами. И там уже работать с колонками или таблицами.
Почему интеграционная БД это отстой