Страницы

Wednesday, October 03, 2007

Sic transit ...

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

total queries: 310

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

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

7 comments:

  1. Anonymous9:57 PM

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

    ReplyDelete
  2. Anonymous5:30 PM

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

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

    ReplyDelete
  4. Anonymous10:48 PM

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

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

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

    ReplyDelete
  6. Anonymous11:02 AM

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

    ReplyDelete
  7. Anonymous7:19 PM

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

    ReplyDelete