Что такое декомпозиция данных
Декомпозиция. Как разобрать огромный проект на понятные сегменты для предварительной оценки
Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?
Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.
Уровни декомпозиции
Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!
1 уровень. Крупные блоки или компоненты
Это может быть блок с е-коммерсом, личный кабинет, мобильное приложение, супер-навороченная админка. В общем, любые блоки работ, которые могут быть как-то между собой связаны, но которые можно делать изолированно друг от друга.
2 уровень. Страницы сайта или экраны мобильного приложения
В случае с блоком «мобильное приложение», как на схеме выше, разбиваем его на экраны. Но как узнать, что вы учли все-все-все возможные экраны? Для проверки полноты берите в расчёт сценарии использования — это даст понимание, какие задачи юзеры будут решать в приложении (или на сайте) и каким примерно образом они это будут делать.
Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.
Есть соблазн написать в смете только сценарий использования и его оценку (скажем, сценарий покупки товара или сценарий заказа такси) — ну, ведь понятно же, что там внутри. Нет, непонятно, и есть большой риск потерять множество шагов, поскольку такие сценарии большие, и их крайне сложно адекватно оценить целиком.
Когда сценарий раскладывается на экраны, шансов ошибиться становится меньше. Но помните, что каждый сценарий стоит проверять на связанность — достаточно ли вам вот этих экранов, чтобы этот сценарий сбылся?
У нас есть маркетплейс — магазин, куда другие производители могут загружать свои товары. Сценарии, лежащие на поверхности: загрузка своих товаров (загрузка и описание, разделы каталога и вот это вот всё), покупка товара (шаги покупателя на пути к цели), обработка заказа (как будут распределяться деньги, как будет получать свою долю маркетплейс и так далее). Если всё это не расписать подробно, можно запросто упустить кучу нюансов.
Будет ещё легче, если вы выделите ключевые роли на проекте (пользователь, администратор интернет-магазина и т. д.), у каждой из которых есть свой сценарий, а у каждого сценария — свой набор экранов. И тогда проверить полноту экранов ещё проще — достаточно посмотреть, связан и выполняется ли сценарий конкретной роли по ним.
3 уровень. Содержание экранов
В общем случае у вас на экранах могут быть какие-то вкладки либо какие-то блоки — грубо, вложенные экраны. Например, страница корзины/оформления заказа — здесь всегда есть блок товаров со своим сценарием (добавить-убавить-очистить), а еще блоки доставки, оплаты, авторизации, бонусной системы и так далее. Бывают ситуации, когда эти блоки также разбивают на экраны по шагам. Зависит от решения, принятого по итогам аналитики — бывает, что удобнее их всё-таки «слить» воедино.
Задача менеджера, когда он добрался до такого экрана, — посмотреть, из чего тот состоит. Бывает, экран легко разбить на блоки, бывает — сложно. Яркий пример сложной разбивки — калькуляторы: по ним чаще всего неочевидно, что происходит и как процесс расчёта делить на шаги.
Когда вы добираетесь до третьего уровня, нужно быть супер-внимательными, потому что на странице могут появляться самые разные вещи. И важно понимать, откуда они там вообще берутся — от этого будут сильно зависеть ваши оценки.
Откуда эта хрень на странице?!
Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».
Например, аналитик сказал: «это мы как-нибудь на коде решим», а потом на планинге сидят 4 умных человека, смотрят друг на друга и спрашивают: «кто это придумал, что это за маразм?!». Такая ситуация — явный признак, что где-то недоработали раньше. Бывает, конечно, что принятие какого-то решения действительно откладывается, но это должно быть осознанно и где-то зафиксировано.
Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.
Итак, какими могут быть варианты, откуда берутся данные на странице?
Вариант 1. Хардкод
Самый простой в реализации вариант ответа на наш вопрос — хардкод. Это значит, что программисты сели, прямо в коде зафигачили какую-то штуку, и теперь поменять ее могут только они. Самые частые блоки, с которыми так делают — логотипы компаний, иногда ссылки на соцсети, время от времени такое делают с меню (всё реже), телефонами (плохо!), декоративными элементами на верстке. Всё это — более-менее разумные моменты. Неразумно, это когда в код зашиваются, например, ВСЕ страницы или SEO-тексты блоками.
Вариант 2. Включаемая область
У включаемых областей есть специфика: во-первых, их можно случайно удалить. Во-вторых, если в них указываются даты мероприятий или цены на товары, это чревато путаницей, поскольку у этих областей нет связанности: если поменять дату или цену в одном месте, в другом она останется той же. Клиенты зачастую сразу говорят, что такого им не нужно — а значит, придётся продумывать, как менять цены, даты и прочие изменяемые поля автоматически и повсеместно.
Вариант 3. Из админки (из базы данных)
Итак, мы знаем, что какие-то данные выбираются из базы данных. Тогда нам нужно понимать, из какой сущности и из какого поля. Примеры сущностей в интернет-магазине: «товар», «раздел», «пользователь», «заказ» — то есть то, что состоит из каких-то полей. Поля — например, «цена».
Но достаточно ли нам будет понимать, из какой сущности и из какого поля выводятся данные? Не совсем. Когда выбираете какую-то информацию из базы, она может выводиться не в том виде, как она там хранится, а в несколько модифицированном.
Например, это формула
Когда информация хранится в базе, но ее нужно как-то определенным образом модифицировать, появляется понятие «формула». Одна из самых опасных вещей, которую менеджеры часто пропускают.
Когда вам аналитик говорит «ну там это как-то считается» — навострите ушки, впереди точно будет затык. Математики не понимают программистов и считают что, их формулу достаточно переписать и следом «просто» запрограммировать — делов-то. Но когда клиента начинаешь спрашивать о формуле, часто слышишь что-то вроде «ой, она у нас там в excel», или «механика пока непонятна», или вообще «ну скопируйте вон с того сайта».
Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».
Вот из-за этого о формулах никто не любит думать:)
В зависимости от используемой технологии бывает, что часть данных хранится в файлах. Может показаться, что это какая-то сущность или поле сущности, но это всё-таки ФАЙЛ.
Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.
С файлами ещё бывает история, что их нужно хранить на отдельных серверах, или в облаках S3, закачивая по специальному протоколу, но это уже нюансы масштабирования. На старте проекта, окупаемость которого непонятна, городить тут огород я не вижу смысла. Исключение — тяжелый видео-контент. Его лучше сразу писать в видеохостинги.
— Владимир Завертайлов, CEO & Founder
Как данные попадают в базу данных?
Обычно администратор или контент-менеджер садится и забивает данные ручками. Тогда здесь должен возникать вопрос, а хватит ли ему стандартных компонентов админки для этого. Для этого ПМ должен быть очень хорошо знаком с возможностями стандартной административной панели. А ещё с ними должен быть знаком аналитик и тестировщик (про кодера, понятно, молчим). В Сибирикс все QA-специалисты проходят базовый курс контент-менеджера, чтобы понимать, на что способна админка. Ну, а про то, что QA-спецы у нас обычно вырастают в проджект-менеджеров, мы уже как-то писали.
У вас на дизайне есть слайдер, где расставлены точки, по клику на которые открывается всплывашка, в которой есть фотография, описание и ссылка на куда-нибудь. Вопрос: как расставлять эти точки? Как вариант — координаты X и Y, но вряд ли контентщик будет счастлив от такого функционала. А значит, придётся что-то придумывать. И значит, в смету нужно это заложить.
Второй момент, который проджекты часто упускают, — права доступа и хватит ли их. А значит, это тоже нужно иметь ввиду и сразу перечислить потенциальные роли.
Вариант 4. Интеграция со сторонним ресурсом
Один из источников данных в базе — пользовательский контент. И здесь важно понимать, как он попадает в базу. На этом этапе часто теряется один из крупных сценариев: например, как пользователь вносит отзывы. У отзывов часто бывает рейтинг — штука с виду простая, но внутри она может быть довольно сложно организована. У чего больше рейтинг? Там, где поставили одну оценку в 10 баллов, или где 1000 оценок, но разных? Среднеарифметическое тут работает плохо. Но хитрые алгоритмы есть — привет, ещё один резерв в смете.
Если данные берутся всё-таки с внешнего источника, то без интеграции никак. Вариантов интеграции может быть несколько:
Другая проблема — админы сайтов, с которым парсятся данные, не слишком счастливы, что эти данные кто-то «ворует», и будут всячески защищаться. А это приводит к «падению» парсинга и попаданию в черные списки. Вы попытаетесь с этим бороться добавлением каких-нибудь платных proxy — короче, целый квест. Есть особые сервисы для организации парсинга — например, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy или Content Grabber (полный список из 30 сервисов ищите тут).
Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:
Хуже всего бывает, когда говорят «ну вы, программисты, между собой договоритесь и разберитесь сами как-нибудь». Если протокол не формализован и взаимной ответственности нет, критический путь проекта будет пролегать через интеграцию, и на ней он завалится. Или по крайней мере, здесь потратится куча времени на согласование с программистом заказчика его протокола и отладку.
Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).
Как все это «подружить»
Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».
Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂
Когда это может не сработать
Если на проекте есть какая-то дремучая математика, и вы живете в мире, полном злых неожиданностей, то декомпозиция по экранам будет давать сбой. В общем случае она довольно хорошо показывает, что и как происходит на типовых проектах.
Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!
Разложение монолита: Декомпозиция БД (часть 1)
Эта статья является конспектом книги «От монолита к микросервисам». Материал статьи посвящен декомпозиции БД во время процесса разложения монолита на микросервисы.
В предыдущей статье рассмотрели способы извлечения функциональности из монолита в микрослужбы. Однако, что делать с данными? Микрослужбы работают лучше всего, когда они полностью инкапсулируют собственные механизмы хранения и извлечения данных.
Однако разложение БД — далеко не простая задача. Нам нужно учесть вопросы синхронизации данных во время перехода на микрослужбы, логической и физической декомпозиции схемы данных, транзакционной целостности, задержки и многое другое. Далее в этой статье будут рассмотрены эти вопросы.
Однако, прежде чем начнем разделять БД, мы должны рассмотреть трудности, связанные с управлением одной совместной БД.
Совместная БД
На первый взгляд, существует ряд проблем, связанных с совместным использованием одной БД многочисленными службами. Главенствующая проблема заключается в том, что мы отказываем себе в возможности решать, что является совместным, а что скрытым, что противоречит стремлению к сокрытию информации. Это означает, что будет трудно понять, какие части схемы можно изменять безопасным образом. Проблему можно смягчить с помощью представлений БД, но это частичное решение.
Еще одна трудность состоит в том, что становится неясным, кто «контролирует» данные. Где находится бизнес-логика, которая оперирует этими данными? Не «размазана» ли она теперь по всем службам? Из этого, в свою очередь, вытекает отсутствие связности бизнес-логики и затруднение обеспечения правильной реализации управления состоянием.
По мнению автора книги, прямое совместное использование БД подходит для микрослужб только в двух ситуациях. Первая — при рассмотрении статических справочных данных, допускающих только чтение. Здесь структура данных остается очень стабильной, и контроль за изменениями в них в типичной ситуации регулируется в рамках работы по администрированию. Второе место — там, где служба непосредственно выставляет базу данных наружу как определенную конечную точку, которая спланирована и управляется для обслуживания многочисленных потребителей.
Итак, в идеале, мы хотим, чтобы новые службы имели собственные независимые схемы. Но это не то место, где мы начинаем работу с существующей монолитной системой. Означает ли это, что всегда необходимо разбивать эти схемы? Это уместно делать в большинстве ситуаций, но не всегда целесообразно делать изначально. Иногда работа занимает слишком много времени или сопряжена с изменением особенно чувствительных частей системы. В таких случаях полезны различные подходы, которые, по крайней мере, остановят ухудшение ситуации, а в лучшем случае станут разумными шагами к чему-то более оптимальному в будущем.
Шаблон: «Представление БД»
В ситуации, когда нам нужен один источник данных для нескольких служб, представление способно смягчить трудности, касающиеся связности. Это представление ограничивает данные, видимые службе, скрывая информацию, к которой она не должна иметь доступа.
Автор книги участвовал в оказании помощи по переплатформированию существующей системы кредитных деривативов. В ходе работ по оптимизации они обнаружили, что многочисленные приложения вне их контроля имели доступ на чтение к БД, а в некоторых случаях доступ на чтение/запись. Они установили, что все эти внешние системы имели одинаковые имена пользователей и пароли, поэтому было невозможно понять, что это за пользователи и к чему они обращались. Однако вскоре они поняли, что большинство этих приложений не проходят активного технического сопровождения, т. е. не было никаких шансов, что они будут обновлены. По сути, схема БД была направлена в публичное пространство контрактом, который не подлежал изменению: им пришлось идти вперед, поддерживая эту структуру схемы.
Их решение состояло в том, чтобы сначала уладить те ситуации, когда внешние системы писали в их схему. Однако для всех тех клиентов, которые хотели данные читать, они создали выделенную схему, содержащую представления, которые выглядели как старая схема. В результате они смогли вносить изменения в собственную схему, при условии, что поддерживали указанные представления.
Способность представления брать только ограниченную информацию из опорного источника позволяет реализовать некую форму сокрытия информации. Однако это решение не идеально — в таком подходе существуют ограничения. Способы реализации представления отличаются, но в типичной ситуации они являются результатом запроса. Это означает, что само представление доступно только для чтения. Этот факт сразу же ограничивает их полезность. Существуют и другие ограничения, например, необходимость, чтобы исходная схема и представление находились на одном и том же ядре СУБД. Это увеличивает сопряженность физического развертывания, приводя к потенциальной единой точке сбоя.
В зависимости от природы БД может иметься вариант создавать материализованное представление. Такое представление предвычисляется — в типичной ситуации с использованием кэша. Это означает, что чтение из проекции не должно генерировать чтение на опорной схеме, что повышает производительность. Однако может случиться так, что вы будете читать из представления «устаревший» набор данных.
Рекомендуется использовать представление БД преимущественно в ситуациях, когда нецелесообразно осуществлять декомпозицию существующей монолитной схемы. В противном случае, нужно стараться, если это возможно, избегать необходимости представления.
Шаблон: «Служба обертывания БД»
Когда с чем-то слишком трудно справиться, имеет смысл скрыть беспорядок. С помощью шаблона «Служба обертывания базы данных» (database wrapping service) скрываем БД за службой, которая действует как тонкая «обертка», перенося зависимости БД, которые становятся зависимостями службы, как показано на рис. 3.
Указанный шаблон очень хорошо работает там, где слишком трудно разобрать на части опорную схему. Указанный шаблон имеет преимущества перед использованием простого представления БД. Можно написать код в своей службе обертывания, который будет предоставлять гораздо более изощренные представления на опорные данные. Служба обертывания также принимает операции записи (через вызовы API). Разумеется, внедрение этого шаблона требует от вышестоящих потребителей внесения изменений, им придется перейти от прямого доступа к БД к вызовам API. В идеале, применение этого шаблона будет отправной точкой для более фундаментальных изменений, давая время на то, чтобы разложить схему под слоем API.
Шаблон: «БД как служба»
Иногда клиентам нужна база данных только для запросов. Это бывает обусловлено тем, что им нужно запрашивать или извлекать большие объемы данных. Один из подходов состоит в создании выделенной БД, предназначенной для выставления наружу в качестве конечной точки с доступом только для чтения, и заполнении этой БД, когда данные в опорной БД изменяются. Он очень хорошо укладывается в варианты использования, связанные с отчетностью, — ситуации, когда клиентам требуется соединять большие объемы данных, хранящихся в той или иной службе.
До сих пор мы не решали проблему, которая лежит в основании. Мы просто накладывали самые разные «повязки» на большую совместную БД. Прежде чем начнем думать о работе по вытаскиванию данных из монолитной БД, нужно подумать о том, где затрагиваемые данные фактически располагаются. Когда выделяется службы из монолита, некоторые данные должны уходить вместе с ними, а некоторые из них должны оставаться там, где они есть. Если мы внедряем идею, в которой микрослужбы инкапсулируют логику, ассоциированную с одним или несколькими агрегатами, то нам также необходимо перенести управление их внутренним состоянием в собственную схему микрослужбы. С другой стороны, если новой микрослужбе требуется взаимодействовать с агрегатом, который по-прежнему находится во владении монолита, то мы должны выставить эту возможность наружу через четко определенный интерфейс. Далее будут описаны два варианта.
Шаблон: «Монолит с выставлением агрегата наружу»
На рис. 4 показано, что службе «Выписка счетов-фактур» нужно обращаться к разнообразной информации, которая не имеет прямого отношения к управлению выпиской счетов. В настоящее время все эти данные находятся в БД монолита. Выставляя информацию о «Сотрудниках» наружу через конечную точку службы (это может быть API или поток событий) на самом монолите, мы четко указываем, какая информация требуется службе «Счет-фактура».
Монолит по-прежнему «владеет» понятием того, что является и не является допустимым изменением состояния; мы не хотим трактовать это просто как «обертку» вокруг базы данных. Помимо просто выставления данных наружу, выставляются также операции, которые позволяют внешним сторонам запрашивать текущее состояние агрегата и запрашивать новые переходы из состояния в состояние. Мы по-прежнему можем решить ограничить то, какое состояние агрегата выставляется изнутри контура нашей службы наружу, и ограничить то, какие операции перехода из состояния в состояние могут запрашиваться снаружи.
В итоге, указанный шаблон хорошо работает, когда данные, к которым вы хотите обратиться, по-прежнему находятся «во владении» монолитной БД, предоставляя новым службам необходимый доступ. При извлечении служб необходимость в том, чтобы новая служба обращалась обратно в монолит для получения доступа к необходимым данным, скорее всего, будет оборачиваться немного большим объемом работы, чем прямой доступ к монолитной базе данных — но в долгосрочной перспективе эта идея гораздо лучше.
Шаблон: «Смена владельца данных»
Теперь же рассмотрим, что произойдет, когда рассматриваемые данные, находящиеся в текущий момент в монолите, должны быть под контролем только что извлеченной службы?
На рис. 5 описаны изменения, которые должны произойти. Нужно перенести счет-фактурные данные из монолита в новую «Счет-фактуру», поскольку как раз там находится контроль над жизненным циклом данных. Затем нужно изменить монолит так, чтобы трактовать службу «Счет-фактура» как источник истины для счет-фактурных данных, и изменить его таким образом, чтобы он вызывал конечную точку службы «Счет-фактура» для чтения данных или выполнения запроса на изменения.
Указанный шаблон выглядит более четко очерченным. Если только что извлеченная служба инкапсулирует бизнес-логику и указанная логика изменяет некие данные, то эти данные должны находиться под контролем новой службы. Данные должны быть перенесены оттуда, где они находятся сейчас, в новую службу.
Синхронизация данных
Как мы обсуждали в предыдущей статье, одна из выгод шаблона, подобного «Фикусу-удавке» состоит в том, что при переключении на новую службу мы затем можем переключиться обратно, если появляется затруднение. Проблема возникает, когда затрагиваемая служба управляет данными, которые должны поддерживаться в синхронизированном состоянии между монолитом и новой службой.
Какие же есть решения? Для начала, нам нужно подумать о степени, в которой данные должны быть согласованы. Если необходима полная согласованность данных между БД, то одним из наиболее простых подходов было бы обеспечить хранение данных в одном месте. Однако опасения по поводу использования совместной БД невозможно преувеличить: следует ее рассматривать только как очень краткосрочную меру. Если совместная БД слишком долго остается на своем месте, то это приведет к значительной головной боли в долгосрочной перспективе.
Если выполнять переключение методом «Большого взрыва» (что лучше избегать), мигрируя одновременно код приложения и данные, то можно использовать пакетный процесс для копирования данных перед переключением на новую микрослужбу. Однако, что произойдет, если нужно будет вернуться к использованию функциональности существующей монолитной системы? Данные, измененные в схеме микрослужб, не будут отражены в состоянии монолитной БД, поэтому мы в итоге потеряем внутреннее состояние.
Еще один подход — подумать о поддержании двух БД в синхронизированном состоянии. В этом случае операции записи в обе БД будет выполнять либо монолит, либо новая служба. Это решение требует тщательного обдумывания.
Синхронизация данных в приложение
Переключать данные с одного места на другое — мероприятие сложное, но оно тем больше чревато последствиями, чем более ценными являются данные
Далее будут описаны шаги синхронизации на примере проекта, в котором участвовал автор книги. Перед ними стояла задача перейти с MySQL на Riak в целях оптимизации производительности. Риски были большие, поэтому требовалось решение, которое позволило бы компании не только перенести данные в новую БД, но и построить механизмы, которые верифицировали бы миграцию, а также в рабочем порядке имели быстрые механизмы отката. Было принято решение, что приложение само будет выполнять синхронизацию между двумя источниками данных. Идея заключалась в том, что изначально существующая БД MySQL останется источником истины, но в течение определенного периода времени приложение будет обеспечивать синхронизацию данных в MySQL и Riak. Через некоторое время Riak станет источником истины для приложения, и только после этого MySQL будет выведена из эксплуатации.
Шаг 1 – массово синхронизировать данные. Это включает выполнение пакетной миграции данных из старой системы в новую базу данных Riak. Пока продолжался пакетный импорт, существующая система продолжала работать, поэтому источником данных для импорта был снимок данных, взятый из существующей системы MySQL. Это вызывает трудность в том плане, что после завершения пакетного импорта данные в исходной системе вполне могли измениться. После завершения пакетного импорта был реализован процесс захвата изменений в данных, с помощью которого были применены изменения, внесенные с момента начала импорта. Это позволило привести Riak в синхронизированное состояние.
Шаг 2 – синхронизация во время записи и чтение из старой схемы. Теперь, когда обе БД были синхронизированы, можно развернуть новую версию приложения, которая будет записывать все данные в обе БД (рис. 6). Цель на данном этапе — обеспечить, чтобы приложение правильно писало в оба источника. Тот факт, что все данные по-прежнему читались из MySQL, обеспечивал возможность извлечения данных из существующей БД MySQL даже в случае, если бы Riak «рухнула».
Шаг 3 – синхронизация во время записи и чтение из новой схемы. На этом этапе было определено, что чтение в Riak осуществляется нормально. Последний шаг — убедиться, что запись тоже работает. После чего Riak становится источником истины. Обратите внимание, что мы по-прежнему пишем в обе БД, поэтому при возникновении каких-либо затруднений есть возможность откатить назад. После того как новая система будет в достаточной мере отлажена, старую схему можно безопасно удалить.
В данном примере миграция происходила в рамках одного приложения. Но мы говорим о ситуациях, когда хотим извлечь микрослужбу. В таком случае поможет ли этот шаблон? Первым делом следует учесть то, что этот шаблон имеет большой смысл, если нужно разложить схему перед выделением кода приложения. При правильной реализации оба источника данных всегда должны находиться в синхронизованном состоянии, что дает значительные выгоды в ситуациях, когда требуется быстрое переключение между источниками для сценариев отката и т. д.
Для того чтобы этот шаблон работал как надо, необходимо, чтобы и монолит, и микрослужба обеспечивали надлежащую синхронизацию во всех БД. Если одно из них ошибется, то будут неприятности.
Физическое и логическое разделение БД
Когда мы говорим о разложении БД, мы в первую очередь пытаемся достичь логического разделения, или сегментации. Одно ядро СУБД способно идеально разместить более одной логически разделенной схемы, как показано на рис. 7.
Почему возникает желание разложить схемы логически, но все-таки иметь их на одном ядре СУБД? Дело в том, что в своей основе логическая и физическая декомпозиция преследуют разные цели. Логическая декомпозиция обеспечивает более простое независимое изменение и сокрытие информации, в то время как физическая декомпозиция потенциально повышает робастность системы и помогает устранять конкуренцию за ресурсы, позволяя повышать пропускную способность.
Когда разбиваем схемы БД логически, но сохраняем их на том же физическом ядре СУБД мы имеем потенциальную единственную точку сбоя. Если ядро СУБД выходит из строя, то затрагиваются обе службы. Однако многие ядра СУБД имеют механизмы, позволяющие избегать единственных точек сбоя.
На этом первая часть конспекта закончена. В следующей части разберем, что же выделить сначала: БД или код. А также затронем транзакции и саги в рамках микрослужб.