Привествую всех!
Меня интересует такой вопрос. Есть сайт, взаимодействующий с БД. Что будет происходить при одновременном обращении к базе большого числа пользователей? И как с точки зрения 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, да это дополнительная нагрузка, но если мы используем индексы, то эта нагрузка минимальна.

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

Artemon, денормализация это не способ проектирования а костыль который иногда необходимо ставить.

Простой пример из жизни.
Две таблицы.


Задача:
На входе список id пользователей (в стеднем 50 значений). Получить rs имя пользователя, ID последнего локейшина.

Как будете решать без денормализации и на каком кол-ве данных вы почувствуете СУЩЕСТВЕННУЮ разницу по сравнению с денормализованым вариантом (всего-то добавить lat_location_id в user)

solenko,  вы немного путаетесь в терминах, мне кажется.
нормализация - приведение, к нормальной форме (их там штук 9, но обчыно ограничеваются 4ой.) Разбиение на таблицы, удаление дублирования
денормализация - обратный процесс, все в одну таблицу

по поводу вашей схемы БД. а пользователи и локейшены как связаны ? у вас не написано

этим ты добьешься связи между двумя таблицами, вид связи будет один ко многим: locations -> users

Правильно, отношение таблиц задал, и стало возможно выбирать записи из таблицы users по условию lat_location_id = locations.id
И что ты этим хотел сказать ?

sir_nuf_nuf, Artemon, упс. Не дописал немного естественно
стартовый вариант:


денормализованный вариант


Добавлено через 2 минуты и 3 секунды
Естесно user -> location связь один -> многим

Твой пример не показывает никаких приимуществ денормализованной БД, вернее он вообще ничего не показывает, привел 2 таблицы и поробуй догадайся в чем фишка.

Это сообщение отредактировал(а) Artemon - 30.8.2008, 10:35

Artemon, думал что поймете по структуре таблицы, на раз нет...
1. Есть пользователи. Данные о них хранятся в таблице users. В нашем примере это уникальный идентификатор (id int primary key) и имя пользователя (name varchar(255))
2. В таблице locations хранятся данные о местоположении пользователей. В нашем примере это уникальный идентификатор местоположения (id int primary key), id пользователя (user_id int references users(id)) и время, когда это местоположение было сохранено (set_date datetime). 
3. Таблица users связана с locations связью типа один ко мноким по полям users.id = locations.user_id

Необходимо, имея список id пользователей (в нашем примере это просто список, в реальности это список друзей), получить результат запроса, который бы содержал id пользователя, имя пользователя, id последнего местоположения (последнее опрделяестя по максимальной set_date. Можно использовать и максимальный locations.id, хоть это не логично). Т.е. в итоге нужно получить rs с полями:
users.id, users.name, locations.id

Если вам еще что-то непонятно в постановке задачи, с удовольствием отвечу на все вопросы.

solenko,  ваш запрос на последнюю локацию










Это сообщение отредактировал(а) sir_nuf_nuf - 2.9.2008, 00:48

sir_nuf_nuf, теперь дописываем ноликов к количеству данных в таблице... 
Торможение я заметил на ~5000 пользователей, порядка 10^6 locations. Вот тогда уже и денормализовал тблицу ) 
А до этого работал джойн на себя, что было немного быстрее вложенных запросов

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