Закодированные в Base64 данные - БД или файловая система - PullRequest
2 голосов
/ 21 ноября 2011

У меня есть новая программа, которая будет генерировать много аудио и изображений в кодировке Base64. Эти данные будут передаваться через HTTP в форме XML, а данные Base64 будут встроенными. Эти файлы, скорее всего, сломают 20 МБ и выше. Будет ли эффективнее обслуживать эти файлы непосредственно из файловой системы или будет возможно хранить данные в базе данных MySQL? Кэширование будет настроено, но в целом излишне, поскольку вполне вероятно, что эти данные будут удалены вскоре после того, как они созданы и обработаны.

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

Ответы [ 2 ]

2 голосов
/ 21 ноября 2011

Вам необходимо взвесить несколько факторов:

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

  • Сжатие MySQL может легко сжать ваши сохраненные данные.С файловой системой может быть сложнее сжимать данные.Использование любого вида сжатия также вызывает обеспокоенность по поводу скорости процессора на вашем сервере.

  • Резервное копирование / восстановление БД создана для простого резервного копирования / восстановления, какЛегко или сложно это для файловой системы сильно различается.Если у вас есть данные в файловой системе для резервного копирования / восстановления, это делает ваше резервное копирование / восстановление более сложным и сложным, что не очень хорошо в кризис.

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

  • Репликация С проблемами репликации легче справитьсяесли вам нужно сделать это только на одном уровне.Хранить ваши данные только в БД и затем реплицировать только БД гораздо проще, чем делать это для БД, а также для файловой системы.

  • громоздкость Этопросто более громоздко иметь дело с большими резервными копиями БД, чем с меньшими резервными копиями БД.

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

0 голосов
/ 21 ноября 2011

Во-первых, вы можете хранить любые байты, которые вам нравятся, в базе данных (используя соответствующие типы «BLOB-объектов»). Базы данных не должны содержать только символьные данные.

Во-вторых, для хранения данных в кодировке base64 на диске или в базе данных было бы бесполезной тратой пространства (в частности, 25% вашего пространства). Сохраните фактические байты, а затем закодируйте base64 байтов при выходе из HTTP-сервера.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...