Я уверен, что вы видели это грядущее "Это зависит".
Это зависит от всего. И решение для обмена данными о клиентах для отдела A может быть совершенно другим для обмена данными о клиентах с отделом B.
Моя любимая концепция, которая выросла за эти годы, - это концепция «Возможная последовательность». Термин произошел от Amazon, говоря о распределенных системах.
Предположение заключается в том, что, хотя состояние данных в распределенном предприятии сейчас может быть не вполне согласованным, оно "в конечном итоге" будет.
Например, когда запись о клиенте обновляется в системе A, данные о клиенте системы B теперь устарели и не совпадают. Но, «в конце концов», запись из A будет отправлена B через некоторый процесс. Итак, в конце концов, два экземпляра будут совпадать.
Когда вы работаете с одной системой, у вас нет «EC», скорее, у вас есть мгновенные обновления, единый «источник правды» и, как правило, механизм блокировки для обработки условий гонки и конфликтов.
Чем больше ваши операции способны работать с данными "EC", тем легче разделить эти системы. Простой пример - хранилище данных, используемое продажами. Они используют DW для запуска своих ежедневных отчетов, но они не запускают свои отчеты до раннего утра, и они всегда смотрят на данные «вчерашних» (или более ранних). Таким образом, нет необходимости в реальном времени, чтобы DW полностью соответствовала ежедневной операционной системе. Вполне допустимо, чтобы процесс выполнялся, скажем, в конце рабочего дня и переносился на несколько дней транзакций и операций в большом количестве в одной большой операции обновления.
Вы можете видеть, как это требование может решить множество проблем. Для данных о транзакциях нет разногласий, нет опасений, что некоторые данные отчетов изменятся в процессе накопления статистики, потому что отчет сделал два отдельных запроса к действующей базе данных. Нет необходимости, чтобы высокодетализированная болтовня поглощала работу сети, процессора и т. Д. В течение дня.
Это предельный, упрощенный и очень грубый пример ЕС.
Но рассмотрим такую большую систему, как Google. Как пользователь Search, мы понятия не имеем, когда и сколько времени понадобится для результата поиска, который Google собирает до уровня поиска на странице поиска. 1мс? 1s? 10s? 10hrs? Легко представить, как, если вы попадаете на серверы Googles West Coast, вы вполне можете получить другой результат поиска, чем если бы вы попали на их серверы East Coast. Ни в коем случае эти два случая не являются полностью согласованными. Но по большей части они в основном последовательны. И для их случая использования их потребители действительно не затронуты задержкой и задержкой.
Рассмотрим электронную почту. A хочет отправить сообщение B, но в процессе сообщение направляется через систему C, D и E. Каждая система принимает сообщение, принимает на себя полную ответственность за него, а затем передает его другому. Отправитель видит, что электронная почта отправляется в путь. Приемник на самом деле не скучает по нему, потому что они не обязательно знают его приход. Таким образом, существует большое окно времени, которое может понадобиться для того, чтобы это сообщение прошло через систему, и никто не заботится о том, насколько быстро это происходит.
С другой стороны, А мог разговаривать по телефону с Б. «Я только что отправил, ты уже получил? Сейчас? Сейчас? Получи сейчас?»
Таким образом, существует некий базовый, подразумеваемый уровень производительности и отклика. В конце концов, «в конце концов», исходящий почтовый ящик A соответствует входному почтовому ящику B.
Эти задержки, принятие устаревших данных, будь то дневная или 1-5 лет, являются тем, что контролирует окончательное соединение ваших систем. Чем меньше это требование, тем слабее муфта и больше гибкости, которую вы имеете в своем распоряжении с точки зрения дизайна.
Это верно для ядер вашего процессора.Современные, многоядерные, многопоточные приложения, работающие в одной и той же системе, могут иметь разные представления об «одних и тех же» данных, только устаревшие на микросекунды.Если ваш код может корректно работать с данными, которые могут быть несовместимы друг с другом, то счастливого дня это происходит.Если нет, вам нужно обратить особое внимание на то, чтобы обеспечить полную согласованность ваших данных, с использованием таких методов, как определение энергозависимой памяти или блокировка конструкций и т. Д. Все это, в свою очередь, приводит к снижению производительности.
Итак,базовое рассмотрение.Все остальные решения начинаются здесь.Ответив на это, вы узнаете, как распределить приложения между компьютерами, какие ресурсы используются совместно и как они используются совместно.Какие протоколы и методы доступны для перемещения данных и сколько это будет стоить с точки зрения обработки для выполнения передачи.Репликация, распределение нагрузки, совместное использование данных и т. Д. И т. Д. Все основано на этой концепции.
Редактировать в ответ на первый комментарий.
Правильно, точно.Игра здесь, например, если B не может изменить данные клиента, то в чем вред от изменения данных клиента?Можете ли вы «рискнуть» тем, что оно устарело на короткое время?Возможно, ваши данные о клиенте поступают достаточно медленно, чтобы вы могли немедленно скопировать их из А в Б.Предположим, что изменение помещено в очередь, которая из-за малого объема будет легко подхвачена (<1 с), но даже при этом исходное изменение будет «вне транзакции», и поэтому есть небольшое окно, в котором Aданные, которых нет у B. </p>
Теперь разум действительно начинает вращаться.Что происходит во время этой «задержки», какой сценарий наихудший из возможных.И вы можете спроектировать вокруг этого?Если вы можете сработать с задержкой в 1 с, вы можете сработать с задержкой в 5 с, 1 м или даже больше.Какую часть данных о клиентах вы фактически используете на B?Возможно B - система, разработанная, чтобы облегчить выбор заказа из инвентаря.Трудно представить что-то более необходимое, чем просто идентификатор клиента и, возможно, имя.Просто что-то, чтобы точно определить, для кого предназначен заказ, пока он собирается.
Система комплектования не обязательно должна распечатывать всю информацию о клиенте до самого конца процесса комплектования, и к тому времени заказ может перейти в другую систему, которая, возможно, более актуальна,особенно информация о доставке, поэтому в итоге система комплектации практически не нуждается в данных клиента.Фактически, вы можете врезать и денормализовать информацию о клиенте в заказе на комплектование, поэтому нет необходимости или ожидания синхронизации позже.Пока идентификатор клиента правильный (который никогда не изменится) и имя (которое меняется так редко, что обсуждать не стоит), это единственная реальная справка, которая вам нужна, и все ваши отборочные листы являются совершенно точными на моментсоздание.
Хитрость заключается в том, чтобы разбить системы и сосредоточиться на основных данных, необходимых для выполнения задачи.Данные, которые вам не нужны, не нуждаются в репликации или синхронизации.Люди недовольны такими вещами, как денормализация и сокращение данных, особенно когда они из мира моделирования реляционных данных.И на то есть веские основания, это следует рассматривать с осторожностью.Но как только вы разошлись, вы неявно денормализовали.Черт возьми, сейчас вы копируете это оптом.Таким образом, вы можете быть более умными в этом вопросе.
Все это можно смягчить с помощью четких процедур и глубокого понимания рабочего процесса.Определите риски и разработайте политику и процедуры для их устранения.
Но сложная часть - это разорвать цепь к центральной БД вначале, и дать людям понять, что они не могут «иметь все», как они.может ожидать, когда у вас есть один, центральный, идеальный склад информации.