Wednesday, October 03, 2007

Sic transit ...

На сайте habrahabr.ru зачем-то в выдачу включили отладочную информацию о запросах к базе данных. Чудно конечно, но вылезли весьма интересные вещи:

total queries: 310

Это столько запросов было выполнено, чтобы сформировать список сообщений к отдельному посту. Часть из них идут к кешу (используется memcached), но остальные - честно лазят по базе данных. Так, например, последовательно выясняют (select операторы) а кто пользователь, а не модератор ли он etc. А потом также циклически (последовательные select) вычисляют отношение пользователя к участникам дискуссии. То есть если дискуссия длинная, то и селектов этих последовательных будет много много :)

При такой схеме им или нужно очень много железок или очень мало пользователей. Что рассуждать об архитектуре всяких Фейсбуков, когда примеры "как не надо" есть гораздо ближе :-)

7 comments:

Anonymous said...

гы, я тоже обратил на это внимание. Впечатление такое, что у них в каком-то большом цикле стоит выполнение операции select :-)

Anonymous said...

написАл об этом в блог "Я умный", приаттачил скриншот, тут же понизили карму и попросили топик прикрыть :)

Coldbeans software said...

то есть вы на самом сайте написали про него же? Уж тогда куда-нибудь еще напишите. И про карму, заодно

Anonymous said...

А не задумывались о том, что нормальная БД ооочень неплохо самостоятельно всё кеширует?
И что 100 однотипных запросов для неё будут копейками просто за счёт того, что нужный блок с данными осел в кеше БД уже после первого запроса из такой сотни? И дальше все обращения идут только в память?

Coldbeans software said...

а поддержка кэша - она бесплатна в смысле ресурсных затрат, или об этом не думают? Или запрос вообще не обрабатывается, если он в кэш будет направлен?

>запроса из такой сотни?
>И дальше все обращения идут только в >память?
вот ровно об этом я и написал - зачем сотни запросов? На 10 сообщений в дискуссии. И как это характеризует тех, кто такую модель спроектировал

Anonymous said...

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

Anonymous said...

>300 закешированных простеньких >запросов к
а 400? :-)