Какой выбрать принцип распределение записей (BLOB) по таблицам?

Question

[nikitasius]

Добрый день.
Есть задача: каждый день система получает от людей текстовый материал, которые затем сжимает и закидывает в blob.
Условие - тексты могут редактироваться (то есть распаковали, клиент отредактировал, далее нажал сохранить и текст снова сжат и текст по новой закинут в базу).

По какому принципу раскидывать blob'ы по таблицам?

• к примеру blob4k, blob8k, blob16k - как если финальный текст (сжатый) менее 4кб, то в первую, от 4 до 8 - вторая, более 16 - третья
  
• или blob001, blob002, blob003 - где число выбирается на рандомно (от 1 до 3), чтобы данные более равномерно писались.
  
• или некий балансер, который каждый раз выбирает таблицу с наименьким суммарным объемом данных и закидывает туда? (что немного добавит нагрузки на базу в плане подсчета int поля с объемом сжатого текста)
  

Вероятно существует и 4й и 5й варианты, которые я бы с радостью услышал.

Answer 1

[Rsa97]

Вариантов существует море, например считать хэш и использовать его первую цифру. Основной вопрос в другом - а нужен ли такой изврат и какие преимущества он даёт перед, например, хранением файлов на диске и пути к ним в базе.

Comments

[nikitasius]

Да, хеш у меня так же будет считаться для поиска дубликатов. Преимущества базы - быстрый поиск записи по id и взятие blob'а, вместо операций чтения и записи с файлами на уровне сайта. Быстрые бекапы десятков таблиц, вместо rsync по миллиону файлов. Поэтому данные будут храниться как blob и интересует метод, по которому их распределять.

Ваш вариант с первой буквой хеша хорош, но я получаю ограничение в 36 таблиц. Если использовать 2 буквы - ограничения уже не будет, но мне придется создать 1296 таблиц, для запуска, или писать костыль. Поэтому нужно гибкое решение, которое можно масштабировать.

[Rsa97]

nikitasius: Если брать первый байт хэша, то будет 256 вариантов, от 0 до 255 (00-FF). Ну и никто не мешает брать неполные байты, например 10 первых бит из хэша (000-3FF) дадут 1024 варианта.

[Rsa97]

nikitasius: И учитывайте, что совпадение хэшей не означает автоматического совпадения данных. Всегда есть вероятность получить на двух разных блоках одинаковые хэши.

[nikitasius]

Rsa97: про совпадение и дубликаты я уже думал, в итоге решил два хеша хранить, sha1 и sha256, шанс получения двух одинаковых хешей по 2м алгоритмам ниже.
Я сейчас посмотрю, на сколько по времени хватит варианта с 10 битами и стоит ли использовать некий балансер (который будет указывать скрипту, в какую таблицу закинуть файл). Спасибо.