Где и как хранить файлы пользователей?
На сколько правильно хранить файлы пользователей web-приложения (Spring) в каталогах по относительному адресу? Например: c:/name project/users/1000/1...1000/ Когда количество папок в папке "1000" достигает соответствующего значения, то создаётся новый каталог со следующей тысячей: c:/name project/users/2000/1...1000/ и т.д. Есть ли какие-то альтернативные решения? Или как лучше всего хранить файлы пользователей?
Дополнительно:
Без разницы. Главное как-то ограничить количество объектов в директориях.
Можно хэш брать, например три символа от md5 – /users/a76/ – максимум будет ~4000 файлов
Можно сюда user_id добавить – /users/a76/12
Можно на дату опираться /users/2024/01/17
Лично я обычно по датам раскладываю.
Максимум файловой системы куда больше.
https://stackoverflow.com/questions/8238860/maximu...
При использовании даты - тут расчет на то, что за один день не будет загружено столько файлов, но это от проекта зависит.
Лично я знаю только один вариант: Обойти все файлы и суммировать их размер. А если файлов много (гигабайты или терабайты), то система подвиснет на время подсчета. И это проблема.
Реальная проблема в том, как проверить, сколько физического места занимает папка пользователей "users"?
Что ж вы о реальной проблеме ничего не написали в вопросе? Там речь идет только о методах хранения.
Наверное стоит "спросить" у операционной системы, вместо самостоятельного подсчета.
Лично я знаю только один вариант: Обойти все файлы и суммировать их размер. А если файлов много (гигабайты или терабайты), то система подвиснет на время подсчета. И это проблема.
От размера файла, получение его размера не будет больше или меньше. Только от их количества.
Но посчитать объем от сотни тысяч файлов не слишком долго, разве что надо это делать прям очень часто.
А так - посмотри в сторону S3 сервиса
посчитать объем от сотни тысяч файлов не слишком долго
Ну, да, это по большому счёту секунды (секунд 10+ в среднем). Однако, может есть какая-то команда, чтоб запросить размер папки (проекта?) у операционной системы?
du /path/to/folder
du -k /path/to/folder
du -m /path/to/folder
du -h /path/to/folder
1. Адреса должны быть относительными всегда
2. Место хранения следует задавать переменной
-
Место хранения следует задавать переменной
Я предусматриваю "alternativeUsersPath" в виде LinkedList, но пока что не реализовал... Есть ссылка на пример организации адресов через переменную?
-
1. Адреса должны быть относительными всегда
Разработчики движков покатываются от смеха :)
- My1Name, например https://www.baeldung.com/spring-value-annotation
- My1Name, вот еще: https://www.baeldung.com/spring-boot-command-line-...
- Dmitry Roo, первая ссылка интересная, но всё как-то очень сложно... У меня конфигурация системы (пути к внешним каталогам и файлам) подгружается через класс Tools. В этом же классе реализованы методы, которые читают системные файлы, которые админ (через своеобразную CMS приложения) может менять.
- Dmitry Roo, проблема в том, что относительный адрес нужно менять в двух случаях: 1. Количество каталогов достигает лимита файловой системы. 2. Мало памяти на накопителе.
Первый вариант достаточно просто решить. А во втором случае, нужно обойти все файлы в каталогах и суммировать их размер. Это "дорогостоящий процесс", если файлов миллионы и всё это дело измеряется гигабайтами или терабайтами данных. В это время, приложение может подвиснуть на какое-то время...
- Refguser,
Разработчики движков покатываются от смеха :)
Движки они во первых на то и движки, что ограничиваются чем-то в угоду универсальности, во вторых многие позволяют настраивать вид ссылок - относительные или абсолютные. В разработке "с руки" удобнее пользоваться именно относительными путями, так как это более переносимое решение.
- ThunderCat,
В разработке "с руки" удобнее пользоваться именно относительными путями, так как это более переносимое решение.
"Аполитично рассуждаешь! Аполитично рассуждаешь, клянусь, честное слово! Не понимаешь политической ситуации." (С) тов. Саахов. :)
Всё зависит от конкретных задач. И двиджки на это тоже как бэ намекают.
Ответы:
Это вообще не вопрос. Реальная проблема в том, как проверить, сколько физического места занимает папка пользователей "users"?
Во первых если это реальная проблема - почему вопрос совершенно о другом?
Во вторых - у вас в примере виндовый диск, что как бы странно для хостинга. В случае линуха все решается либо командой du -sm /your/directory/* либо установкой ncdu, который сильно быстрее, и соответственно что-то типа ncdu /your/directory/.
-
Во первых если это реальная проблема - почему вопрос совершенно о другом?
Это вроде как к одна тема...
Во вторых - у вас в примере виндовый диск
А какая разница, если я хочу мониторить количество файлов и физический размер папки "users" через приложение (CMS)?
- My1Name,
1. Это совершенно разные темы и задачи.2. Если самостоятельно будете подсчитывать общий размер файлов обходом - нет разницы. Если будете запрашивать у операционки через системные вызовы, разница огромная.
- Сергей delphinpro,
разница огромная
Я понимаю. Поэтому и задал вопрос:
Есть ли какие-то альтернативные решения?
Как получить доступ к логическим дискам на выделенном сервере?
- My1Name, Вы извините, но у вас какие-то скачки. То нужно структуру хранения, то как получить доступ к логическим дискам, то как посчитать размер... В чем вопрос то?
- ThunderCat, Вопрос в том, что на выделенном сервере, обычно подключен дисковый массив в рейде.. По мере увеличения проекта, непонятно, нужно ли менять адрес хранения данных при увеличении дискового пространства?
- My1Name,
Вопрос в том, что на выделенном сервере, обычно подключен дисковый массив в рейде.. По мере увеличения проекта, непонятно, нужно ли менять адрес хранения данных при увеличении дискового пространства?
Во первых - чем вам помогло решение отмеченное как верное в контексте этого вопроса? Во вторых - какой адрес вы собираетесь менять? Обычно при расширении райд массива вы получаете просто дополнительное пространство, виртуально объедененное в нужное количество разделов. Как расширять зависит от задачи, то есть ничего не мешает просто увеличить место на использующемся разделе.
- ThunderCat,
Во первых - чем вам помогло решение отмеченное как верное в контексте этого вопроса?
1. Адреса должны быть относительными всегда 2. Место хранения следует задавать переменной. И это правильно. Потому что это позволяет не привязываться к поставщику услуг. В случае каких-то недоразумений, разработчик может поменять сервер (хостинг-провайдера). Кроме того, если используется выделенный сервер (или я покупаю статический IP и делаю свой), это позволяет добавлять диски и указывать новые адреса.
Во вторых - какой адрес вы собираетесь менять?
Думаю эту часть адреса делать опциональной c:/name project/users/ На данный момент, я программно создаю два каталога (две папки) "name project" и "users" относительно месторасположения проекта (System.properties). И это неправильно в контексте ограничений файловой системы... Нужно оставить возможность использовать корень жесткого диска.
Обычно при расширении райд массива вы получаете просто дополнительное пространство
Всё верно. И это только хранилище, а не сервер приложения... Сама программа обычно работает совершенно в другом месте.
Если тебе нужно временное место - то используй системную переменную
System.getProperty("java.io.tmpdir")
Или с префиксом и суффиксом - есть готовая функция которая возвращает файл.
Files.createTempFile("", ".tmp")
Вместо игр со счетчиком от 0 до 1000 - лучше использовать текущую дату-время или GUID.
На сколько правильно хранить файлы пользователей web-приложения (Spring) в каталогах по относительному адресу?
Всё зависит от общих принципов формирования адресов в приложении. Нужно делать единообразно.
Только не забывать, что если используются абсолютные ссылки, но должна быть константа или перемененная, указывающая на корень, от которого и формируются все ссылки приложения.
Есть ли какие-то альтернативные решения? Или как лучше всего хранить файлы пользователей?
Полно альтернатив. Зависит от задач и условий эксплуатации.
Можно раскидывать по датам (напр месяцам: 2023/12, 2024/01)
Можно по юзерам
Можно по теме
итд.
Можно также комбинировать способы.
Но тут важно понимать что большое кол-во файлов в каталоге может вызывать проблемы при некоторых условиях, поэтому стоит делать проверку кол-ва и распределять по другим каталогам.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Для хранения файлов пользователей существует несколько подходов, которые могут быть применены в зависимости от требований вашего проекта. Ниже приведены некоторые из наиболее распространенных методов хранения файлов пользователей:
1. Хранение файлов в файловой системе сервера:
Один из самых простых способов - это хранение файлов непосредственно на сервере. Вы можете создать специальную директорию на сервере, куда будут загружаться файлы пользователей. При этом важно обеспечить безопасность доступа к этой директории, чтобы избежать утечки конфиденциальных данных.
// Пример сохранения файла в файловой системе $uploadDir = 'uploads/'; $uploadFile = $uploadDir . basename($_FILES['file']['name']); if (move_uploaded_file($_FILES['file']['tmp_name'], $uploadFile)) { echo "Файл успешно загружен."; } else { echo "Ошибка при загрузке файла."; } |
// Пример сохранения файла в файловой системе $uploadDir = 'uploads/'; $uploadFile = $uploadDir . basename($_FILES['file']['name']); if (move_uploaded_file($_FILES['file']['tmp_name'], $uploadFile)) { echo "Файл успешно загружен."; } else { echo "Ошибка при загрузке файла."; }
2. Хранение файлов в базе данных:
Вместо хранения файлов на сервере, вы можете сохранять их в базе данных. Для этого вам потребуется создать таблицу, в которой будет храниться информация о файлах (например, название файла, тип файла, данные файла). Этот метод может быть удобен для резервного копирования данных и обеспечения целостности информации.
// Пример сохранения файла в базе данных $fileData = file_get_contents($_FILES['file']['tmp_name']); $fileName = $_FILES['file']['name']; $fileType = $_FILES['file']['type']; $sql = "INSERT INTO files (name, type, data) VALUES ('$fileName', '$fileType', '$fileData')"; |
// Пример сохранения файла в базе данных $fileData = file_get_contents($_FILES['file']['tmp_name']); $fileName = $_FILES['file']['name']; $fileType = $_FILES['file']['type']; $sql = "INSERT INTO files (name, type, data) VALUES ('$fileName', '$fileType', '$fileData')";
3. Использование облачного хранилища:
Другой вариант - это использование облачных хранилищ, таких как Amazon S3, Google Cloud Storage, Dropbox и другие. Эти сервисы предоставляют надежное и масштабируемое хранение файлов, а также удобные API для работы с ними.
// Пример загрузки файла в облачное хранилище Amazon S3 use Aws\S3\S3Client; $client = new S3Client([ 'version' => 'latest', 'region' => 'us-west-2', 'credentials' => [ 'key' => 'YOUR_AWS_ACCESS_KEY_ID', 'secret' => 'YOUR_AWS_SECRET_ACCESS_KEY', ], ]); $result = $client->putObject([ 'Bucket' => 'my-bucket', 'Key' => 'my-file.jpg', 'Body' => fopen($_FILES['file']['tmp_name'], 'rb'), ]); |
// Пример загрузки файла в облачное хранилище Amazon S3 use Aws\S3\S3Client; $client = new S3Client([ 'version' => 'latest', 'region' => 'us-west-2', 'credentials' => [ 'key' => 'YOUR_AWS_ACCESS_KEY_ID', 'secret' => 'YOUR_AWS_SECRET_ACCESS_KEY', ], ]); $result = $client->putObject([ 'Bucket' => 'my-bucket', 'Key' => 'my-file.jpg', 'Body' => fopen($_FILES['file']['tmp_name'], 'rb'), ]);
Выбор метода хранения файлов зависит от конкретных требований вашего проекта, таких как объем данных, доступность, безопасность и масштабируемость. При выборе решения важно учитывать все эти факторы, чтобы обеспечить эффективную и безопасную работу с файлами пользователей.

Для хранения файлов пользователей в веб-приложении есть несколько основных подходов, каждый из которых имеет свои преимущества и недостатки. Вот некоторые из наиболее распространенных способов:
1. Хранение файлов на сервере:
- Простота управления: файлы хранятся непосредственно на сервере, что облегчает доступ и управление ими.
- Безопасность: сервер имеет контроль над файлами и может регулировать доступ к ним.
- Производительность: доступ к файлам осуществляется быстрее, чем при использовании удаленного хранилища.
2. Хранение файлов в облачном хранилище:
- Гибкость и масштабируемость: облачные хранилища позволяют легко масштабировать хранимые файлы и обеспечивают гибкость в управлении ими.
- Доступность: файлы доступны из любой точки мира, что удобно для пользователей.
- Резервное копирование: облачные хранилища обычно предоставляют автоматическое резервное копирование данных.
3. Хранение файлов в базе данных:
- Целостность данных: файлы хранятся вместе с другими данными в базе данных, обеспечивая целостность и связь между ними.
- Управление доступом: базы данных обеспечивают механизмы для управления доступом к файлам.
- Сложность резервного копирования: резервное копирование больших файлов из базы данных может быть сложным и требовать дополнительных усилий.
Выбор конкретного способа хранения файлов зависит от конкретных требований вашего приложения. Например, если вам нужно обеспечить быстрый доступ к файлам и управлять ими централизованно, то хранение файлов на сервере может быть хорошим выбором. Если же вам важна гибкость и масштабируемость, то облачное хранилище может быть предпочтительным вариантом. Важно также учитывать вопросы безопасности и резервного копирования данных при принятии решения о способе хранения файлов пользователей.