Ничего не запутанно, нормально. Polyglot persistence, для хранения горячих и холодных данных используются разные хранилища. Горячие данные нужно максимально быстро читать (из памяти), и в то же время все данные нужны для долговременного хранения (в базе/на дисках)

Мне очень понравилось все что вы сейчас написали. Мне действительно нужно нечто немного более сложное чем кэш, и я думал что это и есть грид. Мне нужно быстро писать и быстро и относительно гибко читать. Логика туда попадает в очень незначительном количестве и то скорее от безысходности

С моей точки зрения недооценена вот эта книга: https://www.amazon.com/Streaming-Data-Understanding-real-time-pipeline/dp/1617292281/

В этой книге описана концепция потоковой обработки. Описан ряд кейсов. В целом, подходит для понимании именно концепции.

Также, незаслуженно забыта лямбда архитектура.

https://www.amazon.com/Big-Data-Principles-practices-scalable/dp/1617290343/

Книга во многом устарела, но для понимания на коцептуальном уровне так же подходит.

Из прикладных: https://www.amazon.com/dp/1617294470/

Большую часть задач по обработке интенсивных потоков информации (хайлоаду) можно решить с помощью Lambda/Kappa архитектуры, где одну из ключевых ролей играет потоковая обработка. При этом, конечно, нужно не ошибиться с выбором хранилищ данных (СУБД/Кэшей), но это не критично. Потому что при правильном дизайне остаётся шанс миграции на хранилища, более подходящие под заданные сценарии нагрузки, которые далеко не всегда сразу видны. Ну и без Polyglot Persistence на экстремальных нагрузках вряд ли получится обойтись. И да, эти концепции не противорячат EDA и микросервисной архитектуре.

Мы тут не недавно обсуждали блокировки в MySQL, а стоило бы дизайн в целом обсудить.

Нужно всегда смотреть на дизайн в целом, потому что если где-то появляется бутылочное горлышко, возможно нужно менять именно дизайн. Мы так же не должны забывать про баланс ресурсов - память/проц/диски/сеть. Если упираемся в предел по одному из ресурсов, нужно менять алгоритмы/дизайн и смещать баланс.

Вместо этого, инженеры ищут волшебный суперпроизводительный тул.

А теперь вернёмся к истории с гридом и поддержкой вендоров. Пример очень показательный. Не хочу никого критиковать, и всё же. Других таких примеров мало.

Эта абсурдная и противоречащая здравому смыслу ситуация возникла, с моей точки зрения, из-за распространения среди архитекторов утверждения лидера компании: "если нам что-то нужно, вендоры нам это сделают". Поэтому, когда рассматривали продукт, не подумали ни об отказоустойчивости, ни о безопасности, ни об обновлении, ни о чём важном по сути. Только представьте, в гриде, во всяком случае на тот момент, все данные были доступны всем, не было персистентности, то есть все данные были только в памяти, а кластера периодически разваливались. То есть потерять или скомпрометировать данные ничего не стоило. И на это хотели перевести банк. И понятно почему, потому что верили, что вендор всё допилит.

Если придерживаться мнения "у нас есть деньги и вендоры всё допилят", то нужно сразу машину времени закладывать в архитектурные решения. А вендоры найдутся, уверен. И поддержку продадут.

+100 про память/проц/диски/сеть

Показательно как юзает все кликаус, заточено именно под выюзывания железа в дц на 1$ цены

Хороший пример

Я правильно понял, Вы о том что ClickHouse избыточно потребляет все ресурсы системы?

Или наоборот оптимально?

В оптимальной пропорции которая хорошо ложится на то что вы можете купить в ДЦ (commodity hardware)

пример вы можете воткнуть 5-10 hdd, 256gb ram, 64core cpu, и 10gbit сеть
если переборщить с hdd/cpu ratio вы получите более медленный поиск. а наоборот - будет простаивать cpu

Это просто mindblowing, думаю все знают что это .. но я примеры особо не смотрел никогда

СУБД придется довольно сильно поменяться