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

Question

В нашем приложении мы сохраняем двоичные данные в базе данных (ужасно, я знаю, но это устаревшие вещи, и это было не мое решение). Мы пытаемся перенести эти данные на внешнее устройство, и я пытаюсь найти схему для сохранения этих файлов.

У нас есть несколько арендаторов, я хотел бы иметь каталог для каждого арендатора. Моя схема состоит в том, чтобы построить путь, используя первые три буквы арендатора. Поэтому, если у вас есть арендатор под названием apple, его файлы будут находиться в /a/p/p/apple. В этих каталогах я сохраню файлы. Для файлов я хочу сгенерировать случайное 6-значное буквенно-цифровое имя (только строчные буквы в настоящее время по внутренним причинам). Поэтому, если мы создадим имя файла под названием 6a8jxo, оно будет сохранено как <tenant>/6/a/6/6a8jxo. С помощью этой стратегии каждый арендатор может иметь максимум около 916 миллиардов уникальных файлов (не то, что мы пытаемся сэкономить много), с максимальным количеством 46 656 файлов в каталоге. Если я поеду на 5-значное имя, у нас будет максимум 60,5 миллиардов уникальных файлов с 1 296 файлами в каталоге.

Есть ли недостатки в этом подходе? Я понимаю, что некоторые каталоги могут содержать только один или два файла, но, на мой взгляд, это не проблема.

Мой коллега не хочет этого делать; он хочет использовать автоинкрементное поле в базе данных, а затем основывать структуру каталогов на шестнадцатеричном (предположим, 32-разрядном), что вместо использования арендатора. С его стратегией шестнадцатеричное значение будет использоваться следующим образом: файл будет храниться в каталоге, расположенном по адресу <tenant>/aa/bbb, где aa - это первые два символа (наиболее значимые полубайты) шестнадцатеричного значения, а bbb - следующие три. Его рассуждение состоит в том, что он только хочет создавать новые каталоги, когда заполняется, а не содержит множество частично заполненных каталогов.

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

Есть ли какие-либо другие стратегии или подходы, которые я не рассматривал?

Answer 1

Я думаю, что главное, что вы не учли, это вероятность столкновения в ваших случайных именах файлов.

С такими маленькими именами, у вас есть только 36^6 = 2,176,782,336 уникальные файлы, а значит, вы, вероятно, получить коллизию до попадания 50000 файлов (http://en.wikipedia.org/wiki/Birthday_problem) - не огромное количество (и, конечно, всегда есть шанс получить один намного раньше).

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

Если вы абсолютно не хотите полагаться на базу данных для создания последовательной последовательности, вы можете использовать UUIDs для имен.

Вы также планируете очень глубокие деревья - сколько файлов (и арендаторов) вы ожидаете? Разумное эмпирическое правило состоит в том, чтобы иметь 10 000 файлов (фактических, а не только возможных) для каждого каталога и, вероятно, больше с современными файловыми системами. Три уровня подкаталогов почти наверняка переполнены.

Кроме того, если вам нужно разделить арендаторов на несколько каталогов, сначала используйте их (или используйте идентификаторы базы данных) - использование натуральных имен может привести к очень неуравновешенным «ведрам» (вероятно, здесь не большая проблема, но это не так Не стоит ничего делать правильно).

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