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

Откуда: Самара
Сообщений: 1783
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
Сообщений: 42861
По теме топика.

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

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

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

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

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

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

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

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

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

Откуда: loopback
Сообщений: 42861
И различные 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
Сообщений: 42861
Вернусь обратно к кешам. Почитал еще раз статью на хабре.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того я пишу о дисковом кеше который сэкономит тебе трафик и бабки.
сегодня, 00:01    [22015779]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Java Ответить