В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.kafka

1534 membersпожаловаться на группу
2019 December 02

A

Anatoly Soldatov in pro.kafka
Допустим, сервисов штук 1000 и все их надо подключить к кафке по щелчку (если они сами хотят делиться данными). У сервисов штук 10 разных баз данных (постгресы, монги, тарантулы, редисы и тд). Разные языки программирования
Разные команды
источник
14:56пожаловаться#1

A

Anatoly Soldatov in pro.kafka
В итоге видится что-то типа Netflix Keystone, но часть с простым подключением продюсеров пока непонятна
источник
14:57пожаловаться#2

AK

Alexander Kovalev in pro.kafka
Anatoly Soldatov
Привет! Подскажите, плиз, кто как решает задачу по сбору данных с сервисов и доставке их в хранилище?
Данные должны доходить до DWH со всеми переходами и изменениями
Интересует больше всего место, где сервисы свои данные в кафку записывают (как это сделать удобно для сервисов? Как это сделать для разных баз данных и технологий максимально похоже?)
код/коннекторы/debezium
источник
14:57пожаловаться#3

AK

Alexander Kovalev in pro.kafka
debezium показал себя не быстрым
коннекторы не гибкими ( для оракла выкидывали и писали руками)
источник
14:57пожаловаться#4

АБ

Алексей Быстрый in pro.kafka
Anatoly Soldatov
В итоге видится что-то типа Netflix Keystone, но часть с простым подключением продюсеров пока непонятна
Ну иначе никак
источник
14:58пожаловаться#5

A

Anatoly Soldatov in pro.kafka
Коннекторы в целом не подходят многие, тк они по умолчанию могут между первым и вторым забором изменений потерять изменение состояния
Debezium работает не со всем нашим стеком + делает сложнее failover
источник
14:59пожаловаться#6

AK

Alexander Kovalev in pro.kafka
Anatoly Soldatov
Коннекторы в целом не подходят многие, тк они по умолчанию могут между первым и вторым забором изменений потерять изменение состояния
Debezium работает не со всем нашим стеком + делает сложнее failover
ну это зависит от коннектора
коммитим в опенсурс если не устраивает, но основные коннекторы таким не страдают
источник
15:00пожаловаться#7

A

Anatoly Soldatov in pro.kafka
Новые это те, что основе WAl логов?
Или как ещё они могут гарантированно все стейты стримить?
источник
15:02пожаловаться#8

AK

Alexander Kovalev in pro.kafka
условно в топик (мы ж наверное про distributed mode говорим) скидывается текущая закомиченная метка, при рестарте вычитываем из топика метку и читаем с нее
так вполне работает для sql, без этго спокойно работает для mq, не вижу проблем сделать в любом коннекторе
источник
15:02пожаловаться#9

AK

Alexander Kovalev in pro.kafka
Anatoly Soldatov
Новые это те, что основе WAl логов?
Или как ещё они могут гарантированно все стейты стримить?
в дистрибютед моде все хранится в топиках кафки
источник
15:03пожаловаться#10

AK

Alexander Kovalev in pro.kafka
для sql к примеру это может быть timestamp последней записи
не помню, скидывает ли коннектор его в топик, но свежие/старые определять по таймстемпу в записи умеет
источник
15:04пожаловаться#11

A

Anatoly Soldatov in pro.kafka
Я не про этот кейс
Я про большое число быстрых изменений одной и той же записи, например в постгресе
JDBC коннекторы в таком случае часть изменений исторических просто потеряют
источник
15:05пожаловаться#12

AK

Alexander Kovalev in pro.kafka
Anatoly Soldatov
Я не про этот кейс
Я про большое число быстрых изменений одной и той же записи, например в постгресе
JDBC коннекторы в таком случае часть изменений исторических просто потеряют
timestamp
источник
15:06пожаловаться#13

A

Anatoly Soldatov in pro.kafka
Либо надо будет накладывать ограничения на Таблицы, чтобы они все верчионировались
Либо лог писать куда-то триггерами
Либо ещё как-то подклстылить
Либо валы использовать
источник
15:06пожаловаться#14

AK

Alexander Kovalev in pro.kafka
умеют смотреть, вычерпывают, проблем не было
источник
15:06пожаловаться#15

A

Anatoly Soldatov in pro.kafka
Как они вычерпают запись, которая уже сверху перетерта другим апдейтом по тому же ключу ?
источник
15:07пожаловаться#16

AK

Alexander Kovalev in pro.kafka
добавляете timestamp полем, вычерпываете всю запись, перезатираете
источник
15:07пожаловаться#17

AK

Alexander Kovalev in pro.kafka
добавить можно триггером, если до сих пор нет
источник
15:08пожаловаться#18

AK

Alexander Kovalev in pro.kafka
валом - можно, но для конкретных баз свои решения
источник
15:08пожаловаться#19

A

Anatoly Soldatov in pro.kafka
Так коннекторы не синхронизируются с бизнес логикой сервисов
источник
15:08пожаловаться#20