Why?

Реляционная база данных по-прежнему служит основной базой данных. data план магазина Relational Databases have been around for a long time and have become a trusted storage medium for all of a company’s data. Традиционные решения ETL и OLAP для хранилищ данных Data is pulled off this primary data store, transformed, and then stored in a secondary data store, such as a data warehouse. The industry typically uses ETL to run nightly jobs to give executives a view of the previous day’s, week’s, month’s, year’s business performance.

OLTP (Online Transaction Processing) vs. OLAP (Online Analytic Processing) : This differentiates between their uses — OLTP for primary data serving, OLAP for analytic processing of a modified copy of the primary data.

BUT, В последнее время большое количество практических в реальном времени data needs At LinkedIn, it also feeds real-time search indexes, real-time network graph indexes, cache coherency, Database Read Replicas, etc… These are examples of LinkedIn’s near-real-time data needs.

Для таких нужд ETL и OLAP не могут удовлетворить требования реального времени. Мы обсуждаем, Как получить данные от Primay data Проблема перемещения магазина в другое место практически в реальном времени?

How?

Linkedin Databus может продлевать события изменений до уровня микросекунд. Каждый сервер может обрабатывать тысячи событий изменения пропускной способности данных в секунду. Он также поддерживает неограниченные возможности обратного отслеживания и богатые функции подписки на изменения.

Как получить изменения?

Существует два распространенных способа выполнения этого требования:

Двунаправленная запись драйвера приложения：В этом режиме,Прикладной уровень также обеспечивает данные и другая система обмена сообщениями инициируют операцию записи. Эта реализация кажется простой, поскольку можно контролировать направление к базе. Код приложения, написанный данными. Однако это приведет к проблемам согласованности, поскольку не существует сложного протокола координации (например, протокола двухфазной фиксации или алгоритма paxos), поэтому в случае возникновения проблем трудно гарантировать, что база данные и система обмена сообщениями находятся в одинаковом заблокированном состоянии. Обе системы должны выполнить одну и ту же операцию записи.,И завершите сериализацию в том же порядке. Если операция записи является условной или имеет семантику частичного обновления,Дальше все становится сложнее.

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

Если требования не очень строгие, допустимо использовать первый способ. После успешного сохранения БД напишите систему pub-sub.

Как доставить изменения за микросекунды?

Реле, реле

Реле — это буфер памяти, который по-прежнему является стратегией пространства-времени. Если скорость достаточно высока, должно быть достаточно реле и достаточно близко к клиенту, потому что скорость, с которой клиент получает данные от реле. Буфер памяти не может быть оптимизирован. Как организовать релейную кластеризацию, существует два следующих метода:

A Databus Relay will pull the recently committed transactions from the source Database (e.g. Oracle, MySQL, etc…) (Step 1). The Relay will deserialize this data into a compact form (Avro etc…) and store the result in a circular in-memory buffer.

Clients (subscribers) listening for events will pull recent online changes as they appear in the Relay (Step 2).

A Bootstrap component is also listening to on-line changes as they appear in the Relay.(Step 3)

первый, Для обеспечения эффективности данные изменений необходимо преобразовать в более эффективный формат (например, Avro). и положить его по кругу in-memory buffer Затем, Клиент (абоненты) слушает и читает из памяти Relay Поместите данные обновления в буфер, Режим Push не может быть использован, Потому что эффективность разных анализов может сильно отличаться. В реле, Данные помещаются в память в буфере, память ограничена, Поэтому используйте круговой метод Проблема в том, Требования каждого клиента разные. У вас нет возможности узнать, когда данные действительно недействительны, Значит, должен быть способ сохранить исторические данные, Это Бутстрап

Есть две ситуации, когда пользователи будут использовать Bootstrap:

1. Медленный клиент, необходимые данные перезаписаны в реле, поэтому их нужно получать из Bootstrap

2. New client, Необходимо получить все исторические данные, Почему Bootstrap получил свое название

Databus’ Bootstrap

One of the most innovative features of Databus is its Bootstrap component. Data Change Capture systems have existed for a long time (e.g. Oracle Streams). However, all of these systems put load on the primary data store when a consumer falls behind.

Bootstrapping a brand new consumer is another problem. It typically involves a very manual process — i.e. restore the previous night’s snapshot on a temporary Oracle instance, transform the data and transfer it to the consumer, then apply changes since the snapshot, etc…

Databus’s Bootstrap component handles both of the above use-cases in a seamless, automated fashion.

Самая инновационная особенность Databus — это Bootstrap. Потому что, хотя данные Change Захват существовал всегда, Но, как и первая версия Databus, Более серьезная проблема заключается в Реле может буферизовать только самые последние данные, Для старых данных Ретранслятор будет действовать как прокси от основного data Магазин извлекает данные напрямую, Затем вернитесь к клиенту Так что для медленного client, Это значительно увеличит первичную data нагрузка на магазин.

В то же время для новых client, Если вам нужно получить все данные, это очень хлопотно, very manual process Bootstrap может полностью решить все вышеперечисленные проблемы. Это действительно инновационно

How Does Databus’ Bootstrap Component Work?

Bootstrap постоянно считывает обновления в журнале. внутреннее хранилище, Затем импортируйте снимки в пакетном режиме. На складе Эта конструкция создана из соображений эффективности. Для моментального снимка вы можете использовать Raw Реализация файлов, И войти хранилище необходимо постоянно обновлять, Вам нужно использовать что-то вроде БД, чтобы получить реализацию.

The Databus Bootstrap component is made up of 2 types of storage, Log Storage serves Consolidated Deltas Snapshot Storage serves Consistent Snapshots

1. As shown earlier, the Bootstrap component listens for online changes as they occur in the Relay. A LogWriter appends these changes to Log Storage. 2. A Log Applier applies recent operations in Log Storage to Snapshot Storage 3. If a new subscriber connects to Databus, the subscriber will bootstrap from the Bootstrap Server running inside the Bootstrap component 4. The client will first get a Consistent Snapshot from Snapshot Storage 5. The client will then get outstanding Consolidated Deltas from Log Storage 6. Once the client has caught up to within the Relay’s in-memory buffer window, the client will switch to reading from the Relay

В чем отличие от Кафки?

Where as DataBus is used for Database change capture and replication, Kafka is used for application-level data streams

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

Github

https://github.com/linkedin/databus

LinkedIn: Creating a Low Latency Change Data Capture System with Databus

http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html

Databus: LinkedIn’s Change Data Capture Pipeline SOCC 2012

http://www.slideshare.net/ShirshankaDas/databus-socc-2012

LinkedIn Data Infrastructure (QCon London 2012)

http://www.slideshare.net/r39132/linkedin-data-infrastructure-qcon-london-2012

Перепечатано по адресу: https://www.cnblogs.com/fxjwind/archive/2013/03/05/2944864.html.

Заявление об авторских правах: Содержание этой статьи добровольно предоставлено пользователями Интернета, а мнения, выраженные в этой статье, представляют собой только точку зрения автора. Этот сайт предоставляет только услуги по хранению информации, не имеет никаких прав собственности и не принимает на себя соответствующие юридические обязательства. Если вы обнаружите на этом сайте какое-либо подозрительное нарушение авторских прав/незаконный контент, отправьте электронное письмо, чтобы сообщить. После проверки этот сайт будет немедленно удален.

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/183621.html Исходная ссылка: https://javaforall.cn