Назар Булавко: В любом случае (хоть дома, хоть на рабочем месте) работа наугад не даёт полного понимания действий: поменяв вслепую что-то одно, можно повлиять и на другое и не обратить на это внимания, хотя оно того и стоит. Поэтому действия в любом случае есть смысл сопровождать чтением документации - что именно меняется. Это уже будет не вслепую.
Назар Булавко: Если Вы, едя по плотно занятой трассе со скоростью 100 км/ч, закроете глаза, то обязательно куда-нибудь впечатаетесь. Если Вы начнёте наугад менять настройки в сложной системе, то непременно что-то сломаете. И хорошо, если за такие тренировки с работы не выпрут. Поэтому изучать надо сначала и только потом начинать что-то делать. Неплохо иметь тестовую среду для проб, но возможно это не везде и не всегда.
Александр Санеев: Я не знаю Ваших условий и не могу сказать, какой именно вариант будет оптимальным. Своё мнение пишу по своему опыту работы с web-сервисами средней нагруженности (когда одного сервера уже не хватает по нагрузке на сервер или канал его связи с сетью, но до уровня youtube и даже rutube и их количества серверов ещё далековато), но с видеохостингами дела сам не имел.
А имя файла можно держать не в файловой системе, а в базе. Для файловой системы никто не мешает сгенерить уникальное имя файла (например, в виде UUID или даже id автоинкрементного поля в таблице БД) и записать его в ту же строку таблицы, что и оригинальное, только в другое поле.
Александр Санеев: Организовываете всё Вы - Вам и решать. Никто не мешает оригинальное имя держать там же в базе, а файл заливать в каталог под другим (записанным в той же строке таблицы).
У одной папки проблема в том, что эти видео из папки серверу придётся неоднократно считывать, каждый раз нагружая один и тот же каталог. Пока файлов там мало, это проблемы не составляет. Но на множестве (сотни тысяч и более) файлов в одном каталоге можно получить тормоза (особенно при бэкапе/репликации) и сложности с масштабированием. Чтобы заблаговременно иметь возможности для реакции на проблемы (а также на исчерпание свободного места в файловой системе), в базе можно иметь поле, указывающее на каталог или даже сервер (может, даже и не один, если предполагается высокая нагрузка) для хранения конкретного видео, а при заливке, если начинаются сложности, админу можно будет просто переключить заливку на новый каталог или сервер, оставив старый в read-only. И затем, если надо, добавлять каталоги, переносить их на другие серверы и таким образом масштабироваться.
Игорь Самохин: Страшно оно много чего, но, если надо, то что делать. Ну держите данные в ОЗУ, а после передачи стирайте, чтобы до них проблематично было добраться.
Игорь Самохин: Эти ключи придётся всем раздать, чтобы пользователи могли шифровать и расшифровывать сообщения. И шифровать придётся для каждого получателя в чате ключом этого получателя, иначе он сообщение не сможет прочитать.