значит надо сразу ставить максимально возможный буфер исходя из требований?) а на производительности не сильно скажется ведь?

На памяти скажется

Надо подумать как не упираться в буфер, это зависит от задачи

Нет. Нужно ставить столько, сколько оптимально для задачи

ну я и имел ввиду исходя из требований к задаче

команда из uber не рекомендует использовать буфферизованные каналы вовсе

только с капасити в 1

Это тоже хорошая рекомендация

В общем случае если у сервиса проблемы из-за размера канала, то проблема не в размере канала, а в логике сервиса

В такой формулировке согласен

Кто с кассандрой знаком, как обеспечить наибольшую скорость работы для следующего кейса:

Планируем использовать как недельный кеш для координат и других данных пользователей. Грубо говоря это структура на N полей, которую планируем хранить в протобафе. Больше недели хранить не требуется, делать сложные запросы тоже - только запросы по конкретной дате и по конкретному пользователю, сейчас вижу 2 варианта.

1) Создавайть кейспейс на текущую дату и по таблице на каждого пользователя:
    INSERT INTO 20201110.12345678 VALUES (blob), (blob)

2) Иметь общий кейспейс и таблицу для всех
    INSERT INTO main.history VALUES (date, userId, blob), (date, userId, blob)

ну и производные от них, есть инфа какой вариант наиболее подходит?

прямо сейчас выглядит, как запрос по record ID range + user, record ID ghb это кассандровский time-based UUID

А зачем кейспейс создавать на день?

не обязательно кейспейс, можно по таблице

Таблицу на каждого пользователя тоже не понял зачем.

В кассандре подход в том, чтобы создавать таблицу на каждый тип запроса. Для ретеншена стоит использовать соответствующую компакшн стратегию. Вам вроде отлично должна подойти TimeWindowCompactionStrategy.

затем что я не знаю как кассандра хранит данные и что лучше выбрать конкретную таблицу из миллиона, в которой 1000 записей, или выбрать конкретные 1000 записей из одной таблице со 100 миллионами строк

Почитайте про partition key, и как его строить правильно. Можете как раз партицировать по пользователям в разрезе времени.

Допустим, если по одному пользователю не больше 100к записей в день, то создаёте ключ, чтобы эти данные попадали в один партишн. От запроса надо плясать. Зависит что достать хотите потом.

спасибо, будем смотреть