Мы туда идем. Сделали транзакционное чтение из топиков и запись в таблицы (сценарий процессинга данных из топиков), сейчас пишем код по транзакционной записи в топики (сценарий стриминга изменений наружу).
А у вас в каком сценарии нужно писать и в таблицу и в топик в одной транзакции?
Мы очень стараемся, чтобы снаружи для приложений оно именно так и выглядело - полная совместимость.
Отличий на самом деле два вида: внутренние (стоимость, скорость, георезервирование), которые существуют, независимо от протокола, и отличия проявляющиеся при использовании YDB sdk или просто экосистемы YDB.
С точки зрения внутренних отличий мы гораздо компактнее храним данные: у нас используется erasure-кодирование против репликации Kafka/Pulsar. В итоге разница в объемах хранения 1:2 в пользу YDB. Кроме этого, мы умеем в настоящее георезервирование на N датацетров, а не просто в дублирование в соседнем кластере. То есть мы полноценно живет в геораспределенных инсталляциях, включая кроссдц exactly once обработку данных.
С точки зрения экосистемы мы двигаемся в сторону транзакционной передачи данных между топиками и таблицами. Сейчас мы умеем транзакционно читать из таблиц и писать в очередь, теперь учимся делать наоборот. Цель - exactly onсe при обработке данных между топиками и таблицами. Кроме этого, сейчас мы делаем split-merge партиций, этого нет в Kafka, но это позволяет динамически изменять число партиций (выполнять scaling) с сохранением всех гарантий exacly once.
Если говорить объективно, то Clickhouse разрабатывается Clickhouse Inc, а не Яндексом.
Clickhouse — отличная БД, но не подходит для задач DWH. Она не любит Joinы и у нее нет Cost Based Optimizer, а нам это было важно
Тут, наверное, вопрос, что такое «своя СУБД» и «какими СУБД Яндекс пользуется». Своя СУБД - одна, это YDB, пользуемся разными, в зависимости от задачи
Да, все так. Плюс технически не во все сервера возможна установка 6 NVME, а хочется работать плюс-минус на commodity серверах
Мы туда идем. Сделали транзакционное чтение из топиков и запись в таблицы (сценарий процессинга данных из топиков), сейчас пишем код по транзакционной записи в топики (сценарий стриминга изменений наружу).
А у вас в каком сценарии нужно писать и в таблицу и в топик в одной транзакции?
Мы очень стараемся, чтобы снаружи для приложений оно именно так и выглядело - полная совместимость.
Отличий на самом деле два вида: внутренние (стоимость, скорость, георезервирование), которые существуют, независимо от протокола, и отличия проявляющиеся при использовании YDB sdk или просто экосистемы YDB.
С точки зрения внутренних отличий мы гораздо компактнее храним данные: у нас используется erasure-кодирование против репликации Kafka/Pulsar. В итоге разница в объемах хранения 1:2 в пользу YDB. Кроме этого, мы умеем в настоящее георезервирование на N датацетров, а не просто в дублирование в соседнем кластере. То есть мы полноценно живет в геораспределенных инсталляциях, включая кроссдц exactly once обработку данных.
С точки зрения экосистемы мы двигаемся в сторону транзакционной передачи данных между топиками и таблицами. Сейчас мы умеем транзакционно читать из таблиц и писать в очередь, теперь учимся делать наоборот. Цель - exactly onсe при обработке данных между топиками и таблицами.
Кроме этого, сейчас мы делаем split-merge партиций, этого нет в Kafka, но это позволяет динамически изменять число партиций (выполнять scaling) с сохранением всех гарантий exacly once.