Комментарии 9
Хоть бы какие-то примеры привели. Хотя бы примеры названий "Event Sourcing". И какие-то практические примеры - структуры данных, способы работы с ними.
Не хватает и каких-то описаний оценок производительности, компактности или иных показателей эффективности. Есть же NoSQL базы как Elasticsearch, MongoDB, Redis, CloickHouse и т.п. Может они не особо неизменяемые (а надо ли это уж так), зато более распространены. И как раз очень часто и используются как хранилища "условно" не изменяемых событий.
Да и чем реляционные базы хуже - сделал таблицу - и пишу туда события.
А неизменяемость организуется правами доступа.
Так же как-то остался в стороне вопрос с итогами - вроде бы в начале про них написали и всё - далее тема не развивалась.
Не понятно и про потоки. Одно событие может быть отнесено к разным потокам? Тут есть какие-то фишки по выстраиванию аналитических моделей и/или оптимизации?
Оставлены в стороне и вопросы эффективности обработки накопленных логов - есть ли какие-то особые преимущества у "Event Sourcing" по сравнению с более классическим подходом.
Оставлены в стороне вопросы надёжности, отказоустойчивости, резервирования, распределения нагрузки т.п.
Оставлены вопросы и обработки в асинхронных и параллельных схемах. Поступления данных из распределённых источников (в т.ч. в разных часовых поясах).
И ещё. На мой взгляд если во главу ставить 100% неизменяемость - то область применения становится уж очень сильно сужается область применения. Вот как по мне - у таких систем больше будущего при реализации гибридных баз как SAP HANA - т.е. где события - это лишь оперативный слой учёта (хотя он может быть и не оперативным при работе "задним числом") - а уже по "Event Sourcing" далее обновляются "условно" матричные данные состояния некоего учёта. И как раз тут может быть и работа в прошедшей хронологии... впрочем насаливать кучу слоёв событий друг на друга тоже можно (сохраняя всю историю изменений). Но бездумно это делать нельзя - тут тоже должны быть свои способы оптимизации. И тут не приведено никакой информации тоже. А без этого - всё пустое!
В общем, у меня сложилось впечатление, что статья попросту ни о чём!
Event Sourcing как архитектурный паттерн, Мартин Фаулер описывал лет 20 тому назад. Паттерн это не сама архитектура и не решение. Скорее просто описание принципа, который можно реализовать как угодно и для чего угодно. Например, его можно обнаружить в Redux из JavaScript с плагином time machine (хотя сам по себе редакс скорее не про это).
Хоть бы какие-то примеры привели. Хотя бы примеры названий "Event Sourcing". И какие-то практические примеры - структуры данных, способы работы с ними.
Как сказано в тексте-event sourcing - это паттерн, что такое пример названия паттерна непонятно.
Не хватает и каких-то описаний оценок производительности, компактности или иных показателей эффективности. Есть же NoSQL базы как Elasticsearch, MongoDB, Redis, CloickHouse и т.п. Может они не особо неизменяемые (а надо ли это уж так), зато более распространены
Т.к. это паттерн он может строится поверх разных баз, в том числе и перечсиленных выше. Сравнить по поивзодительности паттерн с базой довольно сложно(особенно с учетом того что он будет построен поверх какой-то базы).
И ещё. На мой взгляд если во главу ставить 100% неизменяемость - то область применения становится уж очень сильно сужается область применения.
Как раз для жтого в статье и есть примеры где этот паттерн применяется
В общем, у меня сложилось впечатление, что статья попросту ни о чём!
Без коментариев
Как сказано в тексте-event sourcing - это паттерн, что такое
пример названия паттернанепонятно.
Это всё понятно - я спрашивал про практические примеры реализаций - готовые инструменты и ПО, демонстрирующие паттерн с практической стороны - которые, условно, можно взять поставить и пощупать (и этом ощупывании и мело строить статью).
Т.к. это паттерн он может строится поверх разных баз, в том числе и перечсиленных выше. Сравнить по поивзодительности паттерн с базой довольно сложно(особенно с учетом того что он будет построен поверх какой-то базы).
Сравнивать паттерны по производительности вообще чуть ли не святое дело - но да - это обычно делается в рамках каких-то реализаций. Но ничего сложно в этом нет.
Но, кажется что я уже понял - тут по сути всё пустое - нет никакой особенной реализации - есть просто, условно, мат модель - и её можно реализовать где угодно как угодно - ну если будет угодно - самостоятельно - тут не приводятся готовые инструменты - от чего статья по-прежнему остаётся пустой!
Никаких особых техник оптимизации не приводится (но это не значит, что они вообще не существуют). Самая простая реализация - это просто включение у объекта хранилища (например у реляционной таблицы, но это не принципиально) прав доступа только на добавление новых элементов - и всё - паттерн реализован! Великое достижение!
Как раз для этого в статье и есть примеры где этот паттерн применяется
Идея применения есть, очень уж скомканная. Но ничего нового она не даёт - журналированием изменений сейчас никого не удивишь - и готовых инструментов для этого есть море!
В общем, у меня сложилось впечатление, что статья попросту ни о чём!
Аналогично! И у меня сложилось впечатление, что статья написана нейросетью.
Понимаю, что замечание не к переводчику, а автору, но тем не менее: автор не читал "Введение в системы Баз данных" Криса Дейта? Про хронологические БД "не, не слышали"(c)? Подозреваю, что у автора сомнительный уровень познаний в БД. Оттуда и восхищения от очередного открытия старых истин.
А я то губу раскатал!
Думал сейчас поведают тайны бытия - эффективные алгоритмы (ну или хотя бы готовые инструменты, реализующие эти алгоритмы) умеющие эффективно работать с данными, которые вот имеют такие заданные ограничения - условно "хронологически накапливаются", образуя иммутабельный поток кортежей.
Думал, расскажут как это всё это оптимизируется, например, для того же анализа в раздельных потоках, с преднастроенными фильтрами (или динамически организуемыми).
Думал расскажут как это эффективно хранятся такие данные (хотя NoSQL базы тут уже не одну собаку съели в решении задачи эффективного хранения и выборки для случаев, когда не нужен особо CRUD - хотя вопрос "а нужен ли CRUD", кстати, для обработки событий я бы пока оставил открытым - и об этом тоже было бы интересно узнать мировой опыт).
Думал продемонстрируют практические примеры применения паттерна для разного спектра задач.
Но не узнал я ровным счётом ничего....
Хотя лично для меня и тема эффективного сбора хранения и анализа гетерогенных логов, истории изменений очень актуальна, и тема оптимизации конкурентного обновления учётных ресурсов без наложения блокировок в одной базе, и тема обновления данных распределённых базах данных! И везде здесь паттерн event sourcing очень даже был бы востребован! Но как , в общем случае, сделать таблицу только для добавления это и школьник знает (сам тому учил в школе). А вот так сделать такую "таблицу" (хранилище данных), чтобы оно было максимально эффективным для некоторой более узкой стратегии её использования - вот это самый интересный вопрос! И на него и хочется получать информацию!
Мне этот паттерн сильно напоминает модель Блокчейна, где состояние блока неизменно, а данные имеют выраженный хронологический порядок.
Только не очень понятно, как осуществляется чтение и обеспечение консистентности в такой БД. Вы пишите про "отсутствие конфликтов при обработке транзакций", но как-то не совсем понятно за счет чего это может достигаться. Как к примеру избежать двойного списания стоимости заказа? По идее должен быть некий индекс, содержащий актуальную информацию объектов в системе и должна быть возможность выполнять транзакции или блокировать (lock) эти объекты перед добавлением новых событий, которые могут вызвать конфликт. Соответственно должен быть какой-то формат представления этого индекса и язык запросов к нему.
В целом, складывается ощущение, что это не альтернативный способ хранения данных, а скорее дополнение к традиционным инструментам, которое добавляет хронологическую перспективу работе с данными. Т. е. по-сути когда берется традиционная СУБД и все операции с данными записываются в отдельный лог (таблицу или коллекцию), помимо того, что эти изменения также фиксируются в основных таблицах/документах (snapshot).
Если так смотреть на этот вопрос, то получается, что это усложнение, которое дает два преимущества — возможность ретроспективного анализа событий (история всех операций) и возможность как-раз таки эту историю переписать (но Вы как раз говорите что этого не стоит делать), т. е. добавить/изменить какие-то события, чтобы, например, исправить баг приведщий к повреждению данных в прошлом и после этого пересчитать данные в основной таблице (обновить snapshot). Получится эффект того, как будто бага и не было.
Конечно, хотелось бы увидеть как этот паттерн применяется в конкретных решениях и какие задачи фактически закрывает.
Первая проблема выглядит странной, по идее если мы пишем события, то изменение формы это всего лишь еще одно событие.
Сможет ли Event Sourcing перерасти базы данных?