bsdi4Ребят ну совсем уж Офф Топ пошел((Извините за оффтопик, но у нас с MBG к сожалению уже не впервые диалог уходит в сторону .

bsdi4: ... хранение файликов в Бд размером от 20мб до 50мб ...
MBG: ... А если будет 1000 запросов в секунду и выше? ...
bsdi4: ... сядь и возьми калькулятор и начни считать )) ...

Меня поражают подобные пальцевания не по теме. Действительно, возьмем калькулятор. Оценим необходимую толщину канала. 1000[1/сек] * 20[Мбайт] ~ 100[Гбит/сек]. Сотни гигабит в секунду! Так какой, уважаемый MBG, в этом проекте может быть разговор о 1000 запросов в секунду?

У нас круто - 1000 запросов в секунду! Откуда 1000? Ну откуда-нибудь когда-нибудь, во время пиковой нагрузки... Берем калькулятор: 1000[запрос/сек] / 300[польз] = 3 [запроса в секунду от каждого пользователя], подозрительно активные пользователи получаются. Но уж по крайней мере у нас 150 запросов в секунду! Откуда 150? Да вместо того, чтобы организовать ситему нотификации через нормальный IM-протокол, сделали на клиетах автоматический релоад каждые две секунды. Нет-нет, это не ошибка проектирования. Это работающий высоконагруженный сервис! И не важно, что нагрузку создали сами проектировщики кривыми ручками/мозгами.

Еще раз сорри за оффтопик.

bsdi4Может всетаки чего потеме а? И перейдем к PostgreSQL и проблеме хранения большого количество бинарных данных а?По теме многие высказали доводы и мнения. Конкретно с такой задачей возможно никто из присутствующих на форуме не сталкивался. Например минусы "хранения большого кол-ва небольших файлов в ФС", с которыми мы столкнулись на практике, я привел. Задача не в точности ваша, но смежная. Дальше наверное остается только Вам делать выводы и выбирать решение. Я бы наверное выбрал хранение фалов в ФС, потому что побаиваюсь базы объемом 1Тб, причем с длинными строками, имхо Shweik точно охарактеризовал ситуцию "такое поле - просто мёртвый балласт".

bsdi4Так ребят, хорошо. Поставлю вопрос иначе 4Gb Рамы хватит для нормальноый полноценой работы PostgreSQL с 700Gb Базой?Вопрос слишком общий. Зависит от требований к базе по характеру запросов и их скорости выполнения.

Например если 1) база работает в основном на выборки, 2) в вашей предметной области соблюдается закон 20/80, то есть 80% пользователей интересует 20% информации. То получается что 4Gb/700Gb=0.5% информации закачанной в кэш оперативной памяти удовлетворят, скажем, 5% пользователей. То есть для большинства пользователей база будет тянуть данные с HDD, и скорее всего именно диски будут узким местом в этой системе.

MBGХорошо считаете. Если _все_ запросы только на получение файлов (т.е. нет никакого веб-интерфейса с разделами, описанием файликов и т.п.)автор топика задал вопрос о работе с большими файлами, а не о "веб-интерфейсе с разделами, описанием файликов и т.п."

MBGА на нормальном сервере с библиотекой запросов на просмотр страниц на два порядка больше, чем на закачку.не могу сказать про "нормальный сервер с библиотекой", но например у нас кол-во поисковых запросов составляет примерно четверть от общего числа обращений к серверу. разница не на два порядка...

MBG LeXa NalBatОценим необходимую толщину канала. 1000[1/сек] * 20[Мбайт] ~ 100[Гбит/сек].Далее, с какого перепугу вы полагаете, что все клиенты будут скачивать файлы за 1 секунду? А если чел с модема 3 часа файл тянет, и таких челов 10 000?скорость соединения с клиентом не влияет на оценку ширины требуемого канала!

если пользователь с модема тянет 20Мб файл 3 часа, значит скорость соединения с ним равна 20[Мбайт] / 3[час] = 20*1000*1000*8[бит] / 3*3600[сек] ~ 15[Кбит/сек]

для скорости поступления таких запросов от подобных юзеров равной 1000[запросов в секунду] получаем, что за три часа их накопится 1000 * 3 * 3600 ~= 10 миллионов. при этом каждую секунду будут открываться 1000 новых коннектов к серверу и закрываться другие 1000 старых, которые уже отработали свои три часа и скачали файл. то есть в каждый момент времени открыто 10 миллионов коннектов.

получается, что сервер должен отдавать данные со скоростью 10млн * 15[Кбит/сек] = 150[Гбит/сек] ~ 100[Гбит/сек].

скорость соединения с клиентом не влияет на оценку ширины требуемого канала!

MBGВы говорите про _постоянное_ соединение.нет. например про клиентское приложение, которое, будучи запущенным на рабочей станции пользователя, слушает порт.

PS: bsdi4, сорри за офф :-)

MBGА на нормальном сервере с библиотекой запросов на просмотр страниц на два порядка больше, чем на закачку.очередной оффтопик... не могу удержаться... ехал с работы домой, пришло озарение. это же золотая жила! какое огромное кол-во рекламы можно впихнуть юзеру, пока он будет 100 раз кликать по разным страницам, прежде чем получить то, ради чего зашел на сайт - скачать книгу. только вот боюсь, не найдется в природе ни одного такого терпеливого пользователя. думаю, если юзер за 3-10 кликов по сайту не получает того, ради чего пришел, он ... уходит. :-( откуда вы берете ваши оценки? "1000 запорсов в секунду", "два порядка". варианты ответов: а) любите круглые цифры, б) с луны.

MBG LeXa NalBatдля скорости поступления таких запросов от подобных юзеров равной 1000[запросов в секунду] ..."для скорости поступления" - это вы к чему? Есть тысяча юзверей, их запросы обрабатываются три часа, так вот и будут у вас 3 часа висеть эти 1000 подключений к веб-серверу, подключения к базе данных и запущенные скрипты. То есть каждую секунду обрабатывается 1000 запросов, в следующую секунду могут обрабатываться эти же запросы или новые, потребление ресурсов то же самое.да нет же! что означает фраза "сервер обрабатывает N запросов в секунду"? что каждую секунду к серверу приходит N новых запросов, каждый из этих запросов сервер успешно обрабатывает и отдает ответ клиенту за время T (не равное 1 секунде!!!). при этом в каждый момент времени сервер обрабатывает и отдает ответ одновременно M клиентам, где M = N * T.

мы говорим (вы начали говорить: "А если будет 1000 запросов в секунду и выше?") о количестве запросов в секунду! а не о количестве одновременно обрабатываемых запросов. это разные вещи, не путайте.

MBGЯ говорил про количество обрабатываемых запросов в секундунет. вы говорили про количество одновременно обрабатываемых запросов в некоторый момент времени.

заметьте, в МОМЕНТ времени, а не в ПЕРИОД времени (каковым является секунда). формулируйте точнее.

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

MBGЗачастую запросы обрабатываются настолько быстро, что это одно и то же.Пример:
сервису поступает 10 запорсов в секунду: N = 10 [зап/сек]
каждый запорс обрабатывается "быстро", за одну десятую секунды: T = 0.1 [сек]
тогда в каждый момент времни сервис обрабатывает один запрос: M = N * T = 1 [зап]

N = 10 [зап/сек] не равно M = 1 [зап] ни по значению, ни по размерности!

MBGНо для закачки больших файлов это не так.А "как это" для закачки больших файлов? Как предлагаете оценивать в этом случае? Вместо простой формулы M=N*T, применимой во всех случаях, для быстрых, медленных запросов,.. :-(