Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Четверговая инвалидация кешей.  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1812
Alexey Tomin
Я ж говорю- GPG надо иметь с ключом.
Мавен централ пока не пропихнул либу


Разобрался я с централом- в oss.sonatype.com есть, скоро на https://mvnrepository.com/artifact/com.maxifier.mxcache/mxcache-asm
17 окт 19, 10:17    [21996130]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
По теме топика.

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

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.

Вопрос - концептуальный. Взлетит?
17 окт 19, 10:34    [21996155]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
kolchanov
Member

Откуда: Питер
Сообщений: 182
mayton,

Видимо не весь солюшен описан.
Если это кэш, то где мастер данные?
Или in-memory database, то где констистентность?
17 окт 19, 15:27    [21996649]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Консистентность между нодами у него - из коробки.
17 окт 19, 15:29    [21996652]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
kolchanov
Member

Откуда: Питер
Сообщений: 182
mayton,
Видимо, неправильно выразился.
Упала нода, на S3 часть данных не выгрузилась.
Данные пропали?
17 окт 19, 16:32    [21996735]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Система - для аналитики. Данные - write-only. +декларировано своство идемпотентности для всех ее частей.
БД. S3. И Ignite caches. Тоесть если какие-то данные недозагрузились - мы просто повторно повторяем
загрузку того дата-сета на котором было падение. И данные обновляются до последнего актуального состояния.
Если их нет - загружаются. Если уже были - сверяются и обновляются.
21 окт 19, 10:07    [21998650]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

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

Разумеется доступ к просмотру содержимого таких файлов будет затруднен. Но обозревать каталог
можно будет всегда.
1 ноя 19, 11:50    [22007941]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
И различные points к реализации
- https://www.javadoc.io/doc/javax.cache/cache-api/1.1.1/index.html
- https://commons.apache.org/proper/commons-vfs/
1 ноя 19, 12:01    [22007957]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Вернусь обратно к кешам. Почитал еще раз статью на хабре.

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

Заинтересовал меня этот 2Q.
13 ноя 19, 17:54    [22015647]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Еще поинт. В тему Redis/Memcached.

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

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

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

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

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

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

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

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

Вобщем - дисковая система которая имеет в теории - бесконечный размер. В практике она будет
хостить только полезные к просмотру сериалы.
13 ноя 19, 18:37    [22015666]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
asv79
Member

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

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

майтон это уже давно реализовано
в том же эпл music
ты покупаешь музло оно хранится в дата центрах эпл и по подписке дается юзерам
тоже саме есть у нетфликс
и у эпл тв
отстал ты от жизни брат)

пс.я тут общался с джавистом из pivotal в живую и он сказал дядь забудь нах все что ты знал)
вся эта этерпрайз шляпа через пару лет будет 90% на aws

я уже начал изучать книжонку их главного разраба - забыл как называется -
13 ноя 19, 20:53    [22015717]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Я качаю авторские фильмы с торрентов про которые эпл и нетфликс слыхом не слыхали.

Кроме того я пишу о дисковом кеше который сэкономит тебе трафик и бабки.
14 ноя 19, 00:01    [22015779]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
asv79

пс.я тут общался с джавистом из pivotal в живую и он сказал дядь забудь нах все что ты знал)
вся эта этерпрайз шляпа через пару лет будет 90% на aws

я уже начал изучать книжонку их главного разраба - забыл как называется -

По поводу AWS.

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

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

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

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

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

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

Смотрите самую дорогую позицию в биллинге и оптимизируйте ее. Как - вот это уже тема отдельных
курсов обучения. Благо в youtube есть миллион индусов котовых вам бесплатно хотя и не качественно
об этом расскзать.
14 ноя 19, 11:47    [22016032]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
lleming
Member

Откуда:
Сообщений: 1664
asv79
пс.я тут общался с джавистом из pivotal в живую и он сказал дядь забудь нах все что ты знал)
вся эта этерпрайз шляпа через пару лет будет 90% на aws


Один говорит будет, другой говорит нет. Поинтересуйся у него он вложил все деньги в акции Amazon если так уверен.
14 ноя 19, 11:52    [22016040]     Ответить | Цитировать Сообщить модератору
 Re: Четверговая инвалидация кешей.  [new]
mayton
Member

Откуда: loopback
Сообщений: 44166
Апну тему по поводу алгоритма 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/
4 янв 20, 19:45    [22053461]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Java Ответить