Ануар Нурмаканов - Event Sourcing и CQRS на конкретном примере
ฝัง
- เผยแพร่เมื่อ 25 พ.ย. 2024
- Ближайшая конференция - JPoint 2025, 3-4 апреля (Москва + трансляция).
Подробности и билеты: jrg.su/T2zfbS
- -
. . . . Что такое Event Sourcing и зачем нам CQRS? Все слышали об этих двух парадигмах - теперь пора разобраться конкретнее, как реализовать их. В докладе будет и мотивировано решение обратиться к Event Sourcing, и разобран небольшой конкретный пример, в котором это всё работает с PostgreSQL и ElasticSearch.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
Отличный доклад. Просмотрел на одном дыхании.
Очень интересных доклад, спасибо докладчику! Взял для себя очень много пищи для размышлений.
Объяснил доступнейшим языком, спасибо!
Первый доклад по этой теме, после которого до меня прям много чего наконец-то дошло! Спасибо, Ануар )
Ты просто красавчик! Спасибо огромное ! 😘😘😘😘
Докладчик просто бомба, разжевал очень хорошо.
Thanks, очень хороший доклад.
Отличный доклад и докладчик! Спасибо!
Блин, на самом интересном закончилось
класс доклад, спасибо )) интересно и позитивно ))
В конце была интересная дискуссия, жаль что перебили.
Помоему нет. Автор объясняет, что два клиента могут считать одинаковое состояние агрегата и затем по разному изменить это одинаковое состояние. Без версионирования получится, что один клиент затрет изменения другого, так как изменения от последнего клиента должны учитывать изменения от предыдущего. Базовые вещи и вообще не про ES + CQRS. Слушатель этого не понимает и просто говорит рандомный набор слов.
@@xfgweb jygjygyg
Ануар, молодец, очень хорошо смотришься на сцене. Правильный слог, интонация и боди language
В общем виде разделение записи и чтения в рамках реляционных субд решает репликация БД. Может не стоит трудиться со сложным Юнитом по синхронизации из видео. Проще применить репликацию.
Отличный доклад!!! Про Бугаенко хорошо было)))
Автор упомянул перед вводом про CQRS и ES такую тему как DDD, с отсылкой как-будто это альма-матер...
а потом показывает, как через сеттеры шатает агрегат в СОБЫТИЯХ :):):):)
Отсюда видимо и начались проблемы с многопоточностью :)
"Мессадж броукер" - этим все сказано
Интересный вариант с кафкой, но я не совсем понял как будут решаться следующие проблемы если использовать кафку как event store:
1) Например мы добавили новую таблицу Materialized view, которая будет основана на уже существующих сообщениях и начинаем ее формировать и через кафку, нам придется прогнать миллиарды сообщения и обработать их, если например данные формировались несколько лет, возможно это вопрос к подходу, а не к кафке))
2) Например, у нас есть сообщения в кафке, но они же не вечно там хранятся, ну например, если электричество отключат и так далее и упадут контейнеры, и с образом что-то случится, как нам восстанавливать данные? Ведь, как я понял, на жестком диске они хранятся в таком варианте, что их нельзя будет прочитать, ну или это считается плохим подходом.. Получается их нужно будет резервировать каждый раз в каком-то другом формате а потом как-то считывать
3) Порядок сообщений, ведь в кафку сообщения могут падать в беспорядочном виде, а нам нужен будет например другой порядок, наверное это как-то решается на уровне приложений.. Но все таки? Например, в обычных бд можно сортировать хотябы по id или по другому полю потом считывать в порядке.
4) Как я понял нельзя считывать данные с определенного id, а например у нас уже есть materialized view до определенного id и нам нужно его обновить. В любом случае хотелось бы понять best practice для kafka. потому как многие рекомендуют его как event store
То что тут названо "обработчик" на 27:45 - в общепринятой терминологии называтся "Projector", а "материализованное представление" - "Projection"
Vidal i "обработчик" nazvonim "denormalizer"
Я фронтендер. Не могу отлелаться от мысли, что докладчик просто описывает redux с таймтревелом в немного видоизмененных терминах.
31:17 а индекс по agregateId или type?
24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.
Хороший доклад. Почему не сделать трансляцию из дискусионного зала? Уверен, там тоже полезная информация была.
в Амазоне нету Кафки, а чем Кинезис не подходит ?
доклад огонь. но про производительность mv такое себе.
Спасибо за интересное видео, но Киев пишется как Kyiv
Что такое постгрес сикель?
SQL некоторые почему-то читают как "сик уэл" . Он говорил не "постгрес сикель" а постгре сик уэл. Имеется в виду PostgreSQL. По крайней мере остальное правильно произносил, что большая редкость на руютубе.
Я конечно понимаю что докладчик старался, но эти шуточки больно слушать...
И зачем вводить в заблуждение о том что такое CQRS? Это всего лишь разделение команд от запросов, при этом можно писать/читать в одну и ту же базу, в одни и те же таблицы. То что можно выделить для запросов отдельные представления (даже отдельные базы построенные на другой парадигме) для увеличения производительности - это уже деталь, это не необходимое условие CQRS. И еще вагон других вопросов по откровенно базовым понятиям...
Это бич нашей сферы.
Из-за того что нет единого реестра (словаря), что такое %любое название%, возникают такие ситуации. Есть только книги отдельных людей, статьи, и они так же не консистентны в своих показаниях. Так же многие технические термины используются вообще без определений, просто по наитию.
Но и даже если был бы реестр, это не решило полностью проблемы, потому что "машина - это средство передвижения с 4 колесами", но при этом, если скрутить 4 колеса, то все равно это машина. А в какой момент это не становится машиной, если начать отламывать по одной детали? Грань тонка.
Журить докладчика по этому поводу не надо, если смысл передан без искажений, то дальнейший спор о терминологии просто не нужен.
Alex B что кроме ваших ощущений заставляет вас думать таким образом?
@@snowy0110 тем не менее человек задает справедливые вопросы. Со временем данные в событиях могут изменяться или даже сами события могут перестать существовать. Как при этом собирать актуальное состояние агрегата? Поддерживать текущую версию события и все предыдущие? Что делать если событие более не существует? Игнорировать такое событие при сборке агрегата? Как модифицировать read часть, чтобы она соответствовала этим изменениям?
Эти вопросы интересуют гораздо больше, чем пересказ любой статьи о том, что такое event sourcing и cqrs. Я не встречал адекватных решений, хотя сама архитектура довольно интересная.
@@xfgweb "Сами события могут перестать существовать" - это как? Кто-то создал запись, а потом изобрели машину времени и тебя с базой перекинули в прошлое, до создания записи?
@@ivangorsky7537 имею ввиду функционал сайта. Был какой-нибудь каталог - генерировал события. Затем он стал не нужен. Теперь весь код связанный с этим каталогом не нужен и должен быть удален. Тоже самое может быть и с отдельно взятым событием которое больше не нужно так как его генерирующий и обрабатывающий код был удален. Не держать же старый код только потому что когда-то какое-то событие было которое больше произойти не может то есть не существует с настоящего момента и далее.
С удовольствием посмотрел картинки и меме. Жаль голос на их фоне постоянно отвлекает.
А если серьёзно - отличный доклад, огромное спасибо за работу. Но назвите меня скучным и занудой, но моё личное скромное имхо - количество смешнявок перечёркивает весь труд.
Я так понял Kafka streams уже решает всю ту магию с базами и ентитями. Агрегация и прочая дич
Везде пример конференции... Может сам кто то что то придумаеет?
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. :)
Афтар отжог нипадецки