Руководство по cdc

Автор оригинала: Vlad Mihalcea.

Вступление

В этой статье я собираюсь объяснить, что такое CDC (Сбор данных об изменениях) и почему вы должны использовать его для извлечения изменений на уровне строк базы данных.

В системах OLTP (Онлайн-обработка транзакций) доступ к данным и их изменение осуществляются одновременно несколькими транзакциями, и база данных переходит из одного согласованного состояния в другое. Система OLTP всегда показывает последнее состояние наших данных, что облегчает разработку интерфейсных приложений, для которых требуются гарантии согласованности данных почти в реальном времени.

Однако система OLTP не является островом, являясь лишь небольшой частью более крупной системы, которая инкапсулирует все потребности в преобразовании данных, требуемые данным предприятием. При интеграции системы OLTP с кэшем, хранилищем данных или Сеткой данных в памяти нам необходим процесс ETL для сбора списка событий, которые изменили данные системы OLTP за определенный период времени.

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

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

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

Триггеры базы данных

Каждая СУБД поддерживает триггеры, хотя и с несколько иным синтаксисом и возможностями.

PostgreSQL предлагает специальную страницу для реализации журнала аудита на основе триггеров .

Триггеры на уровне приложений

Существуют фреймворки, такие как Hibernate Envers , которые эмулируют триггеры базы данных на уровне приложения. Преимущество заключается в том, что вам не нужно обращать внимание на синтаксис триггеров, специфичный для базы данных, поскольку события в любом случае фиксируются контекстом сохранения. Недостатком является то, что вы не можете регистрировать события изменения данных, которые не проходят через приложение (например, изменения, поступающие из консоли базы данных или из других систем, использующих одну и ту же СУБД).

CDC на основе журнала транзакций (Сбор данных об изменениях)

Хотя триггеры на уровне базы данных или приложений являются очень распространенным выбором для CDC, есть лучший способ. Журнал аудита-это просто дубликат журнала транзакций базы данных (он же журнал повтора или журнал предварительной записи), в котором уже хранятся изменения на основе строк.

Таким образом, на самом деле вам не нужно создавать новую структуру журнала аудита с использованием триггеров базы данных или уровня приложения, вам просто нужно просмотреть журнал транзакций и извлечь из него события CDC.

Исторически сложилось так, что каждая СУБД использовала свой собственный способ декодирования базового журнала транзакций:

• Предложения Oracle Золотые ворота
• SQL Server предлагает встроенную поддержку CDC
• MySQL, так широко используемый для веб-приложений, позволяет вам фиксировать события CDC с помощью различных сторонних решений, таких как База данных LinkedIn

Но в городе появился новый парень! Debezium -это новый проект с открытым исходным кодом, разработанный Red Hat, который предлагает соединители для Oracle, MySQL, PostgreSQL и даже MongoDB.

Мало того, что вы можете извлекать события CDC , но вы можете распространять их в Apache Kafka , который служит основой для всех сообщений, необходимых для обмена между различными модулями крупной корпоративной системы.

Вывод

Если вы используете приложение OLTP, CDC пригодится, когда дело доходит до интеграции с другими модулями в текущей корпоративной системе. Некоторые могут возразить, что использование источника событий лучше и даже может полностью заменить системы OLTP, поскольку вы регистрируете каждое событие заранее и затем получаете последний снимок.

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

В противном случае Google, который стал пионером MapReduce для BigData с помощью своего хранилища данных Bigtable , не вложил бы столько усилий в создание глобально распределенной системы баз данных , совместимой с ACID, такой как Spanner , которая была разработана для создания критически важных приложений для обработки онлайн-транзакций (OLTP).

Привет, Хабр! На связи СберТех — мы создаём Platform V, цифровую платформу Сбера для разработки бизнес-приложений.

В платформу входит более 60 продуктов на базе собственных сборок open source, доработанных до уровня enterprise по функциональности, безопасности, производительности и отказоустойчивости.

В этой статье расскажем про реализацию паттерна Change Data Capture и межкластерной репликации данных в продукте Platform V DataGrid, распределённой in-memory базе данных для высокопроизводительных вычислений. А также об особенностях внедрения функции и вариантах репликации. Написать материал помог наш коллега Николай Ижиков из команды по развитию баз данных на стеке open source.

Что такое Change Data Capture

Представим, что у вас есть база данных с критичными для бизнеса данными и жёсткими SLA по чтению и записи. 

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

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

И тут на помощь приходит паттерн Change Data Capture или CDC.

