За последние 20 лет я видел несколько больших модульных конструкций баз данных и уже несколько раз видел сценарий, предложенный Дэвидом, где приложения имеют доступ на запись к своей собственной схеме / набору таблиц и доступ на чтение к другой схеме / набор столов. Чаще всего эти данные, к которым приложение / модуль получает доступ только для чтения, могут быть описаны как «основные данные» .
В то время я не видел проблем, которые, как предполагали предыдущие ответы, мне следовало бы видеть, поэтому я думаю, что стоит более подробно рассмотреть вопросы, поднятые в предыдущих ответах.
Сценарий: вы связываете пару компонентов непосредственно с RDBMS и видите, что один конкретный компонент становится узким местом в производительности
Я согласен с этим комментарием, за исключением того, что это также аргумент в пользу наличия копии данных локально для микросервиса для чтения. То есть большинство зрелых баз данных поддерживают репликацию, и поэтому без каких-либо усилий разработчика «основные данные» могут быть физически реплицированы в базу данных микросервиса, если это необходимо или необходимо.
Некоторые могли бы признать это в старом облике как «Корпоративная база данных», реплицируя основные таблицы в «Ведомственную базу данных». Суть в том, что, как правило, хорошо, если база данных делает это для нас со встроенной репликацией измененных данных (только разницы, в двоичной форме и с минимальными затратами для исходной базы данных).
И наоборот, когда выбор нашей базы данных не позволяет эту «репликационную» поддержку репликации, мы можем оказаться в ситуации, когда мы хотим передать «основные данные» в базы данных микросервисов, что может привести к значительным усилиям разработчиков и также будет существенно менее эффективным механизмом.
Возможно, вы захотите денормализовать базу данных, но вы не сможете, потому что все остальные компоненты будут затронуты
Для меня это утверждение просто не правильно. Денормализация - это «аддитивное» изменение, а не «критическое изменение», и ни одно приложение не должно прерваться из-за денормализации.
Единственный способ сломать приложение - это когда код приложения использует что-то вроде «select * ...» и не обрабатывает дополнительный столбец. Для меня это будет ошибка в приложении?
Как денормализация может сломать приложение? Похоже, FUD для меня.
Зависимость схемы:
Да, приложение теперь зависит от схемы базы данных, и подразумевается, что это должно быть серьезной проблемой. Хотя добавление какой-либо дополнительной зависимости, очевидно, не является идеальным, мой опыт показывает, что зависимость от схемы базы данных не была проблемой, так почему же это может иметь место? Мне просто повезло?
Основные данные
Схема, к которой мы обычно хотели бы, чтобы микросервис имел доступ только для чтения, чаще всего описывается как « основные данные » для предприятия. Он имеет основные данные, которые необходимы для предприятия.
Исторически это означает, что схема, от которой мы добавляем зависимость, является одновременно зрелой и стабильной (несколько фундаментальной для предприятия и неизменной).
нормализация
Если 3 дизайнера баз данных займутся разработкой нормализованной схемы БД, они получат одинаковый дизайн. Хорошо, может быть некоторое изменение 4NF / 5NF, но не очень. Более того, есть ряд вопросов, которые дизайнер может задать для проверки модели, чтобы дизайнер мог быть уверен, что они получили 4NF (я слишком оптимистичен? Люди борются с переходом на 4NF?).
Обновление: По 4НФУ здесь я имею в виду все таблицы в схеме должны их высшую нормальной форму до 4НФА (все таблицы получили нормировать соответственно до 4НФА).
Я полагаю, что процесс проектирования нормализации - это то, почему разработчики баз данных, как правило, довольны идеей зависимости от нормализованной схемы базы данных.
Процесс нормализации приводит дизайн БД к известному «правильному» дизайну, а отклонения от него должны быть денормализованы для производительности.
- Могут быть вариации, основанные на поддерживаемых типах БД (JSON, ARRAY, поддержка Geo-типов и т. Д.)
- Некоторые могут утверждать, что вариации основаны на 4NF / 5NF.
- Мы исключаем физические изменения (потому что это не имеет значения)
- Мы ограничиваем это дизайном OLTP, а не дизайном DW, потому что это схемы, которым мы хотим предоставить доступ только для чтения
Если бы 3 программиста получили проект для реализации (в виде кода), ожидание было бы для 3 разных реализаций (потенциально очень разных).
Для меня потенциально существует вопрос "веры в нормализацию".
Ломать схему изменениями?
Денормализация, добавление столбцов, изменение столбцов для увеличения объема памяти, расширение дизайна новыми таблицами и т. Д. - все это неразрывные изменения, и дизайнеры БД, которые получили 4-ую нормальную форму, будут в этом уверены.
Разрывные изменения, очевидно, возможны путем удаления столбцов / таблиц или внесения разрывающих типов. Возможно да, но в практическом плане у меня здесь вообще не было проблем. Возможно, потому что понятно, что такое серьезные изменения, и с ними хорошо справились?
Мне было бы интересно услышать случаи нарушения схемы в контексте общих схем только для чтения.
Что важнее и важнее в микросервисе: его API или схема базы данных? API, потому что это его контракт с остальным миром.
Хотя я согласен с этим утверждением, я думаю, что есть важный нюанс, который мы могли бы услышать от Enterprise Architect: «Данные живут вечно» . То есть, хотя API может быть самой важной вещью, данные также довольно важны для предприятия в целом, и они будут важны в течение очень долгого времени.
Например, когда возникает необходимость заполнить хранилище данных для бизнес-аналитики, схема и поддержка CDC становятся важными с точки зрения бизнес-отчетности независимо от API.
Проблемы с API?
Теперь, если бы API были безупречными и простыми, все вопросы были спорными, так как мы всегда выбирали бы API, а не имели бы локальный доступ только для чтения. Таким образом, мотивация даже для рассмотрения локального доступа только для чтения состоит в том, что могут быть некоторые проблемы с использованием API, которых избегает локальный доступ.
What motivates people to desire local read-only access?
Оптимизация API:
У LinkedIn есть интересная презентация (с 2009 года) по вопросу оптимизации их API и почему это важно для них в их масштабе. http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment
Короче говоря, если API должен поддерживать множество различных вариантов использования, он может легко попасть в ситуацию, когда он оптимально поддерживает один вариант использования, а остальные - довольно плохо с точки зрения сети и базы данных.
Если API не обладает той же сложностью, что и LinkedIn, вы можете легко получить сценарии, в которых:
- API извлекает гораздо больше данных, чем вам нужно (расточительно)
- Chatty API, где вы должны вызывать API много раз
Да, конечно, мы можем добавить кеширование в API, но в конечном итоге вызов API - это удаленный вызов, и разработчикам предоставляется ряд оптимизаций, когда данные локальны.
Я подозреваю, что есть множество людей, которые могли бы добавить это как:
- Низкая стоимость репликации основных данных в микросервисную базу данных (без затрат на разработку и технически эффективна)
- Вера в нормализацию и устойчивость приложений к изменениям схемы
- Возможность легко оптимизировать каждый сценарий использования и потенциально избежать ненужных удаленных вызовов API.
- Плюс некоторые другие преимущества с точки зрения ограничений и согласованного дизайна
Этот ответ слишком длинный. Извиняюсь !!