еще налить. если все льется ровно и постоянно, то у меня насчиталось 38580 RPS на месяц. не факт, что достижимо, даже если у вас есть только PK. если появляются secondary indicies, по RPS еще будут падать. у нас с двумя вторичками выходит около 20K RPS batch REPLACE по 100 tuples per batch.
- space amplification: у вас 15Tb "сырых" данных, которые уложатся в x2->x3->xY в зависимости от. у вас есть такая дисковая полка с адекватными IOPS ?
- данные в vinyl надо как-то чистить от старых. вы будет делать drop space и новый space на месяц или DELETE на старые данные ?
- если вторичные индексы не уникальны, то это не потребует pread(2) по диску на каждую вставку, если уникальны, то придется закручивать blum filter's и тюнить page size
- в целом, если вы пошардите эту конструкцию на 4-8 shard'ов, то все выглядит вполне реально, vinyl в целом на профиле "много наливаем, редко читаем" ведет себя уже относительно прилично.
- ничего не мешает сделать синтетический тест и налить тестовых данных. сразу поймете, годно оно для ваших целей или нет. для наших 10B данных оказалось годным, однако сразу оговорюсь, что tuples у нас маленькие, до 100b.
Спасибо за развернутый ответ, думаю тогда лучше хранить по неделям или по 10 дней) сейчас в одном дне почти 3B кортежей, они удаляются через truncate почти без проблемно. Шардить не хотелось бы. Мне кажется шардирование принесет еще больше боли тут.
Обсуждают сегодня