Автор упомянул перед вводом про CQRS и ES такую тему как DDD, с отсылкой как-будто это альма-матер... а потом показывает, как через сеттеры шатает агрегат в СОБЫТИЯХ :):):):)
Интересный вариант с кафкой, но я не совсем понял как будут решаться следующие проблемы если использовать кафку как event store: 1) Например мы добавили новую таблицу Materialized view, которая будет основана на уже существующих сообщениях и начинаем ее формировать и через кафку, нам придется прогнать миллиарды сообщения и обработать их, если например данные формировались несколько лет, возможно это вопрос к подходу, а не к кафке)) 2) Например, у нас есть сообщения в кафке, но они же не вечно там хранятся, ну например, если электричество отключат и так далее и упадут контейнеры, и с образом что-то случится, как нам восстанавливать данные? Ведь, как я понял, на жестком диске они хранятся в таком варианте, что их нельзя будет прочитать, ну или это считается плохим подходом.. Получается их нужно будет резервировать каждый раз в каком-то другом формате а потом как-то считывать 3) Порядок сообщений, ведь в кафку сообщения могут падать в беспорядочном виде, а нам нужен будет например другой порядок, наверное это как-то решается на уровне приложений.. Но все таки? Например, в обычных бд можно сортировать хотябы по id или по другому полю потом считывать в порядке. 4) Как я понял нельзя считывать данные с определенного id, а например у нас уже есть materialized view до определенного id и нам нужно его обновить. В любом случае хотелось бы понять best practice для kafka. потому как многие рекомендуют его как event store
Помоему нет. Автор объясняет, что два клиента могут считать одинаковое состояние агрегата и затем по разному изменить это одинаковое состояние. Без версионирования получится, что один клиент затрет изменения другого, так как изменения от последнего клиента должны учитывать изменения от предыдущего. Базовые вещи и вообще не про ES + CQRS. Слушатель этого не понимает и просто говорит рандомный набор слов.
В общем виде разделение записи и чтения в рамках реляционных субд решает репликация БД. Может не стоит трудиться со сложным Юнитом по синхронизации из видео. Проще применить репликацию.
Я конечно понимаю что докладчик старался, но эти шуточки больно слушать... И зачем вводить в заблуждение о том что такое CQRS? Это всего лишь разделение команд от запросов, при этом можно писать/читать в одну и ту же базу, в одни и те же таблицы. То что можно выделить для запросов отдельные представления (даже отдельные базы построенные на другой парадигме) для увеличения производительности - это уже деталь, это не необходимое условие CQRS. И еще вагон других вопросов по откровенно базовым понятиям...
Это бич нашей сферы. Из-за того что нет единого реестра (словаря), что такое %любое название%, возникают такие ситуации. Есть только книги отдельных людей, статьи, и они так же не консистентны в своих показаниях. Так же многие технические термины используются вообще без определений, просто по наитию. Но и даже если был бы реестр, это не решило полностью проблемы, потому что "машина - это средство передвижения с 4 колесами", но при этом, если скрутить 4 колеса, то все равно это машина. А в какой момент это не становится машиной, если начать отламывать по одной детали? Грань тонка. Журить докладчика по этому поводу не надо, если смысл передан без искажений, то дальнейший спор о терминологии просто не нужен.
@@snowy0110 тем не менее человек задает справедливые вопросы. Со временем данные в событиях могут изменяться или даже сами события могут перестать существовать. Как при этом собирать актуальное состояние агрегата? Поддерживать текущую версию события и все предыдущие? Что делать если событие более не существует? Игнорировать такое событие при сборке агрегата? Как модифицировать read часть, чтобы она соответствовала этим изменениям? Эти вопросы интересуют гораздо больше, чем пересказ любой статьи о том, что такое event sourcing и cqrs. Я не встречал адекватных решений, хотя сама архитектура довольно интересная.
@@xfg9183 "Сами события могут перестать существовать" - это как? Кто-то создал запись, а потом изобрели машину времени и тебя с базой перекинули в прошлое, до создания записи?
@@ivangorsky7537 имею ввиду функционал сайта. Был какой-нибудь каталог - генерировал события. Затем он стал не нужен. Теперь весь код связанный с этим каталогом не нужен и должен быть удален. Тоже самое может быть и с отдельно взятым событием которое больше не нужно так как его генерирующий и обрабатывающий код был удален. Не держать же старый код только потому что когда-то какое-то событие было которое больше произойти не может то есть не существует с настоящего момента и далее.
24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.
С удовольствием посмотрел картинки и меме. Жаль голос на их фоне постоянно отвлекает. А если серьёзно - отличный доклад, огромное спасибо за работу. Но назвите меня скучным и занудой, но моё личное скромное имхо - количество смешнявок перечёркивает весь труд.
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. :)
Очень интересных доклад, спасибо докладчику! Взял для себя очень много пищи для размышлений.
Отличный доклад. Просмотрел на одном дыхании.
Автор упомянул перед вводом про CQRS и ES такую тему как DDD, с отсылкой как-будто это альма-матер...
а потом показывает, как через сеттеры шатает агрегат в СОБЫТИЯХ :):):):)
Отсюда видимо и начались проблемы с многопоточностью :)
Объяснил доступнейшим языком, спасибо!
Интересный вариант с кафкой, но я не совсем понял как будут решаться следующие проблемы если использовать кафку как event store:
1) Например мы добавили новую таблицу Materialized view, которая будет основана на уже существующих сообщениях и начинаем ее формировать и через кафку, нам придется прогнать миллиарды сообщения и обработать их, если например данные формировались несколько лет, возможно это вопрос к подходу, а не к кафке))
2) Например, у нас есть сообщения в кафке, но они же не вечно там хранятся, ну например, если электричество отключат и так далее и упадут контейнеры, и с образом что-то случится, как нам восстанавливать данные? Ведь, как я понял, на жестком диске они хранятся в таком варианте, что их нельзя будет прочитать, ну или это считается плохим подходом.. Получается их нужно будет резервировать каждый раз в каком-то другом формате а потом как-то считывать
3) Порядок сообщений, ведь в кафку сообщения могут падать в беспорядочном виде, а нам нужен будет например другой порядок, наверное это как-то решается на уровне приложений.. Но все таки? Например, в обычных бд можно сортировать хотябы по id или по другому полю потом считывать в порядке.
4) Как я понял нельзя считывать данные с определенного id, а например у нас уже есть materialized view до определенного id и нам нужно его обновить. В любом случае хотелось бы понять best practice для kafka. потому как многие рекомендуют его как event store
В конце была интересная дискуссия, жаль что перебили.
Помоему нет. Автор объясняет, что два клиента могут считать одинаковое состояние агрегата и затем по разному изменить это одинаковое состояние. Без версионирования получится, что один клиент затрет изменения другого, так как изменения от последнего клиента должны учитывать изменения от предыдущего. Базовые вещи и вообще не про ES + CQRS. Слушатель этого не понимает и просто говорит рандомный набор слов.
@@xfg9183 jygjygyg
31:17 а индекс по agregateId или type?
В общем виде разделение записи и чтения в рамках реляционных субд решает репликация БД. Может не стоит трудиться со сложным Юнитом по синхронизации из видео. Проще применить репликацию.
Я конечно понимаю что докладчик старался, но эти шуточки больно слушать...
И зачем вводить в заблуждение о том что такое CQRS? Это всего лишь разделение команд от запросов, при этом можно писать/читать в одну и ту же базу, в одни и те же таблицы. То что можно выделить для запросов отдельные представления (даже отдельные базы построенные на другой парадигме) для увеличения производительности - это уже деталь, это не необходимое условие CQRS. И еще вагон других вопросов по откровенно базовым понятиям...
Это бич нашей сферы.
Из-за того что нет единого реестра (словаря), что такое %любое название%, возникают такие ситуации. Есть только книги отдельных людей, статьи, и они так же не консистентны в своих показаниях. Так же многие технические термины используются вообще без определений, просто по наитию.
Но и даже если был бы реестр, это не решило полностью проблемы, потому что "машина - это средство передвижения с 4 колесами", но при этом, если скрутить 4 колеса, то все равно это машина. А в какой момент это не становится машиной, если начать отламывать по одной детали? Грань тонка.
Журить докладчика по этому поводу не надо, если смысл передан без искажений, то дальнейший спор о терминологии просто не нужен.
Alex B что кроме ваших ощущений заставляет вас думать таким образом?
@@snowy0110 тем не менее человек задает справедливые вопросы. Со временем данные в событиях могут изменяться или даже сами события могут перестать существовать. Как при этом собирать актуальное состояние агрегата? Поддерживать текущую версию события и все предыдущие? Что делать если событие более не существует? Игнорировать такое событие при сборке агрегата? Как модифицировать read часть, чтобы она соответствовала этим изменениям?
Эти вопросы интересуют гораздо больше, чем пересказ любой статьи о том, что такое event sourcing и cqrs. Я не встречал адекватных решений, хотя сама архитектура довольно интересная.
@@xfg9183 "Сами события могут перестать существовать" - это как? Кто-то создал запись, а потом изобрели машину времени и тебя с базой перекинули в прошлое, до создания записи?
@@ivangorsky7537 имею ввиду функционал сайта. Был какой-нибудь каталог - генерировал события. Затем он стал не нужен. Теперь весь код связанный с этим каталогом не нужен и должен быть удален. Тоже самое может быть и с отдельно взятым событием которое больше не нужно так как его генерирующий и обрабатывающий код был удален. Не держать же старый код только потому что когда-то какое-то событие было которое больше произойти не может то есть не существует с настоящего момента и далее.
Что такое постгрес сикель?
Спасибо за интересное видео, но Киев пишется как Kyiv
Первый доклад по этой теме, после которого до меня прям много чего наконец-то дошло! Спасибо, Ануар )
Я фронтендер. Не могу отлелаться от мысли, что докладчик просто описывает redux с таймтревелом в немного видоизмененных терминах.
Докладчик просто бомба, разжевал очень хорошо.
Блин, на самом интересном закончилось
То что тут названо "обработчик" на 27:45 - в общепринятой терминологии называтся "Projector", а "материализованное представление" - "Projection"
Vidal i "обработчик" nazvonim "denormalizer"
Хороший доклад. Почему не сделать трансляцию из дискусионного зала? Уверен, там тоже полезная информация была.
Ты просто красавчик! Спасибо огромное ! 😘😘😘😘
в Амазоне нету Кафки, а чем Кинезис не подходит ?
24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.
"Мессадж броукер" - этим все сказано
Thanks, очень хороший доклад.
доклад огонь. но про производительность mv такое себе.
Ануар, молодец, очень хорошо смотришься на сцене. Правильный слог, интонация и боди language
Отличный доклад!!! Про Бугаенко хорошо было)))
Я так понял 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. :)