Когда в базу данных вносятся изменения, для ускорения записи и оптимизации операций она пишет журнал изменений (UNDO, REDO логи). В него база данных последовательно записывает дельту, которую вы изменяете.

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

В результате получаем линейные, упорядоченные по времени события изменений данных: что было, что есть, какая операция, над какой таблицей или кэшем была выполнена. Обработка асинхронная, не триггер и не хранимая процедура. Данные закоммитились, приложение, которое их отправляет, продолжило работать дальше, а потребитель через какое-то время получает уведомление о произошедшем изменении.

Как и когда использовать CDC

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

• Постобработка событий. В системе произошло событие — пользователь зарегистрировался, создал заказ, загрузил новый файл, — и, согласно бизнес-процессу, по новой записи нужно инициировать модерацию или другие действия.

• Аналитика. По поступающим в CDC событиям можно считать аналитику в режиме, близком к реальному времени.

• Логическая репликация. В CDC у нас на руках есть ВСЕ изменения, которые происходят в базе. Для реализации репликации нужно всего лишь надёжно исполнить их на реплике.

CDC в open source database

Дизайн

При любой доработке сложной системы, к которой, очевидно, относится распределённая СУБД, всегда есть риск что-то сломать. Лучший выход — делать новую фичу, вообще не трогая существующие.

Поэтому, проектируя CDC на базе Ignite, команда решила, что ignite-cdc должен выступать как отдельный java-процесс, не влияющий на ноду Ignite.

Ignite в persistence-режиме, как и любая классическая СУБД, записывает изменения в WAL (Write-Ahead Log). WAL — бинарный файл, содержащий изменения, дельты, которые мы периодически пишем в основную память (page memory).

Время от времени WAL-сегмент переходит в архив. Ignite-cdc видит, что появился архивный WAL-сегмент, и обрабатывает его.

Обработка — уведомление потребителя об изменениях. Есть public API для потребителя, но можно написать и свой. 

Важно, что при этом нет перерасхода места на диске: WAL-архив — это существующая функциональность, которая нужна для восстановления после сбоев. Ignite-cdc обрабатывает ровно те же сегменты, никаких новых данных на диске не появляется.

Следующий важный момент — возможность сохранять состояние чтения. Ignite-cdc — отдельный процесс, который может падать. Нужно реализовать возможность фиксации состояния потребителя каждый раз, когда он решил, что данные обработаны и можно сохраниться. При падении обработка будет продолжена с места последнего commit-а. К счастью, поддерживать это довольно просто: нужно всего лишь сохранять указатель на том месте в сегменте, на котором чтение остановилось.

Из возможности сохранять состояние следует возможность сделать fail-fast-приложение. При любых проблемах Ignite-cdc падает. Предполагается, что поднимать его будут с помощью ОС-механизмов.

На уровне ноды всё выглядит вот так:

Есть небольшая тонкость: WAL-архив не бесконечный, Ignite складывает в архив столько сегментов, сколько было указано в настройках. При архивации n+1 сегмента самый старый удаляется.

Чтобы избежать ситуаций, когда CDC затормозил и не обработал уже удалённый сегмент, архивный сегмент hard-link’ом переносится в папку, с которой работает только Ignite-cdc.

Если удалим данные из архива, файл останется в папке для СDC, и данные будут доступны.

Если Ignite-cdc обработал сегмент, его можно будет сразу же удалить. Данные исчезнут с диска, когда оба hard-link’а будут удалены.

Приложению понадобятся метрики. API уже есть в Ignite, и его нужно переиспользовать.

API и настройки

Для настройки CDC есть три параметра, которые нужно настроить на уровне ноды.

public class DataStorageConfiguration {
    long walForceArchiveTimeout;
    String cdcWalPath;
}

public class DataRegionConfiguration implements Serializable {
    boolean cdcEnabled;
}

Здесь:

• cdcWalPath — путь к папке, где складываются WAL-сегменты для CDC;

• cdcEnabled — включает CDC для DataRegion’а;

• walForceArchiveTimeout — таймаут принудительной архивации сегмента: даже если сегмент заполнен не полностью, по таймауту он будет архивирован и станет доступным для CDC.

С walForceArchiveTimeout есть тонкость. WAL-архив работает быстро за счёт того, что он является memory-mapped file. Это позволяет фактически писать не на диск, а в память для того, чтобы операционная система сбросила файл или мы могли сделать это вручную, когда сегмент будет заполнен.

Запись на диск — дорогая операция, в момент которой производительность ноды снижается, поэтому, с одной стороны, запись нужно делать как можно реже. С другой — CDC узнаёт об изменениях после архивации сегмента, поэтому запись нужно делать как можно чаще. Противоречие

