pansa

Лично меня еще смутили такме моменты:
1) а что это за хэши такие странные - в символах UTF8? Вкурсе, что _1 символ_ в этой кодировке может занять от 1 до 6 байт, что на таком кол-ве записей ведет к огромному разбросу. Если у вас хэш из ASCII, то тогда зачем притянули сюда UTF8?
2) 32-64 символа -- так 32 или 64? На вашем кол-ве это разница +- 50Тб . Это довольно серьезные объемы.
3) Как вы посчитали 100Тб? Вы учли место под индекс?

Идеи по проблеме:
1) тащить сюда реляционку не стоит, ибо...
2) очевидно, что это всё надо запускать не на одной машине, на глаз - минимум 2, не считая бэкапа (он нужен?) либо реплик => шардинг => kv-хранилища подойдут лучше (если мы правильно поняли, что вы хотите)
3) ничего не сказано про кол-во запросов - вставки/чтения. Но я бы подумал над размещением перед этим хранилищем предварительной проверке по фильтру Блума, чтобы лишний раз не стукаться в хранилище. Но это надо знать характер данных и запросов.

У меня этот shareup прописался прямо в тексты post'ов , т.е файлы WP целы (у меня мониторинг на изменения в ФС и жесткое ограничение прав), а вот в БД кто-то покапался. Подозреваю, что это уязвимость в WP, возможно, еще не исправленная. Гугл выдает кучу сайтов, у которых эти строки криво втиснуты в тексты постов -- очень похоже, что орудует бот. =(

> 2. Что за ошибка Killed: 9?
Запускаете в Linux? Скорее всего это работа OOM Killer, ваш распухший процесс он убивает сигналом SIGKILL.
Подробности легко нагуглите.

Пишите в текстовые файлы, в режиме append .
Ротируйте их каждые N секунд/минут, сколько вам надо. Отротированные файлы разгребает воркер, а все новые входящие - идут в текущий файл.
Очень просто и тупо =)