По теме топика.

Расматриваю конфигурацию.

1. Amazon EC2/ WebApp/GraphQL (endpoint)
2. 2x EC2 / Apache Ignite Caches (caches)
3. Шаровый Amazon S3 как общая точка персистенса для двух Ignite.
4. Конфигурация кешей. Стандартная механика с WAL отключена (
5. Работаем как In-Memory. По прохождении 2 минут каждая запись делает выталкивается из кеша и сохраняется
в S3.

В чем вопрос.

На каждом Ignite есть быстрый локальный диск класса SSD. Он небольшой но больше чем оператива.
Хочу попробовать кеш с 2 уровнями когда запись выталкивается сначала на SSD. А после этого
на S3. Выталкивание на S3 - не срочное. Фактически оно актуально только когда идет перебалансировка
узлов. Тоесть падают и однимаются узлы и меняются маппинг партишенов для ключей. Грубо говоря
когда падает caches-01 то его локальные данные должны заехать в caches-02.

Схема предполагает бесконечно болшой рост узлов кешей. Так заявляет бизнес. Сейчас их 2 но может быть и 20 и 200.

Вопрос - концептуальный. Взлетит?

Консистентность между нодами у него - из коробки.

Система - для аналитики. Данные - write-only. +декларировано своство идемпотентности для всех ее частей.
БД. S3. И Ignite caches. Тоесть если какие-то данные недозагрузились - мы просто повторно повторяем
загрузку того дата-сета на котором было падение. И данные обновляются до последнего актуального состояния.
Если их нет - загружаются. Если уже были - сверяются и обновляются.

Уже несколько лет рассеяно думаю над идей. Вот сегодня сеть Bittorrent хранит пета-байты музла и видосов.
А можно ли эту сеть представить как распределённую файлову систему. Где ключ (директория или файл)
это в общем человекочитабельное название а значение - магнитная ссылка. Которая может быть
либо загружена по заказу пользователем на его локальный диск. Или вытеснена по eviction policy.

Разумеется доступ к просмотру содержимого таких файлов будет затруднен. Но обозревать каталог
можно будет всегда.

И различные points к реализации
- https://www.javadoc.io/doc/javax.cache/cache-api/1.1.1/index.html
- https://commons.apache.org/proper/commons-vfs/

Вернусь обратно к кешам. Почитал еще раз статью на хабре.

https://habr.com/en/company/surfingbird/blog/306252/

Заинтересовал меня этот 2Q.

Еще поинт. В тему Redis/Memcached.

Представим что у нас есть некий толстый диск старого типа. Магнитный на 16 терабайт.
Типа такого Seagate Exos X16 HDD 16TB 7200rpm 256MB ST16000NM002G 3.5

Смонтирован как /tmp со своей хитрой файловой системой.

И мы храним на нём фильмы. Музло. Вобщем всё что скачано для просмотра. Но храним
тоже по принципу кеша. Только очень большого и долгоиграющего.

Вычисляем для каждого файла его рейтинг полезности. Например если это сериал типа Game Of Thrones,
который мы с женой посмотрели уже раза 3. То соотв каждый файл этого сериала получает +3 балла.

А те файлы которые были просмотрены 0 раз - соотв внизу списка. И когда допустим я качаю
на этот диск новый сериал и при нехватке места (осталось 0.001 %) срабатывает логика
автоматического удаления старых файлов у которых этих баллов - меньше.

Чуть дальше. Я думаю несправедливо сразу грохать файлы не разу ни просмотренные.
Пускай будет некая вещественая метрика. Которая изначально - максимальна для файла
а потом - затухает со временем. Типа рейтинг свежести.

И при расчете итогового рейтинга мы будем брать некое взвешенно произведение просмотров на эту
метрику.

Если вдруг (внезапно понадобился) файл который был удалён - он снова скачивается по magnet-link.
Линк в свою очередь хранится всегда и не удаляется.

Вобщем - дисковая система которая имеет в теории - бесконечный размер. В практике она будет
хостить только полезные к просмотру сериалы.

Я качаю авторские фильмы с торрентов про которые эпл и нетфликс слыхом не слыхали.

Кроме того я пишу о дисковом кеше который сэкономит тебе трафик и бабки.

По поводу AWS.

Ты общался с джавистом? Теперь пообщайся со мной. AWS-lambda это говно еще то. И наша к примеру
попытка полносьтю выйти в server-less провалилась. Приложение не декомпозировалось на лямбды.

Возможно удел лямбд это например написание конвертеров картинок которые делают thumbnails
для крупного хостинга изображений. Но написание сколь-либо сложной и вменяемой логики - почти
невозможно. Есть ограничения на память и на время сеанса.

По поводу AWS-S3. Кроме того что он толстый (это правда). Он еще и обладает некоторыми свойствами
которые выводят его из области обычного использования файловой системы. И подводят тебя к другим
принципам. Типа асинхронизма и идемпотентности. Грубо говоря S3 - это НЕ ФАЙЛОВАЯ система.
В ней нет директорий как таковых. Грубо говоря навигация по каталогам - это фейк. И если кто-то завязался
на таймингах которые критичны к тому как вы навигируетесь по каталогам - поздравляю вас - вы проиграли.
Любой жлобский магнитый диск навигацию сделает быстрее.

Этот месседж надо выжечь калёным железом на руке каждого кто хочет заниматься с AWS в будущем.
Я видел уже 2 проекта которые облажались думая что их логика которая персистит и читает документы
с локальной ФС вдруг (!) внезапно взлетит и также будет работать с S3.

По поводу всех остальных сервисов я пока не готов говорить. Кстати в тостере есть много вопросов
по биллингу.

Ответ один - делайте макет - и замеряйте траты своих денег. Никто и никогда не может наперед угадать
сколько вы заплптите за EC2+Dynamo+S3+SQS+Lambda+Gate после того как вы задеплоите ваше
сферическое приложение в вакууме.

Смотрите самую дорогую позицию в биллинге и оптимизируйте ее. Как - вот это уже тема отдельных
курсов обучения. Благо в youtube есть миллион индусов котовых вам бесплатно хотя и не качественно
об этом расскзать.

Апну тему по поводу алгоритма 2Q.

Основная суть изложена в документе
2Q: A Low Overhead High Performance Buffer Management Replacement Algorithm
(авторов много)
https://pdfs.semanticscholar.org/d62d/e5f995164fff50f5ce61c0113f6bc9f04225.pdf

Есть также очень корявая и бестолковая статья на хабре где автор пытается это использовать.

Расскажу своё понимание.

2Q основана на более агрессивной политике выталкивания слотов (slots) из LRU.
Предполагается что горячие данные - это те которые будут востребованы через несколько
шагов работы 2Q сразу же как только были туда положены. В отличие от классического
LRU который награждает поднятием вверх всех подряд участников кеша независимо
от эвристики.

Теоретический документ (приаттачено) оперирует двумя очередями A1, Am. Это очередь
потенциальных горячих слотов и очередь лузеров. Очереди в обычном режиме просто
проталкивают элементы из одной в другую (паровозиком). Если подать в них sequence
уникальных чисет то так это и будет. Но если элемент был запрошен в момент когда
находился в A1. То происходит его защелкивание в отдельной структуре LRU тех
самых горячих блоков. Повторное чтение-же лузеров из Am не вызывает никакой реакции.
Авторы считают (в конце статьи) что это дает +5-10% перформанса к реалистичным
данным по отношению к простому LRU.

Вот вобщем-то и весь алгоритм. Длины очередей - это экспертные настроечные параметры.

Статья не говорит но насколько я понял очереди это метафора. Там на самом деле нужны
гибриды очередей и хешей (тоесть те-же самые 2хLRU но с разной политикой выталкивания).

Для оптимизации очереди должны трекать линки на данные чтоб избежать копирования объектов.

Вот пока всё.

Кому интересно - читайте. Пишите свои (ценные) каменты.

Я пока почитал про
JDK LinkedHashMap
https://docs.oracle.com/javase/9/docs/api/java/util/LinkedHashMap.html
(там есть возможность переопределить removeEldestEntry())

Apache Commons LRUMap
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/map/LRUMap.html
(фиг знает что никогда не юзал)

EhCache (пока непонятно) Есть оно там или нет? Какие алгоритмы и какие политики вытеснения.
https://www.ehcache.org/documentation/3.8/