Решить его можно, выбирая таймаут согласно требованиям приложения.

Теперь самое интересное — сonsumer, слушатель, который позволяет узнать и обработать изменения:

public interface CdcConsumer {
   public void start(MetricRegistry mreg);
   public boolean onEvents(Iterator<CdcEvent> events);
   public void onTypes(Iterator<BinaryType> types);
   public void onMappings(Iterator<TypeMapping> mappings);
   public void stop();
}

• start, stop — для инициализации и остановки;

• onEvents — callback для обработки изменений: вернули true — состояние коммитнулось;

• onTypes, onMappings — callback’и для обработки изменений метаинформации о типах.  

Что доступно в событии:

public interface CdcEvent extends Serializable {
   public Object key();
   @Nullable public Object value();
   public boolean primary();
   public int partition();
   public CacheEntryVersion version();
   public int cacheId();
}

• key, value — данные: value может быть null, если событие по remove’у;

• primary — событие произошло на primary или backup;

• partition — номер партиции, необходим для распределения нагрузки в соответствии с существующими в Ignite партициями;

• version — версия entry;

• cacheId — идентификатор кэша.

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

Логическая репликация с помощью CDC

Под физической репликацией в данной статье я понимаю перенос между экземплярами БД внутреннего представления данных: страниц памяти и т. д.

Под логической — выделение потока изменений из базы-источника и его воспроизведение в базе-приёмнике.

CDC позволяет реализовать именно логическую репликацию.

В Ignite есть поддержка двух схем: Ignite to Ignite и Ignite to Kafka.

Ignite to Ignite

Внутри Ignite-cdc работает IgniteToIgniteCdcStreamer, кстати, доступный из коробки. Это consumer, который внутри себя поднимает клиентскую ноду Ignite, коннектится к кластеру-приёмнику и, получая изменения, отправляет почти обычную операцию put в кластер-приёмник.

Если кластер-источник недоступен, например из-за упавшей ноды, Ignite-cdc будет вечно ждать, пока нода не запустится. Новые данные не поступят, и процесс обработает те, которые были сгенерированы ещё живой нодой.

Если упал Ignite-cdc, то, во-первых, на всех остальных нодах он будет жив. Во-вторых, через некоторое время операционная система его перезапустит, CDC посмотрит, какие изменения он обработал, и продолжит отправлять их в соседний кластер.

Если потерялся соседний кластер или сетевая связность, Ignite-cdc также упадёт, а после перезапуска снова пойдёт в кластер-приёмник. Если кластер недоступен — падение. Если доступен — отлично, CDC начнёт отправлять в него изменения, которые были накоплены в WAL на диске. Диск является буфером изменений, которые будут копиться до тех пор, пока не получится их обработать и отправить в нужную точку.

Ignite to Kafka

Это вариант репликации для ситуаций, когда кластеры Ignite не видят друг друга, нужно использовать Kafka в качестве транспорта, или если есть несколько читателей событий.

Схема практически такая же: для обработки событий используется стример IgniteToKafkaCdcStreamer. Он раскладывает данные по партициям Kafka в соответствии с партициями Ignite.

На стороне приёмника есть приложение kafka-to-ignite — оно читает данные из Kafka и кладёт их в принимающий кластер Ignite.

Conflict resolver

Подошли к самому интересному: что произойдёт, если один ключ будет изменён на обоих кластерах?

Ответ — сработает conflict resolver. Это интерфейс, который определяет, какие именно данные должны попасть в кластер. Он может взять «старое», «новое» значение или выполнить merge.

СDC-extension предоставляет дефолтную имплементацию, но можно реализовать и свою. При этом стоит отметить, что правильного решения при конфликтах изменений не существует. Не зная ничего о данных, невозможно точно определить, какое изменение правильное, а какое нет.

Ключевые свойства дефолтной имплементации:

1. Если изменение произошло на «локальном» кластере, оно выигрывает.

2. Изменения с одного и того же кластера сравниваются по версии. Изменение с большей версией выигрывает.

3. Если указано поле для сравнения, записи сравниваются по нему.

4. Если всё предыдущее не сработало, новая запись отбрасывается. Данные разъезжаются, в логах warning, а вам нужно думать, что делать дальше.

Заключение

Внедрение паттерна CDC позволило добавить востребованную функциональность для реализации событийных подписок и создания реплик без влияния на производительность ядра самой базы данных.

Лучше поберечься, чем потом жалеть

