кубер не про это)

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

некислый k->v для стораджа, в котором ключ занимает фиксированное число байт, а значение - ограниченное число байт (e.g. до 16К?)

вот я тоже начинаю догадываться

ты серьезно?

1. Ну так и есть да
2. Угу. Шаред например крайне популярен в США. Хочу пслушать про их труд за копейки. И мы возвращаемся к изначальному гиганты туда не лезут, но лезут создав сервисы в своих облачных услугах. Я запутался - лезут или не лезут? :)))

в памяти потребуется держать 24 байта на урл

И? Да, я серьёзно. Я вон сраную выгрузку не смог в Гиг запихать. Там посложнее чутка, но всё же. Хотя всё умерло на фиксированных IPv4 в ключе

24 байта на URL? Это если ты собрался просто перебором искать

Фил, не расстраивай меня.

Мне всё равно, расстраиваю я кого-то или нет, но боевой clck.ru на pi zero - шапкозакидательство. Не прямо чтобы сильное, но оно

8 байт достаточно для значения хеша.
8 байт на смещение на диске и 8 байт на длину объекта. на самом деле можно 2 байта на длину объекта, потому что мы не разрешим настолько длинные оригинальные урлы на самом деле.

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

запись тривиальна:
1) считаем хеш
2) пишем объект на диск
3) пишем строчку в индекс (24 байта)

чтение тривиально:
1) считаем хеш
2) читаем смещение и длину объекта из индекса
3) отправляем с диска сразу в TCP-сокет

это даже не байтоёбство.
работы на день.

0. А мы учли свою проверку на уникальность при такой длине хэша?
1. Что такое "оптимизировать хэш-табицу"? Что за таблица?
2. Я пропустил место с мультиплексированием записи. С синхронной блокирующей небуферизированной записью тебе вся конструкция очень быстро фигвам нарисует
3. Я пропустил место собственно с индексом. Вероятно это как-то связано с (1), но я не вижу цифр
4. Я бы не стал утверждать, что небуферизированная логически беспорядочные чтение/запись не будет крайне неприятным узким местом, если мы говорим о нагрузках в 1000rps
5. В работу на день не включена конструкция по поддержанию целостности и/или восстановление. Хотя, конечно в простой конструкции это сделать проще. Но таки сделать надо

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

4. Не будет, если диск достаточно быстрый

2. А при чем тут это?

В смысле? Оно у тебя будет очень херово работать, если ты ничего не сделаешь с буферизацией записи

Вы изначально говорили о том чтобы оно помещалось в рам или на сд карту. Сд карта достаточно шустро работает так то.

Мы изначально говорили, что это должно заработать на pi zero. ну точнее, было такое утверждение. SD-карта вообше то ешё развлечение найти, чтобы шустро работало. Такая карта будет сравнима по цене с самим pi zero

Ну и то, я не знаю как она будет работать на рандомном i/o