Forum Webscript.Ru
Разное => Флейм => Тема начата: xRUSha от 22 Июня 2004, 17:29:45
-
Начальство поставило задачу - решить какую субд использовать для проекта, исходя из того, что расчетная нагрузка примерно 1 000 000 хитов в день, на скрипт, совершающий 30-40 запросов. Т.е. 30 000 000 заросов в день ~ 350 запросов в секуду. Никогда не сталкивался с таким трафиком (даже расчетным) раньше. Собственно поэтому решил спросить - имеет ли смысл отказыватся от MySQL. Если выбирать мускуль - какую версию предпочесть.
Но самый главный вопрос - какими критерими принято руководствоватся в моем случае. Мне дали достаточно времени на принятие этого решения, но оно должно быть грамотно аргументированно, а я даже не знаю, с какой стороны к нему подойти.
Язык реализации кстати тоже еще не выбрали, но скорей всего c++ (имеет ли смысл в этом случае отказыватся от пхп?)
Надеюсь на вашу помощь
-
Oracle | DB2 | на край Informix + C++
бизнес логику максимально возможно реализовать на стороне СУБД.
-
Oracle | DB2 | на край Informix + C++
бизнес логику максимально возможно реализовать на стороне СУБД.
А исходя из каких соображений выбор на эти субд пал?
Другими словами - как мне аргументировать выбор?
-
xRUSha
Возможности + производительность.
-
Читать о технологии кеширования.
Любая база при неумелом проектировании загнется на таких условиях.
-
ThE0ReTiC
Возможности + производительность.
как оценивают производительность. какие критерии оценки?
-
вот нашел хорошую статью на эту тему - может кому будет интересно
http://www.pcmag.ru/?ID=286006
-
xRUSha:
Начальство поставило задачу - решить какую субд использовать для проекта, исходя из того, что расчетная нагрузка примерно 1 000 000 хитов в день, на скрипт, совершающий 30-40 запросов. Т.е. 30 000 000 заросов в день ~ 350 запросов в секуду. Никогда не сталкивался с таким трафиком (даже расчетным) раньше. Собственно поэтому решил спросить - имеет ли смысл отказыватся от MySQL. Если выбирать мускуль - какую версию предпочесть.
Вот на webscript за последние 48 дней в СРЕДНЕМ 5 запросов в секунду, в пик 50, потянет увелечение в 3-4 раза, ничего не кешировано и не оптимизировано. А уж если бы я купил себе сервачок, то твои параметры он потянул бы, но конечно многое зависит от приложения. Кстати что это за сайтик с милионом хитов в день это всего лишь 60% от ВСЕГО Яндекса.
-
Кстати что это за сайтик с милионом хитов в день это всего лишь 60% от ВСЕГО Яндекса.
не сайтик банерокрутилка. а трафик расчетный - и не я его расчитывал. а сервачок есть.
так значит мускуль потянет эти параметры?
-
Сервачек - это фамилия админа?
-
xRUSha
NAS:
но конечно многое зависит от приложения.
С баннерокрутилкой все несколько не так и у меня к сожалению опыта в этом вопросе нет.
-
xRUSha
1. Дай полную раскладку сервака... (ОС, Веб сервер, Канал, и.т.д.)
2. MySQL - скорее всего будет отдыхать....
3. 350 запросов в секуду это придел?
4. но скорей всего c++
это правильно... если даже не будет устраивать скорость... подрубишь модулем к апачу...
P.S. (имеет ли смысл в этом случае отказыватся от пхп?)
ДА!
-
интересно.
а никто не задался вопросом, откуда в скрипте, показывающем баннер, 30-40 запросов?!
-
RomikChef
Видать сложный банер... :)
-
commander
TIFF 1024x768
-
, и таких 40 штук.
-
hanslinger
[off]
в секунду :)
[/off]
-
издеваитесь...
30 запросов это в принципе с потолка, но бизнес логика там должна быть очень непростой, так что ориентироватся лучше на худшее. Хотя основная нагрузка ляжет на одну cgiну а она я думаю будет просто обращатся к хранимой процедуре и возвращать результат ее работы. Соответственно еще одно требование к базе - хранимые процедуры и триггеры.
commander
1. Дай полную раскладку сервака... (ОС, Веб сервер, Канал, и.т.д.)
Сервер выделенный - соответственно выбор оси, веб-сервера, субд, вопрос решаемый просто. Канал достаточный (этим вопросом не я занимаюсь). Ось - думаю linux или фря, этот вопрос буду решать немного пожже.
3. 350 запросов в секуду это придел?
думаю нет
-
xRUSha:
Хотя основная нагрузка ляжет на одну cgiну
нагрузку надо переносить в СУБД.
соответственно под фрю нормально работает только PostreSQL
все остальное сертифицированно только под Линухи.
Oracle конечно заводится на фре, но я бы например не рискнул ставить такую связку в продакшн.
возможно имеет смысл смотреть на Solaris+Oracle
-
нагрузку надо переносить в СУБД.
я так и думал
основная нагрузка ляжет на одну cgiну а она я думаю будет просто обращатся к хранимой процедуре и возвращать результат ее работы
-
Сервер выделенный - соответственно выбор оси, веб-сервера, субд, вопрос решаемый просто. Канал достаточный (этим вопросом не я занимаюсь). Ось - думаю linux или фря, этот вопрос буду решать немного пожже.
1. Советую этот вопрос решить изначально!
2. Очень рекомендую FreeBSD, а не Linux.
3. Веб сервер Апач, до 500 единовременных подключений при определенной настройке...
нагрузку надо переносить в СУБД.
не думаю... Лучше на сишный модуль апача. (написанный самим).
скорость в 100/200 раз быстрее чем тот же скрипт под CGI. БД в твоем случае не стоит сильно дергать... (это может очень печально кончиться..)
-
commander:
не думаю...
а попытаться?
commander:
на сишный модуль апача
бизнес-логику надо максимально сделать на стороне СУБД.
Ибо это будет быстрее, чем обработка полусырых результатов даже модулем.
-
commander:
рекомендую FreeBSD
сначала определиться с СУБД.
Под Фрю есть только Postgres.
Запуск всего остального - извращение, допустимое исключительно в образовательных целя.
-
ThE0ReTiC
а попытаться?
не модо иронии...
Ибо это будет быстрее, чем обработка полусырых результатов даже модулем.
а не предлогаю обрабатывать полусырые результаты... я пердостерегаю от написания безумных функций!
сначала определиться с СУБД. Под Фрю есть только Postgres.
Как на счет индексов? + обработку результатов модулем...
Да и потом, чем тебя не устраивает Postgres?
-
ThE0ReTiC
http://www.freebsd.org/commercial/software.html#Altera
-
commander:
чем тебя не устраивает Postgres?
Меня - всем. Ничего не имею против.
Она может не справиться с нагрузкой...
commander:
обработку результатов модулем
само собой.
commander:
Как на счет индексов?
что насчет индексов?
индексы не панацея и могут даже способствовать падению производительности.
-
http://www.freebsd.org/commercial/software.html#InterBase
-
commander
Нервно курит в углу.
Postgres 100 очков вперед даст.
Это очередная попытка сделать конфету и Борландовского недоразумения.
-
что насчет индексов?
индексы не панацея и могут даже способствовать падению производительности.
Все дело в руках...
Она может не справиться с нагрузкой...
только лишь предположение...?
-
commander
Да.
тестов не проводил. Не люблю Interbase. Наелся в свое время.
Кстати она есть только официально под Шапку, Сусь и Соляру (v 7.1) :)
-
[off]
вообще это все флейм.
предлагаю выбор оставить на усмотрение автора топика.
Проодлжение возможно приватно.
[/off]
-
[OFF]да мужики, нафлеймили вы не мало. Жаль меня небыло, поучаствовал бы.
с тем что топик продолжать смысла нет согласен.
с выбором я уже определился, - linux (думаю red hat 9) и постгрес. с тем что бизнеслогику нужно перенести в базу согласен, что пытался сказать еще вчера.
[/OFF]
-
xRUSha
linux (думаю red hat 9)
большая ошибка! если уж ты выбраешь PostgreSQL FreeBSD на много лучше!!!!
с тем что бизнеслогику нужно перенести в базу согласен
спорный ворпос... но я бы так делать не стал...
-
commander:
PostgreSQL FreeBSD на много лучше!!!!
согласен
commander:
но я бы так делать не стал...
несогласен
-
большая ошибка! если уж ты выбраешь PostgreSQL FreeBSD на много лучше!!!!
почему?
-
commander:
большая ошибка! если уж ты выбраешь PostgreSQL FreeBSD на много лучше!!!!
а давай будем свои предположения ссылками подкреплять.
мне (уверен, не только мне) очень интересно посмотреть на характеристики постгреса на линуксе и фре.
[OFF]для религиозных войн у нас есть соответствующий раздел[/OFF]
-
мне нравится этот топик
хрюша, который ни бельмеса не смыслит в веб-девелопменте, задает вопрос высосав его из пальца, и не понимая вообще ничего из того, что он спрашивает.
комманндер, который симыслит не больше, начинает с умным видом давать советы..
расслабьтесь, горячие финские парни.
лимон хитов превратится в десяток тысяч, а 40 запросов - в 1.
и удовлетворит в реальности нашего кремлевского мечтателя - дбм.
-
Так....поехали во флейм....
Эээээ....DB2 рулит!:))
-
Chs:
....DB2 рулит
ага.
особенно если она на каком-нить сервачке (http://www-1.ibm.com/servers/eserver/zseries/900.html) работает.
спору нет :)
-
RomikChef
Ты как всегда в своем репертуаре... но на тебя обижаться даже как-то глупо... :)
NeoNox
Я имел в ввиду, не то что постгрес быстрее работает на фре, а то что сервак лучше на фре собирать....
Пример пожалуйта:
1. мил. обращений в день сервак на FreeBSD прекрасно работает... :) RedHat не выдержал бы такой нагрузки...
-
commander:
RedHat не выдержал бы такой нагрузки
имхо
/dev/hands
надо правильно монтировать.
-
commander
у тебя опять одни только слова.
И еще, что-бы не офтоп - http://www.potentialtech.com/wmoran/postgresql.php
-
NeoNox
Однако UFS2 побыстрее будет. Если без ACL делать :)
-
ThE0ReTiC да без вопросов :)
оптимайзить сервер это вопрос компетенции далеко не программеров.
и базу не они выбирают.
а угробить любую платформу программер сможет запросто, с этим ты спорить не будеш? ;)
-
неа.
я не идиот :)
-
И я не буду.
ThE0ReTiC
Я больше к таким привык - http://www-1.ibm.com/servers/eserver/iseries/hardware/medlarge/870/index.html
-
Chs
тоже внушаеть :)
-
http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/pSeries/high_end/690.html
весчь :-)))
-
Britva
Chs
маньяки :)