Так что же нужно делать перед зомби… или ураганы или пандемии, например, на самом деле случаются? Прежде всего, у вас должен быть аварийный комплект в вашем доме. Это включает в себя такие вещи, как вода, еда и другие принадлежности, которые помогут вам пережить первые пару дней, прежде чем вы сможете найти лагерь беженцев без зомби (или, в случае стихийного бедствия,он даст вам некоторое время, пока вы не сможете добраться до эвакуационного убежища или не будут восстановлены инженерные линии). Ниже приведены несколько предметов, которые вы должны включить в свой комплект, для полного списка посетите страницу CDC Emergency.

• Вода (1 галлон на человека в день)
• Еда (запаситесь несобирательными продуктами, которые вы едите регулярно)
• Лекарства (включая рецептурные и безрецептурные лекарства)
• Инструменты и расходные материалы (нож, клейкая лента, радио с батарейным питанием и т. Д.)
• Санитария и гигиена (бытовой отбеливатель, мыло, полотенца и т.д.)
• Одежда и постельные принадлежности (смена одежды для каждого члена семьи и одеяла)
• Важные документы (копии водительских прав, паспорта и свидетельства о рождении, чтобы назвать несколько)
• Предметы первой помощи (хотя вы гонер, если зомби укусит вас, вы можете использовать эти принадлежности для лечения основных порезов и рваных ран, которые вы можете получить во время торнадо или урагана.)

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

1. Определите типы чрезвычайных ситуаций, которые возможны в вашем районе. Помимо зомби-апокалипсиса, это может включать наводнения, торнадо или землетрясения. Если вы не уверены, свяжитесь с местным отделением Красного Креста для получения дополнительной информации.
2. Выберите место встречи для вашей семьи, чтобы перегруппироваться на случай, если зомби вторгнутся в ваш дом… или ваш город эвакуируется из-за урагана. Выберите одно место прямо за пределами вашего дома для внезапных чрезвычайных ситуаций и одно место за пределами вашего района на случай, если вы не сможете сразу вернуться домой.
3. Определите свои контакты в чрезвычайных ситуациях. Составьте список местных контактов, таких как полиция, пожарная служба и ваша местная команда реагирования на зомби. Также определите контакт за его штата, которому вы можете позвонить во время чрезвычайной ситуации, чтобы остальные члены вашей семьи знали, что с вами все в порядке.
4. Спланируйте маршрут эвакуации. Когда зомби голодны, они не останавливаются, пока не получат еду (то есть мозги), а это значит, что вам нужно быстро уехать из города! Планируйте, куда вы пойдете, и несколько маршрутов, которые вы бы выбрали заранее, чтобы у плотоядных не было шансов! Это также полезно, когда происходят стихийные бедствия, и вы должны быстро укрыться.

Никогда не бойтесь – CDC всегда готов

Если бы зомби начали бродить по улицам, CDC провел бы расследование, как и любая другая вспышка болезни. CDC будет оказывать техническую помощь городам, штатам или международным партнерам, занимающимся заражением зомби. Эта помощь может включать консультации, лабораторные испытания и анализ, ведение пациентов и уход за ним, отслеживание контактов и инфекционный контроль (включая изоляцию и карантин). Вполне вероятно, что исследование этого сценария будет направлено на достижение нескольких целей: определить причину болезни, источник инфекции / вируса / токсина, узнать, как она передается и насколько легко она распространяется, как разорвать цикл передачи и, таким образом, предотвратить дальнейшие случаи, и как лучше всего лечить пациентов. Мало того, что ученые будут работать над выявлением причины и излечения вспышки зомби, но CDC и другие федеральные агентства будут отправлять медицинские бригады и спасателей, чтобы помочь тем, кто находится в пострадавших районах (я буду добровольно вызывать молодых безымянного детектива по болезням для полевых работ).

Чтобы узнать больше о том, что CDC делает для подготовки и реагирования на чрезвычайные ситуации всех видов, посетите: http://emergency.cdc.gov/cdc/orgs_progs.asp

Чтобы узнать больше о том, как вы можете подготовиться и оставаться в безопасности во время экстренного визита: http://emergency.cdc.gov/

Присоединяйтесь к целевой группе CDC по зомби!

CDC Foundation, некоммерческий партнер CDC, предлагает футболки Zombie Task Force (нажмите на картинку, чтобы узнать больше). Вырученные средства идут на помощь в ликвидации последствий стихийных бедствий и других важных программ в области здравоохранения. Получите свои, прежде чем они уйдут…

Вы готовы? Расскажите нам…

Вы начали готовиться к зомби-апокалипсису?

