Как же сторадж файлов забацать...

У меня опять приступ “хоцца закосить под гугл”. Дать всем много аттачев и не облажаться 😃

Cитуевина такова - дисковое место “по идее” дешевое, если устраивают простецкие процессоры и медленные диски. Вона, почти терабайт в страйпе на хорошей площадке, за 50 евриков:

www.hetzner.de/…/rootserver-produktmatrix/

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

По идее, если отбросить аттачменты, то:

• Памяти хватает. База влазит целиком (1-2 гига). На случай, если “будет расти” - дык самсунг уже начал продавать планки DDR3 по 8-16 гигов. Так что с этой стороны жопы сто пудов не ожидается. Главное, что репликаций не понадобится и mysql будет на 1 машине еще много-много лет.
• Процессоры - в принципе тоже нормально. PHP-пул офигенно легко масштабируется, если все в пределах одного датацентра. В самом хреновом случае - просадка по времени отклика сервера, но не больше. А пока даже 50% запаса на единственном сервере вполне имеется. Главное большими файлами связку серверов по сети не долбить, и ни каких проблем.
• Дисковые операции - если не отвлекаться на специальные случаи, то в top бодро показывается wa 1-2%. В смысле - база в памяти, гимору нема.

И вот имеем “не в рот какую большую” проблему - КАК (?) обслуживать аттачи отдельно, но при этом:

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

Ну ДОПУСТИМ можно второй раз всех прокинуть с абсолютными путями к картинкам 😃 . Изобрести аццкий формат с кучей поддоменов (по сервакам), путями в виде хеша, и поклясться мамой больше никогда его не менять. Тогда возникает несколько вопросов:

• Как сделать, чтобы если “покласть” сервак img58.rcdesign.ru, то статические ссылки все равно обслуживались с других. С учетом того, что серверы могут быть в разных датацентрах.
• По какому алгоритму генерировать ссылки на картинки, чтобы они обеспечивали правильную заполняемость (с учетом нагрузки) серверов, и не долбили центральный мастер.
• На чем делать распределенное хранилище в плане файловой системы. Чтобы картинки файлы дублировались автоматом, но не на все ноды, а только на необходимые. И чтобы можно было делать бакапы не на уровне файловой системы, а на уровне нод.
• Как вообще синхронизировать (реплицировать) данные о картинках на уровне базы данных. Все-таки каждая нода должна знать, чего на ней находится, и куда сходить, если вдруг не нарыли.

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

Задачка интересная. Через год пышным цветом распустится could computing, и было бы весьма актуально аккуратно напилить файлохранилище кусками скажем по 100-гигабайтным виртуальным серверам, которые можно без проблем задвигать куда душа пожелает.

PS. Как же все-таки хорошо, что на MVC-архитектуру vBulletin довольно легко ложится большинство модификаций. Ну а дровосекам из IPB, пользуясь случаем, в очередной раз шлю луч ненависти и кровавого поноса. Определенно, 10 килобаксов оказалось не слишком высокой ценой, чтобы поменять их говнописный софт на воблу.