Вступление
Прежде всего, я хотел бы заявить, что я не являюсь экспертом Oracle DB. Я просто обычный разработчик с полным стеком, который разбирается в мире БД и может заставить все работать. Я участвовал в нескольких проектах, в которых использовалась Oracle DB, и я могу честно сказать, что каждый из них мог бы выжить на любом другом движке базы данных с открытым исходным кодом. Каждый раз его использование было неоправданным, а заявления типа “он был там всегда” и “от него трудно отойти” просто подчеркивали невозможность замены.
Тем не менее, я должен был использовать его, и большую часть времени это было больше похоже на драку. Вещи, которые были необходимы в любом другом движке, были кошмаром для настройки ( самые простые ). Если было включено что-то полезное, вам приходилось доплачивать за это (например, за отсутствие секционирования в стандартной версии). В любом случае, Oracle DB по-прежнему является синонимом “решения для корпоративных баз данных”, так что команда маркетинга Oracle хорошо выполняет свою работу!
Модель обмена сообщениями, ориентированная на базу данных
(Упрощенная версия) приложения, которое было преобразовано в Kafka, может быть описано с помощью модели производитель/потребитель.
Проще говоря: есть 1 .. n производителей и 1 потребитель. Производители записывают данные в таблицы базы данных, которые имеют триггеры ON UPDATE для отправки информации в Oracle Pipe ( DBMS_PIPE package). Затем клиент считывает информацию из канала и обрабатывает ее.
Каналы Oracle – это низкоуровневый механизм для обмена данными между двумя (или более) сеансами в аналогичных сценариях, описанных выше. Они работают так же, как каналы UNIX, со всеми их ограничениями, и на самом деле довольно быстры. У этого решения есть одна очень важная проблема – оно не масштабируется. Представьте, что будет 1 .. gazillion производителей, вы, вероятно, можете добавить немного дополнительной мощности и оперативной памяти, но у вас все еще есть одно узкое место для обслуживания – база данных.
Введите Кафку
Apache Kafka не нуждается в представлении, поскольку он уже занял прочное место в мире решений с высокой нагрузкой и высокой доступностью. Это потоковая платформа, которая позволяет создавать масштабируемые распределенные приложения без особых усилий. Если у вас нет опыта работы с Kafka, в этом посте есть все, что вам нужно знать, чтобы понять его .
Кафка каким-то образом естественным образом вписывается в наш вариант использования. Там уже есть производители и потребители, так что мы могли бы просто взять их, соединить все это вместе с помощью Kafka и пропустить часть DB! В простом мире, да, это было бы так. Но наше приложение имеет важную бизнес-логику, связанную с вычислениями и обменом сообщениями, хранящимися в базе данных, помните?
Пока мы не окажемся в идеальном мире, где база данных – это просто хранилище, у Kafka есть инструмент, который может помочь нам перейти к чистому решению Kafka для производителей и потребителей.
Соединитель источника Kafka JDBC
Используя kafka-connect API , мы можем создать (исходный) соединитель для базы данных, который считывал бы изменения в таблицах, которые ранее обрабатывались в триггерах базы данных и процедурах PL/SQL. Затем эти изменения будут отправлены промежуточному компоненту, который выполнит само вычисление.
Вы можете использовать либо решение на основе JDBC, либо решение на основе журналов, но поскольку последнее будет стоить дороже (лицензии на такие инструменты, как Oracle GoldenGate или XStream), мы будем использовать решение на основе JDBC. Настройка JDBC source connector относительно проста, вот хорошая статья, в которой это кратко описано . Если вы не хотите читать эту статью, вот что она делает:
- Опрашивает конкретную таблицу (либо на основе запроса, либо просто по имени таблицы)
- Когда вносится изменение, его представление в формате JSON отправляется в Kafka
Есть определенные предостережения и ограничения, которые я перечислю для дальнейшего использования:
вы можете указать режим, в котором будут проверяться обновления. Я использовал
timestamp, который использует сравнение значений столбцов временных меток. Чтобы настроить это, столбец метки времени должен быть:- присутствует в таблице (да)
- not null (возможность обнуления может быть включена, но какой в этом смысл?)
- обновляется при каждом изменении либо в приложении, либо в триггере базы данных (поскольку Oracle изначально не поддерживает
ПРИ ОБНОВЛЕНИИ МЕТКИ ВРЕМЕНИ) - использование правильного часового пояса (который можно настроить в настройках соединителя)
- JDBC connector будет использовать опрос, поэтому тайм-аут опроса должен быть точно настроен таким образом, чтобы он не затоплял базу данных. Кроме того, запрос, используемый для извлечения данных, должен выполняться быстро.
- Триггеры базы данных имеют возможность сравнивать старую и новую дату (например, до и после обновления). Это было бы невозможно с помощью JDBC connector, поэтому вам нужно иметь это в виду.
- Вероятно, вам также потребуется отформатировать результат в запросе, например
number(*)(неограниченный числовой тип) будет преобразован в байтовый массив. Это можно легко решить, присвоив ему определенное значение, напримерnumber(12).
Что действительно замечательно в этом решении, так это то, насколько легко оно масштабируется. Модуль processing logic может быть развернут несколько раз в пределах одной и той же группы Kafka, что означает, что нагрузка будет распределена между потребителями ” способом Kafka “. Это практически сняло бы нагрузку с базы данных и позволило бы нам увеличить объем обрабатывающей части.
Реализация логики обработки может быть выполнена с использованием kafka-streams или API производителя/потребителя Kafka, в зависимости от характера преобразований. Я не раскрыл слишком много подробностей, что было сделано специально, так что, если у вас есть еще вопросы, не стесняйтесь оставлять комментарии и обращаться ко мне!
Оригинал: “https://dev.to/rapasoft/migrating-from-oracle-db-pipe-messaging-to-kafka-1ee3”