Или, может быть, вы готовились к более реалистичной угрозе, такой как ураганы или следующий сезон гриппа? Расскажите нам о том, что вы делаете, чтобы подготовиться! Участвуйте в нашем видеоконкурсе здесь: http://prepare.challenge.gov»

PS. По своему складу характера, я бы скорее расценил вышеуказанное как серьёзную форму шизофрении, но сопоставление фактов и критический анализ происходящего заставляет рассматривать любые версии. Тем более я уверен, что нынешняя пандемия КОВИД и кампания так называемой «вакцинации», организована тяжело больными на голову сектантами, но очень влиятельными. А от таких высокопоставленных придурков можно ожидать воплощение любого, даже самого тяжелого шизофренического бреда.

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

Ниже пара скринов с пользовательского соглашения сайта «Амазон»:

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

Цель

Представляется временное руководство по вакцинации различных групп населения 23-валентной пневмококковой полисахаридной вакциной (PPSV23) для предотвращения пневмококковой инфекции во время вспышки нового гриппа типа  A(H1N1).

История вопроса

Одним из осложнений гриппа у людей является бактериальная пневмония. Во время эпидемий гриппа в 20 веке вторичная бактериальная пневмония, этиологическим фактором которой, в основном, былStreptococcuspneumoniae (пневмококк), являлась одной из основных причин, вызывающей ухудшение состояния больного вплоть до смертельного исхода. Ранее также сообщалось о тяжелой пневмококковой пневмонии, ассоциированной с пандемическим гриппом, при этом  S. Pneumoniaeпродолжает оставаться ведущей причиной вакцинно-предотвращаемой болезни и летальных исходов в США. В настоящее время вспышка нового гриппа типа А(H1N1) стремительно развивается, и CDC продолжает представлять основную информацию относительно рисков заболевания гриппом, тяжести болезни и уровня поражения вторичной бактериальной пневмонии среди пациентов, больных гриппом. Вместе с тем, в настоящее время не определена роль пневмококковых инфекций среди тяжелых случаев заболевания новым гриппом типа А(H1N1), требующих госпитализации.

Пневмококковые вакцины

Во время вспышек гриппа пневмококковые вакцины могут быть эффективны в плане предотвращения вторичных пневмококковых инфекций и снижения уровня заболеваемости и смертности. В настоящее время имеются две вакцины для борьбы с пневмококковой болезнью – 23-валентная пневмококковая полисахаридная вакцина (PPSV23) и 7-валентная конъюгированная пневмококковая вакцина (PCV7).

Рекомендация по использованию вакцины PPSV23 во время вспышки гриппа типа A(H1N1)

Консультативный комитет CDC по вопросам иммунизации (ACIP) рекомендует одноразовую дозу вакцины PPSV23 для всех лиц от 65 лет и старше, а также для лиц от 2 до 64 лет, относящихся к группам высокого риска развития осложнений (см. Таблицу). Люди из этих групп подвержены повышенному риску пневмококковой пневмонии, как осложнения гриппа. Одноразовая вакцинация по меньшей мере через 5 лет после первоначальной вакцинации рекомендована для лиц от 65 лет и старше, которым первичная вакцинация проводилась до наступления 65-летнего возраста, а также она рекомендована людям, подверженным повышенному риску развития осложнений, например, лицам с отсутствием селезенки, являющимся носителями ВИЧ, болеющими СПИД или злокачественными заболеваниями.

Всем, кому показана вакцинация PPSV23, необходимо продолжать курс вакцинации согласно рекомендациям Консультативного комитета CDC по вопросам методов иммунизации (ACIP) при вспышке нового гриппа типа А(H1N1). Упор необходимо сделать на проходящих вакцинацию контингента младше 65 лет с установленными болезнями высокого риска, так как, исходя из имеющихся данных, среди людей этой группы, очевидно, больше всего встречаются тяжелые случаи заболевания, вызванного инфекцией нового гриппа типа А(H1N1).

В настоящее время не рекомендуется применять вакцину PPSV23 для людей, не имеющих показаний к вакцинации. Эта рекомендация может быть пересмотрена по мере более тщательного изучения эпидемиологии и клинической картины инфекции, вызываемой новым вирусом гриппа А(H1N1), частоты и тяжести вторичных пневмококковых инфекций.

Конъюгированные пневмококковые вакцины

Вакцина PCV7 рекомендована всем детям младше 5 лет, при этом привитой контингент среди детей в возрасте от 19 до 35 месяцев с 3 или более дозами вакцины PCV7 в настоящий момент составляет более 90%. Поддержание привитого контингента на таком высоком уровне позволяет не использовать вакцину PCV7 для детей старше 5 лет.