Интересует технология создания системы по загрузке и размещения видео на сайте. Хотя бы какие-нибудь ссылки или названия технологий. Т.е. мне надо сделать такую штуку на подобии как youtube.com. Посоветуйте пожалуйста.
Не вижу там ничего сложного, чтобы кишка лопнула. Единственная проблема - воспроизведение видео онлайн и все. И то, думаю, есть стандартные методы, которые погуглить стоит. А загрузка идет обычных файлов. Работа файл+БД и все. Ничего сложного.
Если есть деньги, то для этого потребуется как минимум свой сервак. Воспроизведение - это Flash, недавно сам плеер писал. А вот с загрузкой тут проблемка, из-за которой как раз и требуется свой сервак. Т.к. flash воспроизводит только свой формат (FLV), загруженные файлы требуется конвентировать на стороне сервера. Если конечно заливаться будут только FLV файлы, то тут ничего сложного нету, только хороший хост...
А нет средств воспроизведения avi хотя бы? Я не специалист во flash, поэтому, возможно, вопрос может показаться абсурдным. Вот воспроизведение звука на странице делается вообще стандартно: HTML: <embed src="http://music/файл.mp3" hidden="true" autostart="true" loop="false" volume="23" pluginspage="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab"> Может и на другие форматы есть что-то подобное? Еще вопрос сразу: конвертирование делается так понимаю не в реальном времени?
Это все тот-же Flash. Почитай про HTML 5 версии, но он не скоро в публичное пользование войдет и реализован щас вроде только под Оперой. Конвертирование должно делаться на стороне сервера, а там уже в зависимости от программы.
скажи ка нам друг, ориентировочную нагрузку на сайт? - кол-во пользоыателей - пользователей онлайн - кол-во видеороликов - размеры видео - кол-во одновременно просматриваемых роликов отсюда и попляшем
нет. не в реальном. там демон висит и смотрит, если появились новые файлы, то конвертит их и пишет в базу что они отконверчеры и удаляет источники.
440Hz Все эти параметры несут нагрузку на сервер и имеющийся софт на нем. Не вижу разницы в структуре кода для 1000 человек и 1 000 000 человек. в любом случае программировать вы будете одинаково. Если ошибаюсь, то объясните на конкретных примерах или аспектах.
гыгыгы тогда бы на F1 все катались на жигулях, а не точили движки и все остальное, а так машина как машина. только стоит несколько лимонов и отпидарасено в ней все так, что придраться не к чему. улавливаешь суть?
я те как пример скажу. в графических движках вместо того что бы делать циклы, как поступили бы "те кто не видят разницы", пишут совсем по другому. например готовят машинный код и потом разворачивают его в памяти и передают туда управление. для понимания выглядит так: обычный код: for($i=0;$i<3;$i++) { $a[$i] = $i; } код для хайлоад $a[0] = 0; $a[1] = 1; $a[2] = 2; другая проблема - хранение и обработка больших объемов. если все загнать в одну таблицу и делать там выборки, то такие проекты как "счетчики" загнулись бы сразу.
когда у тебя смотрят ролик 5 человек, то серверу похрен, а когда ОДНОВРЕМЕННО ролик качают 1000 человек, то посчитай нагрузку на канал и подумай, сможет ли сервер отдать такое всем сразу? p.s. с учетом что апач, к примеру, может держать сразу только 255 коннектов, то это у тебя положит сервер намертво. p.p.s одна из атак DOS на апач именно в этом. делают 256 коннектов и держат из 30 сек., а потом пеерконнекчиваются. в результате не работающий сервер. мысля понятна? так что , если писать для 1000000 как для 100, то это означает - иметь пустую башку и много самомнения но мало опыта и нежелание сесть и посчитать.
440Hz Для начала читайте внимательнее то, о чем я писал! А именно: Вы об этом и утверждаете. Поэтому необходимо больше внимания уделять имеющемуся софту и серверу!
440Hz Это единственный ваш пример, который можно взять во внимание с учетом темы. Вот с этим полностью согласен. Вот только имея цикл динамического максимума, так не сделаешь. В этом и возникает много проблем. Сейчас как раз пишу проект на хайлоад. Если у вас есть опыт и примеры конкретные, то приму во внимание! Кстати, при разработке учитываю и просчитываю примерные нагрузки, поэтому делаю распределение между БД и файловой системой.
поржал. Откуда у него опыт? Так, всего лишь десяток серверов в кластере работают. Куда ему до тебя...
мой опыт мне говорит, что КАЖДУЮ отдельную задачу нужно рассматривать ОТДЕЛЬНО и решения принимать исходя из конкретных постановок, нагрузок и решений. в частности с видео. тут одна из задач упрется в две вещи: 1. объем хранимой инфы 2. кол-во одновременных просмотров. так вот, архитектурные решения сильно будут отличаться в зависимости от нагрузки на сайт (НЕ СЕРВЕР). итак. какая планируемая нагрузка? p.s. только не надоговорить о масштабируемых решениях. масштабировать до бесконечности тоже не получится.
440Hz Я и говорю, что прежде всего нагрузка будет на сервер! Под сервером подразумеваю не apache, а само железо и совокупность программного обеспечения, т.е. комп в целом. Пока вижу разницу в программировании в том, что следует разпараллеливать хранение данных. Причем не из-за того, что не выдержит БД по одновременному подключению (можно и Oracle засунуть при необходимости, а MS SQL Server поддерживает до 20 одновременных подключений, что достаточно при посещении 1000000 человек в сутки если брать средний расчет: 1000000/86400 сек = 11 подключений в сек, при этом запрос явно происходит гораздо менее секунды, т.е. запас имеется приличный), а просто потому, что размер данных типа INT для ID будет переполнен в ближайшие сроки при больших объемах, скажем почта или счетчик посещаемости.
=) а MySQL сколько скажешь. у меня например 1024 стоит. это как раз архитектурное решение, а не програмное. это ГДЕ??? Ну-ка расскажи... как мы тут уже выяснили с Флоппиком, php-cgi прикрасно работает с mysql_pconnect, что я отлично проверил на боевых серверах. ниче. скоро начнешь видеть и другие стороны. главное по сторонам смотреть... =)
Если не можешь привести конкретных примеров, о которых я писал и которые готов выслушать и принять, то не стоит распыляться словами знатока! Под архитектурным понимаю как раз таки совокупность программно-аппаратных средств сервера! Распараллеливание - решение на уровне проектирования и реализации, а следовательно программное. В настройках! Не смеши! Любой продукт не прыгнет выше своей головы. В данном случае будет реализовано максимальное количество подключений одновременных, но не 1024. Если бы все было так просто, то и отпал бы вопрос в понятиях хайлоад и обычных проектах! А количество подключений в 20 - это официальные характеристики. Посмотри-ка максимальный размер этого типа данных и вопросы отпадут сами собой! А вообще такие вещи знать бы надо таким заядлым и квалифицированным программистам!
klerick, я тоже ржу с тебя, это даже не просто смех, а отчаянный смех в перемешку с мыслями "надо же быть таким......"
Так считать нельзя, нагрузка не может быть равномерно распределена в течении дня, будут пики и будут провалы.