MG
С какой-то версии протокол и клиенты умеет жать и батчевать.
Size: a a a
2019 October 01
AR
Передачи и хранения, да.
Хранение с сжатием по батчам? Чот я не слышал о таком, завтра почекаю
ИФ
ИФ
К слову о кафке
RN
Zstandard - Real-time data compression algorithm
https://facebook.github.io/zstd/#small-data
https://facebook.github.io/zstd/#small-data
DS
Я для этой задачи заюзал fressian - из него можно потоком по одному объекту считывать и по одному записывать ну и плюс контрольная сумма есть
RN
Я для этой задачи заюзал fressian - из него можно потоком по одному объекту считывать и по одному записывать ну и плюс контрольная сумма есть
а как доставлял?
DS
ну задача была не совсем такой же конечно же :)
DS
просто надо было хранить бинарные данные которые легко можно было бы сериализовать/считывать в кложе. при этом нужна была поддержка durable записей, дозаписи в файл и стримингового чтения
DS
ну в смысле кложа-объекты в бинарном виде
MB
А есть какой-то хороший клиент для редиса, чтоб не на макросах, как кармин?
MP
А есть какой-то хороший клиент для редиса, чтоб не на макросах, как кармин?
я напрямую взял джавовый класс для него.
IG
кармин обмазывает все своим nippy
IG
если с редисом кто-то еще работает, скажем, из питона, они расстроятся
MP
ну да, это тоже момент такой, довольно важный.
KC
А есть какой-то хороший клиент для редиса, чтоб не на макросах, как кармин?
Jedis вполне себе норм
AR
> Kafka supports this with an efficient batching format. A batch of messages can be clumped together compressed and sent to the server in this form. This batch of messages will be written in compressed form and will remain compressed in the log and will only be decompressed by the consumer.
о, прикольно, спасибо
о, прикольно, спасибо
A
Есть не относящийся к кложуре вопрос. Есть access и refresh токены. Несколько параллельных запросов. Как обработать ситуацию когда на одном из запросов закончилось время жизни access токена, а остальные запросы уже ушли. Что вы с ними делаете в своих проектах?