Синхронизация данных MySQL с ES, по сути, является формой денормализации данных. В этом разделе мы расширяем технические решения «Миграции и синхронизации данных MySQL в ES» и предлагаем читателям некоторые идеи, сравнивая их преимущества и недостатки и сценарии применения.
нормализация базы данныхЭто относится к стратегии уменьшения избыточности и повышения согласованности данных с помощью ряда парадигм базы данных в реляционных базах данных.
Но зачем денормировать?
Хотя нормализация приносит нам видимые преимущества (способствует повышению производительности транзакций и снижению затрат на хранение), наряду с расширением масштаба данных, параллелизма и сложности, постепенно выявляются ее недостатки.
на этот раз черезденормализация базы данныхДля решения этих проблем в определенной степени общая идея состоит в том, чтобы повысить производительность чтения базы данных с помощью ряда операций, которые снижают производительность записи, таких как большая избыточность данных и группировка данных.
Существуют различные мотивы для денормализации данных.Триггерными факторами являются случаи, когда сложные операции с данными влияют на стабильность системы, не выполняются требования бизнес-ответа/параллелизма и т. д.
проблемы со стабильностью бизнеса: Интернет-приложения, ориентированные на C-сторону, характеризуются большим количеством параллелизма, а SQL смещен в сторону перечисления и записи, что относительно просто, но накопленные данные необходимо оперировать и часто включает рабочие характеристики традиционных корпоративных- приложения уровня в базах данных. Операции в реальном времени, такие как крупномасштабное удаление данных, связывание таблиц и сортировка, а также более сложные требования к базе данных, такие как отчетность/BI. Прохождение денормализации и разделения нагрузки является разумным выбором.
Проблемы с производительностью сложных запросов: Приложения корпоративного уровня часто включают такие операции, как ассоциация таблиц, агрегирование, многомерная фильтрация, сортировка и т. д., и часто вызывают проблемы с производительностью. Благодаря некоторым способам денормализации, таким как избыточность данных и предварительные вычисления, упомянутые ниже, производительность значительно повышается.
Обработка на уровне столбцов Избыточные поля основной таблицы запросов
За счет избыточного вычисления данных в основной таблице можно избежать частого пересчета данных. Следующие сценарии подходят для избыточных данных в основной таблице данных:
- Прикладная система должна часто получать расчетные данные
- Избыточные необработанные данные изменяются нечасто
преимущество: Метод прост и легок в реализации
недостаток: вторгаясь в бизнес-логику и замедляя производительность бизнес-кода, изменения, созданные в результате длительной итерации, могут иметь риски для стабильности.
Обработка на уровне таблицы Предварительная сборка широкой таблицы / Предварительная сборка куба
Основной операцией является построение широкой таблицы, либо построение куба данных (Data Cube). Созданная широкая таблица содержит всю информацию об измерениях и показателях, которую пользователь должен запросить.
Общая обработка на уровне таблицы включает: Многократная запись приложения, материализованное представление, реализованное самой базой данных, и синхронизация переноса данных.
Применить несколько записей
Создайте широкую таблицу в той же базе данных, что и основные данные.Когда приложение записывает данные, оно также хочет записывать данные в широкую таблицу (транзакция гарантирует согласованность), и из этой таблицы можно выполнять сложные запросы.
преимущество: Простая и недорогая реализация
недостаток: Повышенная нагрузка на основную базу данных при чтении и записи плюс затраты на трансформацию бизнеса.
Материализованные представления РСУБД
Материализованное представление (моментальный снимок) — это доступный только для чтения объект базы данных, который содержит результаты запроса, является локальной копией удаленных данных или используется для создания сводной таблицы на основе суммы таблиц данных. Сократите количество объединений и агрегаций за счет избыточности данных и предварительных вычислений, тем самым повысив производительность запросов.
преимущество: Сам движок базы данных поддерживает, стоимость использования низкая
недостаток: способ реализации РСУБД имеет свои ограничения.Например, данные для создания материализованного представления требуют некоторых бизнес-преобразований, которые не могут быть выполнены, или некоторые базы данных не полностью реализуют эту возможность.
синхронизация переноса данных
С помощью средств синхронизации данных организация данных и преобразование основной таблицы данных (в том числе преобразование по бизнес-логике) может формироваться в обычные таблицы или таблицы большой ширины в квазиреальном времени, а также записываться в сторонние накопительный двигатель. Сложные запросы выполняются непосредственно к предварительно созданным таблицам или кубам для достижения хорошей производительности. Существует много вариантов инструментов переноса данных, и в целом по своей направленности их можно разделить на следующие категории:
Большие данные, потоковые вычисления, сообщения, базы данных, поставщик облачных услуг, профессиональные инструменты миграции и синхронизации данных
преимущество:
Основная база данных более стабильна: асинхронное разделение запросов транзакций бизнес-системы и сложных запросов предотвращает влияние сложных запросов на основную базу данных.
Простота эксплуатации и обслуживания, стабильная связь: связь синхронизации переноса данных поддерживается стандартизированными продуктами и отделена от основной бизнес-системы и чтения и записи основной базы данных. Общая структура имеет четкие обязанности, простоту обслуживания и отслеживания проблем.
недостаток: необходимо выбрать различные инструменты миграции и синхронизации данных и продукты баз данных, которые выполняют сложные запросы.
Представьте техническое решение «Синхронизация миграции данных MySQL в ES» здесь.
Почему стоит выбрать Mysql?
Высокая возможность параллелизма: функции ядра MySQL особенно подходят для высококонкурентных и простых операций SQL, связь является легковесной (поточный режим), а оптимизатор, исполнитель и механизм транзакций относительно просты.
хорошая стабильность: Самым большим требованием к основной базе данных является стабильность и отсутствие потери данных. Активная и резервная системы MySQL быстро переключаются в случае сбоя, а механизм хранения innodb также обеспечивает стабильность сервера MySQL.
Простота в эксплуатации: хороший и удобный пользовательский интерфейс, простота использования и низкая стоимость обучения.
Экология с открытым исходным кодом: MySQL является открытым исходным кодом, что позволяет производителям вышестоящих и нижестоящих компаний относительно легко создавать инструменты на ее основе.Прокси высокой доступности, подбазы данных и промежуточное программное обеспечение подтаблиц значительно повышают его практичность, а характеристики открытого исходного кода позволяют ему иметь большой Количество пользователей.
Почему ЭС?
Несколько примечательных особенностей ES могут эффективно компенсировать недостатки MySQL в сценариях операций с данными корпоративного уровня.
возможность текстового поиска: ES — это поисковая система, основанная на инвертированном индексе, с различными токенизаторами, она лучше работает при поиске с нечетким сопоставлением текста и имеет широкий спектр бизнес-сценариев.
Хорошая производительность многомерной фильтрации: Предварительное построение данных в масштабе 100 миллионов с использованием широких таблиц (устранение объединений) в сочетании с полной индексацией полей делает ES уникальным преимуществом в возможностях многомерной фильтрации, а также в возможностях текстового поиска.
Открытый исходный код и коммерческий бок о бок: Экосистема с открытым исходным кодом ES очень активна, с большим количеством групп пользователей, а также поддерживается независимыми коммерческими компаниями, что позволяет пользователям иметь более разнообразный и прогрессивный выбор в соответствии с их собственными особенностями.
Почему метод синхронизации переноса данных?
хорошая стабильность: операция синхронизации миграции в основной базе данных в основном заключается в последовательном чтении данных и журналов, и в то же время параллелизм невелик, и влияние на стабильность основной базы данных невелико (может иметь большее количество нижестоящих подписок). воздействие на сетевом уровне, которое обычно решается с помощью сообщений). Кроме того, журнал (Binlog/WAL/Redo и т. д.) можно воспроизвести, что значительно снижает вероятность потери данных в нисходящем направлении (если идемпотент хорошо обрабатывается).
разделение бизнеса: Вообще говоря, основная база данных выполняет больше транзакционных операций, в то время как нижестоящая система данных выполняет операции и другие услуги.
Меньше вмешательства в бизнес: Миграция и синхронизация данных ненавязчивы для бизнеса, а стандартная база данных (источник) подключена к обоим концам, что позволяет легко находить зрелые решения или продукты в различных направлениях, таких как open source, коммерческие и облачные.
Хорошая деловая пригодность: некоторые продукты для переноса и синхронизации данных могут включать бизнес-логику, чтобы обеспечить нисходящий доступ к данным, который ближе к бизнесу, что делает службы данных более эффективными и удобными.
Выбор модели синхронизации миграции данных
Потребление подписки
преимущество:
Возможность стекирования: из-за введения очередей сообщений вся ссылка имеет возможность стекирования для изменения данных. Предполагая, что потребление измененных данных относительно медленное, когда старые файлы binlog в MySQL удаляются из-за нехватки места на диске, данные в очереди сообщений все еще существуют, и синхронизация данных все еще может быть выполнена.
Возможности распространения данных: после введения очередей сообщений можно поддерживать многосторонние подписки. Если несколько нижестоящих приложений используют данные об изменениях на стороне источника, вы можете подписаться на одну и ту же тему.
Возможности обработки данных: поскольку измененные данные подписываются нижестоящими потребителями, некоторая обработка данных может выполняться гибко после подписки. Например, интерфейс микросервиса удобнее вызывать извне или реверсировать некоторые данные для обработки данных.
недостаток:
Стоимость эксплуатации и обслуживания относительно высока: он содержит множество компонентов и приложений, а гарантия эксплуатации и обслуживания относительно сложна.
Высокий риск стабильности: проблема в одном канале повлияет на стабильность всего канала синхронизации данных. И будет сложнее устранить неполадки и локализовать проблему.
прямой сквозной
преимущество:
Низкая задержка: прямая сквозная синхронизация с короткими ссылками и низкой задержкой.
Хорошая стабильность: компонентов канала немного, вероятность сбоя низкая, а позиционирование и устранение неполадок относительно просты. Он подходит для тяжелых сценариев с высокой точностью данных.
Сильная масштабируемость функций: напишите систему сообщений на противоположном конце, смоделируйте режим подписки и получите сильную масштабируемость.
Контрольная точка развертывания при эксплуатации и обслуживании: меньше компонентов связи, более простое развертывание, эксплуатация и обслуживание
Сводка по выбору модели синхронизации переноса данных
Если подписок на нисходящие данные не так много, рекомендуется использоватьПрямой режим. Ссылки для синхронизации данных часто размещаются в онлайн-сервисах, но с ростом масштабов и важности сервисов стабильность канала становится все более важной.
Кроме тогосквозной режимПоскольку одноранговым источником данных является промежуточное программное обеспечение сообщений, режим подписки может быть реализован немедленно, а возможность обработки данных может быть решена путем загрузки бизнес-кода для запуска в некоторых продуктах миграции и синхронизации данных.
Хотя архитектура данных отвечает потребностям бизнеса,лаконично и ясноЭто может упростить обслуживание и устранение неполадок в системе.Когда канал синхронизирует большой объем данных каждый день, иногда теряет некоторые данные и требует проверки, или канал синхронизации зависает и не синхронизируется, сквозной метод часто показывает значительные преимущества.
Отношение соединения таблиц в реляционной базе данных может быть выражено несколькими типами данных в ES, включая объектные, вложенные и объединенные.
objected
Тип объекта может хранить вложенные структуры.
преимущество: Представляет отношение «один ко многим» между основным полем и внутренним полем объекта и поддерживает запрос соединения doc. Поскольку все связанные данные, от которых зависит запрос, также находятся в одном документе, объединение внутри ES исключается, а эффективность запроса высока.
недостаток: связь «один ко многим» может сохранять только один слой, несколько слоев будут сведены, а связь внутри вложенного поля будет потеряна.
nested
Вложенный тип может хранить вложенные структуры, представляющие отношение «один ко многим», и является расширением типа объекта.
преимущество:
Недостаток объекта не появится, все отношения вложенности полностью сохраняются, а внутренние отношения ассоциации поддокументов полностью сохраняются.
Связанные данные естественным образом связаны с основным документом посредством реализации, а производительность при поиске выше (по сравнению с объединением).
недостаток:
Вложенное поле может принадлежать только одному основному документу.
Во вложенном типе существует сильная привязка между вложенным документом и основным документом, и вложенный документ принудительно обновляется при обновлении основного документа. В сценарии больше писать и меньше читать новая стоимость энергии относительно велика.
Запрос дочернего документа должен пройти через родительский документ, а затем найти дочерний документ.
Частая модификация вложенных документов повлияет на другие вложенные документы и родительские документы, поскольку, по сути, реализация lucene представляет собой избыточный архив в родительском документе.
join
Тип объединения позволяет настраивать документы "родитель-потомок" и реализовывать возможности "один ко многим" через документы "родитель-потомок". Можно построить только один индекс. Этот тип более гибкий, чем вложенный тип. Родительский и дочерний документы связаны parentId, фактически они являются независимыми документами.
преимущество:
Обновление вложенного документа не влияет на родительский документ и другие вложенные документы.
Поддокумент можно искать индивидуально
Когда документ является вложенным документом, он может выбирать, к какому родительскому документу он принадлежит. Различные столбцы соединения могут быть указаны через отношение
недостаток:
Необходимо создать глобальный порядковый номер для обслуживания отношений между родительскими и дочерними документами, что повлияет на производительность поиска.
объединение и сравнение вложенных типов
join подходит для сценариев с большим количеством операций записи и меньшим количеством операций чтения, а также для сценариев, в которых важна производительность индекса. Это означает, что обновления вступают в силу быстрее, но накладные расходы на поиск относительно велики.
Вложенный подходит для сценариев с большим количеством чтения и меньшим количеством записи и уделяет больше внимания производительности поиска.
Далее будет представлено несколько способов денормализации синхронизации данных:
Избыточные данные первичной таблицы
С точки зрения бизнеса некоторые реляционные данные, необходимые для запроса, заранее избыточно сохраняются в поле исходной таблицы.
преимущество: режим обработки может иметь дело с различными ассоциациями «один ко многим», имеет низкие функциональные требования к средствам синхронизации данных и прост в настройке, требуется только поддержка одиночной синхронизации с ES.
недостаток:
Производительность индексирования и поиска не оптимальна: ES не снабжен встроенными широкими табличными данными. Эта реализация будет иметь дополнительные накладные расходы с точки зрения производительности индексации и поиска и не является самой эффективной реализацией.
Вторжение в бизнес-систему: когда бизнес-система записывает основные данные, необходимо записать дополнительную информацию.
Слишком большая избыточность данных в основной таблице базы данных. В таблице реляционной базы данных содержится слишком много избыточной информации из других таблиц, что может привести к снижению производительности и объема памяти.
Суммировать:Этот метод не рекомендуется
Подписка на несколько таблиц и предварительная сборка данных широкой таблицы
Инструмент синхронизации данных подписывается одновременно на все таблицы, на которые опирается поиск, данные, которые приходят первыми, сначала попадают в ES, а поля, в которых нет данных, пустые.
преимущество:
Задача синхронизации конфигурации инструмента синхронизации данных относительно проста, нет вмешательства в бизнес, и логика бизнес-системы не связана.
Требования к средствам синхронизации данных низкие, и никаких дополнительных функций, кроме синхронизации, не требуется.
Способ, основанный на предварительно созданной широкой таблице, также имеет лучшую производительность индексов и запросов на ES.
Канал синхронизации не блокирует синхронизацию всего канала данных из-за отсутствия данных в некоторых столбцах широкой таблицы.
недостаток: Широкая таблица строится упреждающим образом на основе таблицы фактов. Для таблицы, на которую подписан источник, если бинарный журнал редко обновляется или никогда не обновляется, значения столбцов в равноправном документе всегда могут быть неполными, что приводит к плохой своевременности. Некоторые столбцы данных отсутствуют при поиске.
Суммировать:
Он подходит для сценария, в котором данные таблицы фактов, составляющие широкую таблицу, записываются с гарантиями транзакций для размещения на диске вместе, чтобы предотвратить поиск неполных данных одноранговым ES.
Он подходит для сценариев, в которых построение широкой таблицы не требует бизнес-обработки.Построение широкой таблицы осуществляется только путем объединения столбцов нескольких таблиц вместе для формирования широкой таблицы.
Проверка процесса синхронизации перед сборкой
Таблица, на которую подписывается средство синхронизации данных, называется основной таблицей. В процессе синхронизации данных таблица, к которой запрашивается база данных, называется подчиненной таблицей. Используя возможности самого инструмента синхронизации данных, при подписке на основную таблицу столбцы в широкой таблице автоматически заполняются путем обратной проверки для формирования полных данных строки широкой таблицы.
преимущество:
Построение широкой таблицы на основе метода обратного просмотра обладает хорошей гибкостью и может выполнять некоторую легкую обработку данных подчиненной таблицы на основе данных основной таблицы перед созданием широкой таблицы.
Данные основной таблицы могут быть сгенерированы обратной проверкой для создания широких строк таблицы, которая может быть объединена с обработкой данных для создания нескольких данных широких строк таблицы.
На основе метода обратного поиска относительно легко реализовать соединения между экземплярами, тем самым генерируя широкие строки таблицы.
Предварительно построенный метод, основанный на широкой таблице, имеет лучшую производительность индекса и запросов в ES.
недостаток:
Данные могут быть не готовы во время обратной проверки, в результате чего данные
Инструменты синхронизации данных необходимы для поддержки контраста данных и обработки данных.
Суммировать:
Подходит для сценариев, в которых создание широких таблиц требует обработки данных.
Разница между материализованным представлением и обычным представлением