ŹR
Т.е. мне надо дропнуть таблицу полностью и сделать новую иногда
Size: a a a
2020 January 09
ŹR
Но я так понимаю, что могу попасть в ситуацию когда читающий видит отсутствие того что уже удалили и отсутсвие того что ещё не добавили
YZ
Если нужен lru кеш, тл лучше взять готовую реализацию
YZ
Ну или если своя реализация кеша из нескольких таблиц, то надо их прятать от клиентов
YZ
Но один ген сервер будет узким местом
YZ
И масштабирование такого решения не тривиально
YZ
Если оно нужно. Если не нужно, то ок
ŹR
cache прям жосткое название для либы.
Так получается, что она ни в один мой проект не войдет из-за name conflict))
Так получается, что она ни в один мой проект не войдет из-за name conflict))
АН
На сколько ets за genserver может быть хуже чем расширенная ets - на чтение
оверхед на передачу сообщений в любом случае будет. Также боттлнеки в генсерверах известный мем от яндекса
SP
Т.е. мне надо дропнуть таблицу полностью и сделать новую иногда
я помнится строил diff между текущей таблицей и той которую хотим получить после апгрейда. ключи которые нужно перезаписать можно вставить атомарным
ets:insert(Tab, ListOfObjects). Те которые нужно удалить обычно можно удалить следующим шагомSP
но если нужно атомарно удалить и добавить то не уверен. может те которые нужно удалить можно заменить на затычку stub
ŹR
я помнится строил diff между текущей таблицей и той которую хотим получить после апгрейда. ключи которые нужно перезаписать можно вставить атомарным
ets:insert(Tab, ListOfObjects). Те которые нужно удалить обычно можно удалить следующим шагомФишка в том, что я даже не уверен что не подойдет 1 генсервер, а замарачиваться прям не хочется
ŹR
Теоретически, на сколько возможно же поменять потом генсервер на пул
ŹR
Оперативы не жалко
SP
возможно конечно. правда если есть более "горячие" ключи или ets:select, то сложнее
SP
но с пулом gen_server не совсем я сно как атомарно их обновить. нужно какой-то механизм синхронизации - пока все не обновили не давать читать
ŹR
но с пулом gen_server не совсем я сно как атомарно их обновить. нужно какой-то механизм синхронизации - пока все не обновили не давать читать
А это то же не жалко, в моей конкретной ситуации мне можно чтобы приходили устаревшие данные. Главное чтобы не было сильных просадок по перфу и не было ситуации где НЕТУ данных
AB
Но я так понимаю, что могу попасть в ситуацию когда читающий видит отсутствие того что уже удалили и отсутсвие того что ещё не добавили
Если оперативы не жалко и кеш актуален от одной перезагрузки до другой, то храни старую версию (клиенты работают с ней) и строй неспеша новую, а как построишь переключайся
ŹR
Alexander Beniaminov
Если оперативы не жалко и кеш актуален от одной перезагрузки до другой, то храни старую версию (клиенты работают с ней) и строй неспеша новую, а как построишь переключайся
Да, но как переключиться то? Вот у меня есть named_table в ets, значит мне нужно строить другую с другим именем. А потом хранить актуальное имя опять же в генсервере?)