Ануар Нурмаканов - Event Sourcing и CQRS на конкретном примере
Vložit
- čas přidán 10. 07. 2018
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Что такое Event Sourcing и зачем нам CQRS? Все слышали об этих двух парадигмах - теперь пора разобраться конкретнее, как реализовать их. В докладе будет и мотивировано решение обратиться к Event Sourcing, и разобран небольшой конкретный пример, в котором это всё работает с PostgreSQL и ElasticSearch. - Věda a technologie
Объяснил доступнейшим языком, спасибо!
Отличный доклад. Просмотрел на одном дыхании.
Первый доклад по этой теме, после которого до меня прям много чего наконец-то дошло! Спасибо, Ануар )
Ты просто красавчик! Спасибо огромное ! 😘😘😘😘
Отличный доклад и докладчик! Спасибо!
Thanks, очень хороший доклад.
класс доклад, спасибо )) интересно и позитивно ))
Блин, на самом интересном закончилось
Докладчик просто бомба, разжевал очень хорошо.
Отличный доклад!!! Про Бугаенко хорошо было)))
24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.
Ануар, молодец, очень хорошо смотришься на сцене. Правильный слог, интонация и боди language
Автор упомянул перед вводом про CQRS и ES такую тему как DDD, с отсылкой как-будто это альма-матер...
а потом показывает, как через сеттеры шатает агрегат в СОБЫТИЯХ :):):):)
Отсюда видимо и начались проблемы с многопоточностью :)
Интересный вариант с кафкой, но я не совсем понял как будут решаться следующие проблемы если использовать кафку как event store:
1) Например мы добавили новую таблицу Materialized view, которая будет основана на уже существующих сообщениях и начинаем ее формировать и через кафку, нам придется прогнать миллиарды сообщения и обработать их, если например данные формировались несколько лет, возможно это вопрос к подходу, а не к кафке))
2) Например, у нас есть сообщения в кафке, но они же не вечно там хранятся, ну например, если электричество отключат и так далее и упадут контейнеры, и с образом что-то случится, как нам восстанавливать данные? Ведь, как я понял, на жестком диске они хранятся в таком варианте, что их нельзя будет прочитать, ну или это считается плохим подходом.. Получается их нужно будет резервировать каждый раз в каком-то другом формате а потом как-то считывать
3) Порядок сообщений, ведь в кафку сообщения могут падать в беспорядочном виде, а нам нужен будет например другой порядок, наверное это как-то решается на уровне приложений.. Но все таки? Например, в обычных бд можно сортировать хотябы по id или по другому полю потом считывать в порядке.
4) Как я понял нельзя считывать данные с определенного id, а например у нас уже есть materialized view до определенного id и нам нужно его обновить. В любом случае хотелось бы понять best practice для kafka. потому как многие рекомендуют его как event store
Хороший доклад. Почему не сделать трансляцию из дискусионного зала? Уверен, там тоже полезная информация была.
В общем виде разделение записи и чтения в рамках реляционных субд решает репликация БД. Может не стоит трудиться со сложным Юнитом по синхронизации из видео. Проще применить репликацию.
"Мессадж броукер" - этим все сказано
Я фронтендер. Не могу отлелаться от мысли, что докладчик просто описывает redux с таймтревелом в немного видоизмененных терминах.
в Амазоне нету Кафки, а чем Кинезис не подходит ?
Спасибо за интересное видео, но Киев пишется как Kyiv
доклад огонь. но про производительность mv такое себе.
С удовольствием посмотрел картинки и меме. Жаль голос на их фоне постоянно отвлекает.
А если серьёзно - отличный доклад, огромное спасибо за работу. Но назвите меня скучным и занудой, но моё личное скромное имхо - количество смешнявок перечёркивает весь труд.
Я так понял Kafka streams уже решает всю ту магию с базами и ентитями. Агрегация и прочая дич
Везде пример конференции... Может сам кто то что то придумаеет?
Афтар отжог нипадецки
Очень интересных доклад, спасибо докладчику! Взял для себя очень много пищи для размышлений.
В конце была интересная дискуссия, жаль что перебили.
Помоему нет. Автор объясняет, что два клиента могут считать одинаковое состояние агрегата и затем по разному изменить это одинаковое состояние. Без версионирования получится, что один клиент затрет изменения другого, так как изменения от последнего клиента должны учитывать изменения от предыдущего. Базовые вещи и вообще не про ES + CQRS. Слушатель этого не понимает и просто говорит рандомный набор слов.
@@xfg9183 jygjygyg
То что тут названо "обработчик" на 27:45 - в общепринятой терминологии называтся "Projector", а "материализованное представление" - "Projection"
Vidal i "обработчик" nazvonim "denormalizer"
Я конечно понимаю что докладчик старался, но эти шуточки больно слушать...
И зачем вводить в заблуждение о том что такое CQRS? Это всего лишь разделение команд от запросов, при этом можно писать/читать в одну и ту же базу, в одни и те же таблицы. То что можно выделить для запросов отдельные представления (даже отдельные базы построенные на другой парадигме) для увеличения производительности - это уже деталь, это не необходимое условие CQRS. И еще вагон других вопросов по откровенно базовым понятиям...
Это бич нашей сферы.
Из-за того что нет единого реестра (словаря), что такое %любое название%, возникают такие ситуации. Есть только книги отдельных людей, статьи, и они так же не консистентны в своих показаниях. Так же многие технические термины используются вообще без определений, просто по наитию.
Но и даже если был бы реестр, это не решило полностью проблемы, потому что "машина - это средство передвижения с 4 колесами", но при этом, если скрутить 4 колеса, то все равно это машина. А в какой момент это не становится машиной, если начать отламывать по одной детали? Грань тонка.
Журить докладчика по этому поводу не надо, если смысл передан без искажений, то дальнейший спор о терминологии просто не нужен.
@@snowy0110 Бич это скорее массовый наплыв некомпитентных. Таким не то что на конференциях выступать нельзя, даже более менее средний проект доверить нельзя.
Alex B что кроме ваших ощущений заставляет вас думать таким образом?
@@snowy0110 тем не менее человек задает справедливые вопросы. Со временем данные в событиях могут изменяться или даже сами события могут перестать существовать. Как при этом собирать актуальное состояние агрегата? Поддерживать текущую версию события и все предыдущие? Что делать если событие более не существует? Игнорировать такое событие при сборке агрегата? Как модифицировать read часть, чтобы она соответствовала этим изменениям?
Эти вопросы интересуют гораздо больше, чем пересказ любой статьи о том, что такое event sourcing и cqrs. Я не встречал адекватных решений, хотя сама архитектура довольно интересная.
@@xfg9183 "Сами события могут перестать существовать" - это как? Кто-то создал запись, а потом изобрели машину времени и тебя с базой перекинули в прошлое, до создания записи?
Ne znaju... ja skorei bi ispolzoval protocol buffers v mesto JSON dlja hronenie i obmena mezhdu servisami. Legche parsitj i menshe mesto nado. Na samom dele prijatno videtj shto u kovo to takaja zhe arhitektura. :)
ИМХО Event Sourcing который хранит изменения это головная боль, мягко говоря. Что если схема изменится - название поля, тип .т.д., что делать со старыми записями обновлять - охренеешь от багов, оставлять как есть - зачем этот мусор вообще нужен. Суть ES это не git, просто нужно записывать каждый раз новую копию и не париться. Автор я думаю сложные системы никогда не строил, судя по обилию явных ошибок и поверхностных рассуждении, просто впиливает в проекты модные фичи. Чего ещё в принципе ждать от работников епама.)
"просто нужно записывать каждый раз новую копию и не париться" - то есть каждая запись является полной и на время её создания содержит все данные? Если я, например, считаю голоса (лайки, рейтинг, мнения и т. д.), а потом обнаруживаю накрутки, как мне перестроить конечные данные? Ведь все события уже посчитаны и записаны. А если хранить только сами события и считать в другую таблицу/базу финальные данные, то я в любой момент могу перестроить фильтры и финальное состояние. Так же я могу добавить два финальных состояния (и больше). Первое - это число голосов с фильтром ботов, а вторая, для аналитики - тенденцию накруток. Если же Вы сразу храните полную копию данных, то любое изменение фильтрации сделает все события ошибочными (они же уже посчитаны, содержат полную информацию и при изменении фильтра информация будет некорректной).
Если че, изменение поля - это тоже эвент
Мы использали JsonIgnore..., мы использали JsonIgnore... пипец) что это за фундаментальная шутука такая, видимо что-то из CS, и доступно только для продвинутых jзеров :)
Вообще у автора в голове полная каша, лучше бы сделали простые MVC формы. При таком то уровне зананий стыдно выступать с докладом.