Привествую всех!
Меня интересует такой вопрос. Есть сайт, взаимодействующий с БД. Что будет происходить при одновременном обращении к базе большого числа пользователей? И как с точки зрения php можно корректно организовать работу сайта с большой посещаемостью?

The_Aleksey, от ПХП тут ничего не зависит, тут надо думать о возможностях тюнинга СУБД.

То есть единственное, что я могу сделать - это оптимизировать запросы? А как БД относится к множественным одновременным обращениям?

Это уже зависит только от БД и ни от кого более. Mysql, к примеру, хоть под такое и заточен, но порой любит ронять индексы, системы с xml+xslt (текстовые базы) просто не могут справиться с критичными нагрузками. Итд.

Подправить конфиг СУБД вы, новерно, тоже можете. Почитать доки насчет того, как оно тюнингуется, к примеру, тоже никто не запрещает.

Можете дать ссылки на информацию, где я могу почитать?

нормально относится. Она для этого и придумывалась.

Если только вы хоть как-то намекнете, какую именно СУБД вы используете.

Пардон, с этого надо было начать)
MYSQL

The_Aleksey, http://dev.mysql.com/doc/refman/5.1/en/optimization.html

Добавлено через 7 минут и 44 секунды
И, да... Мускуль - штука порой малопредсказуемая. Сам я когда-то тюнинговал ее по вышеупомянутому мануалу. Там все нужное имеется. Но то, что именно вам понадобится, зависит только от того, что вы собираетесь получить в результате.

Спасибо, буду изучать!

Вот, простой скриптик для простой провеки качества настройки MySQL.
Ничего особенного, но, в целом, приятная вещь.
http://rackerhacker.com/mysqltuner/

The_Aleksey, можете снизить нагрузку на субд используя memcached

Это сообщение отредактировал(а) Glip - 25.7.2008, 00:10

Очень даже зависит! Точнее зависит от логики работы сайта, которую всегда можно направить в необходимое русло.

1. Всегда используем cache и перед тем, как обратиться к БД, смотрим, а нет ли у нас нужной инфы в кеше.

2. Показываем на сате информацию столько - сколько можно увидеть, но не больше. Для этого используем конструкцию LIMIT.

3. В БД обязательно нужно поставить индексы по числовым полям, которые участвуют в сравнениях, даже не представляете на сколко эт оповысит производительность.

4. Ну естественно БД должна быть спроектирована грамотно и должна быт ьприведена минимум к третей нормальной форме.

Artemon, а вот про нормализацию готов поспорить:

обратная сторона нормализации : необходимость join-ить таблицы, что под нагрузкой часто не приемлемо (хотя зависит от размера БД).

Иногда и охота расписать все по таблица, что бы было без избыточности, но приходится всю инфу сливать в одну таблицу..

У ненормализованной БД следующие минусы:

1. Большой размер, а как известно хостеры всегда ограничивают БД по размеру.
2. С разрастанием БД в ненормализованной базе становится вообще трудно что-либо понять.
3. Могут появляться ошибки, связанные с тем, что начнут частично меняться дублирующиеся записи, что может привести к тому, что наример на складе у товара цена 100р., а в заказе уже почему-то 200р.

По поводу Join, да это дополнительная нагрузка, но если мы используем индексы, то эта нагрузка минимальна.

По опыту скажу, что нормализовать нужно всегда!