Ну так я выше и написал, когда, по какой причине и чем заменили базу. ))))
Я ни разу не сказал, что не надо использовать базу, говорил только о том, что БД узкое место веб-проектов. И да, в автомобиле часто движок узкое место - из-за него автомобиль не может ехать быстрее и/или быстрее разгоняться ;)
На БД у меня завязанно только хранение данных. Логика в коде. А у Вас иначе? ))
По поводу канала - я не говорил о его расширении, говорил о снижении нагрузки на него. Не надо перевирать слова ;). Так же и с базой - часто надо не расширять ресурсы под нее, а изменить логику приложения, разгрузив БД. Разве я не это говорил выше? )
100 раз на 1 страницу?! Да Вы, сударь, ни разу не писали бизнес-приложения, но рассуждаете о нагрузках? o_O Я могу показать Вам приложение, в котором на одну страницу идет около 3000 запросов к базе и еще больше у другим компонентам. При этом, генерация этой самой страницы занимает 0.0055 сек.
Проблема БД - долгая обработка запроса к ней. Долгая - понятие относительное. Для какого-то запроса это может быть 1 сек, а для какого-то и 0.0001 - долго. И перенеся логику этих запросов на другую технологию (да хоть на кеширование) можно ускорить приложение в десятки/сотни/тысячи раз. Именно это и называется "узкое место" - то место, которое занимает самые большие ресурсы (включая временные) на обработку запроса.
История из практики (которую и Вы можете у себя проверить): заменив поиск данных с sql-запроса на сфинкс получите ускорение поиска по сайту раз в 100. И это при том, что меняется только формат индексирования (даже не хранения - данные так же остаются в БД). Разве в данном случае узкое место не БД? )))))
Во-первых, у меня самого достаточно большой опыт построения и обслуживания веб-проектов. Во-вторых, основное в конференциях и семинарах не готовые решения, а общение. И решение проблем с БД разные: шардинг, партиции, кеширование и пр. Я уже выше писал про это.
Но Вы так и не ответили на вопрос: на чем основывается утверждение, идущее вопреки мировой статистике, что БД не может быть узким местом? Навскидку, могу предположить пару-тройку вариантов:
1. Узкий канал, который забивается быстрее, чем падает база. Gzip+браузерное кеширование+cdn легко решают подобную проблему.
2. Слабый фронтенд, не успевающий обслужить поток входящих соединений. Nginx, при правильной настройке, решит и эту проблему.
3. Сложные вычисления в скриптах. Тут проблема в неправильной архитектуре.
Все выше основано на общении с создателями довольно сложных и масштабных проектов + личный опыт. Именно эти факторы позволяют мне утверждать, что в большинстве случаев проблема ТОЛЬКО в БД. А Вы на каких данных утверждаете обратное? Мне действительно очень интересно, т.к. это позволит узнать что-то новое, что-то, что я возможно упустил в своей практике.
Бредово оспаривать это... Я посетил достаточно много конференций и семинаров, посвященных стартапам и веб-разработкам и везде говорили именно о том, что самое узкое место БД. Я считаю, что это большая статистика. А Вы на чем основываетесь, утверждая, что БД не может быть узким местом? На своем сервере? ))
Текущая моя работа: 400-500 уников онлайн круглосуточно. При этом 20Мб канала занимают постоянно. И схема выше, когда данные готовятся еще до появления пользователя, именно с него. Да, "большая нагрузка" - понятие относительное, полностью согласен.
Ну так в посте никто полностью не отказывался от бд, там вариант разгрузки бд за счет стороннего инструмента. А сфинкс может отлично работать и с файлами ;)
Все-же на это отвечу и буду считать диалог закрытым )))
А если так:
1. начало генерации
while (..)
{
2. запросы в БД\к файлам
3. генерация по результатам
4. (опционально) запросы (ы) к запрашивающему ЮА
}
endwhile;
5. запрос страницы юзером
6. конечный результат генерации
7. Обработка сервером для выдачи (gzip например)
Да, только не всю систему, а некоторую ее часть (процентов 40 системы). На одном сервере, на одних пользователях и пр. ФС победила. Но ведь это не важно, верно? ))))
Да и у вас ФС победит, если захотеть. Другое дело - поклонение одному направлению, с этим трудно бороться.
Может. При кривых ручках ;)
Не, нельзя так считать. Иначе придется считать, что запрос данных из базы начинается до того, как пришел юзер (при использовании pconnect). Да и вообще, данные из базы могут запрашиваться отдельно от генерации страниц (например, демон заранее генерирует страницы) ;). Так что "запущено" и "бред" надо употреблять аккуратнее ;)
Стоп-стоп-стоп... Мы про какие винты говорим? Сата? Скази? Ссд? Это во первых. Во-вторых, кто говорит, что надо использовать именно диски? Что, религия запрещает создавать виртуальные диски в памяти? )
Ну а считать генерацию кеша дополнительной нагрузкой - это нечто, т.к. задача кеши именно избавить сервак от основной нагрузки ;)
Ну так я и отвечаю на этот вопрос. Да, можно избавиться от БД (в ее привычном обозначении). И да, можно перенести хранение данных на ФС. Вопрос только в реализации и не более того, а тут уже надо исходить из требований и целей.
Мдя... Вы работали с нагруженными проектами? Например, 200-300к уников при 3-5М просмотров? Я вот работал. И все, что я говорил выше - это практический опыт, а не теория.
Вообще, всегда удивляли люди, которые начитавшись "умных" книг строят теории. Вот вам еще один холивар - нормализация БД в крупных проектах вредна. А по учебникам - наоборот ;). Ну а я удаляюсь из темы - доказывать, что земля круглая, дело не благодарное в принципе ;)
Да ладно?! http://habrahabr.ru/post/64325/ - простой пример, когда отказ от БД дает только плюс.
А про кеширования я разве не то же самое говорил? Процитирую СВОИ слова:
---------- Добавлено 05.10.2012 в 10:36 ----------P.S.: вообще, я не говорил, что БД - плохо )). Использование базы данных дает огромные плюсы, но и несет свои минусы. И когда человек говорит, что БД никогда не будет самым слабым местом в веб-проекте - это повод усомниться в его квалификации.
Опросил всех знакомых, кто так или иначе работал с более-менее нагруженными проектами (от 50к уников в сутки). Во всех, без исключений, случаях проблемы были только с базой.
Из своего опыта: один сервер может держать тысячи одновременных подключений, а вот база данных такого не выдерживает (разговор не о select 1). Именно поэтому и используются шардинги, репликации, партиции и пр. плюшки.
@Root77 - индексы были приведены в пример, как фича баз данных. Хотя их можно использовать почти везде, включая файловые хранилища.
Ни разу. На спор, без базы сделаю быстрее? Или индексы есть только в базах? )))
Ну так я про то и говорю, что время на генерацию результата мизерно, по отношению к получению данных из базы.
Просто некоторые не умеют правильно готовить ))). В реале, кеширование спасает именно от обращения к базе, а не от генерации результатов, верно? )
Ну-ну... http://aktuba.com/o-bloge.html - именно кеш помогает ;)
Я работал с большими нагрузками. Не на одном проекте. И тормоза ВСЕГДА именно в БД. Никогда не задумывались, для чего используется кеширование?
Перешли не из-за скорости работы, а из-за удобства. Попробуйте в файловом хранилище нормально настроить индексы, особенно составные. А потом замерьте удобство и скорость работы.
Плюс базы данных, изначально, именно в удобной работе с данными, а уже потом идут другие плюшки (триггеры, шардинг, партиции и пр.). И кстати, практически все движки баз данных имеют внутреннюю систему кеширования именно по причине НЕ быстрой работы с данными.
Похоже, все-же именно диванный ))) Как сессии в мемкеше ускорят сам php? o_O Наверное, имелось в виду ускорение обработки сессий? Ну тогда надо вообще от сессий отказываться, в пользу обычных кук (секретный данные необходимо шифровать в них). Даже полностью зашифрованные куки работают ЗНАЧИТЕЛЬНО быстрее сессий в мемкеше ;)
Почему предлагается на nginx только статику повесить? Почему-бы не отдать ему часть функционала (например, ресайз изображений, кеширование отдаваемых страниц, gzip в конце-концов)?
