История изменений
Исправление x3al, (текущая версия) :
И ты проигнорировал как днище мой вопрос, простая система, как ты соберёшь отчёт за 5 лет, где будешь хранить данные, как будешь обрабатывать перезагрузку сервера при установлении обновлений безопасности.
Подожди, тут про очередь речь идёт? Распределённая очередь — ок архитектура для современных приложений. Суть: берётся что-нибудь вроде kafka (удачи девопсам это ментейнить в продакшне) или kinesis, любое событие запихивается в эту очередь. Консумеры этой очереди — это, например,
* тупо лог всей очереди — для банального дебага, возможности replay либо добавления новых отчётов по старым данным.
* nosql-база для часто выполняемых запросов
* если нужна бизнес-аналитика и произвольные запросы — данные для этой самой аналитики запихиваются в нужную SQL-базу
* прочие консумеры могут вытаскивать, например, ЛЮБУЮ техническую статистику из этой же очереди для того же анализа загруженности. Не мешая всему остальному.
* бэкапы, снапшоты и прочие радости жизни банальны: (за бесконечное время) ты можешь откатить всю систему на ЛЮБОЕ состояние при наличии лога событий и при желании выкинуть/отменить любые события из лога если сильно нужно.
при этом ты можешь масштабировать ЛЮБОГО из консумеров этой очереди независимо от других. Да, это работает с терабайтами данных. Да, эта архитектура начинается с дублирования данных (каждый консумер держит копию интересных ему данных). Да, консумеры ничерта не консистентны между собой в любой момент времени в общем случае, но они eventually consistant т.е. рано или поздно твой отчёт за 5 лет увидит свежие данные в своей базе, но это может быть чуть позже, чем их учтёт более реалтаймовый микросервис. Хочется, чтобы все данные учитывались одновременно везде и это не просаживало производительность/доступность? Отдел фантастики про distributed transactions — на другом этаже.
Подводные камни — ошибка в классификации событий приведёт к костылям нереального размера либо переписыванию уймы кода, ну и прочие радости event sourcing.
Исправление x3al, :
И ты проигнорировал как днище мой вопрос, простая система, как ты соберёшь отчёт за 5 лет, где будешь хранить данные, как будешь обрабатывать перезагрузку сервера при установлении обновлений безопасности.
Подожди, тут про очередь речь идёт? Распределённая очередь — ок архитектура для современных приложений. Суть: берётся что-нибудь вроде kafka (удачи девопсам это ментейнить в продакшне) или kinesis, любое событие запихивается в эту очередь. Консумеры этой очереди — это, например,
* тупо лог всей очереди — для банального дебага, возможности replay либо добавления новых отчётов по старым данным.
* nosql-база для часто выполняемых запросов
* если нужна бизнес-аналитика и произвольные запросы — данные для этой самой аналитики запихиваются в нужную SQL-базу * прочие консумеры могут вытаскивать, например, ЛЮБУЮ техническую статистику из этой же очереди для того же анализа загруженности. Не мешая всему остальному.
при этом ты можешь масштабировать ЛЮБОГО из консумеров этой очереди независимо от других. Да, это работает с терабайтами данных. Да, эта архитектура начинается с дублирования данных (каждый консумер держит копию интересных ему данных). Да, консумеры ничерта не консистентны между собой в любой момент времени в общем случае, но они eventually consistant т.е. рано или поздно твой отчёт за 5 лет увидит свежие данные в своей базе, но это может быть чуть позже, чем их учтёт более реалтаймовый микросервис. Хочется, чтобы все данные учитывались одновременно везде и это не просаживало производительность/доступность? Отдел фантастики про distributed transactions — на другом этаже.
Подводные камни — ошибка в классификации событий приведёт к костылям нереального размера либо переписыванию уймы кода, ну и прочие радости event sourcing.
Исходная версия x3al, :
И ты проигнорировал как днище мой вопрос, простая система, как ты соберёшь отчёт за 5 лет, где будешь хранить данные, как будешь обрабатывать перезагрузку сервера при установлении обновлений безопасности.
Подожди, тут про очередь речь идёт? Распределённая очередь — ок архитектура для современных приложений. Суть: берётся что-нибудь вроде kafka (удачи девопсам это ментейнить в продакшне) или kinesis, любое событие запихивается в эту очередь. Консумеры этой очереди — это, например,
* тупо лог всей очереди — для банального дебага, возможности replay либо добавления новых отчётов по старым данным. * nosql-база для часто выполняемых запросов * если нужна бизнес-аналитика и произвольные запросы — данные для этой самой аналитики запихиваются в нужную SQL-базу * прочие консумеры могут вытаскивать, например, ЛЮБУЮ техническую статистику из этой же очереди для того же анализа загруженности. Не мешая всему остальному.
при этом ты можешь масштабировать ЛЮБОГО из консумеров этой очереди независимо от других. Да, это работает с терабайтами данных. Да, эта архитектура начинается с дублирования данных (каждый консумер держит копию интересных ему данных). Да, консумеры ничерта не консистентны между собой в любой момент времени в общем случае, но они eventually consistant т.е. рано или поздно твой отчёт за 5 лет увидит свежие данные в своей базе, но это может быть чуть позже, чем их учтёт более реалтаймовый микросервис. Хочется, чтобы все данные учитывались одновременно везде и это не просаживало производительность/доступность? Отдел фантастики про distributed transactions — на другом этаже.
Подводные камни — ошибка в классификации событий приведёт к костылям нереального размера либо переписыванию уймы кода, ну и прочие радости event sourcing.