накопление угу, довольно банальная вещь. мы и в php в этом же проекте аналогично накапливаем часть счётчиков в APC и изредка сбрасываем в базу.
однопоточность в данном случае не идеал, просто так сложилось исторически, на мой взгляд всё-таки работу с базой стоило бы вынести в отдельный thread, но автор не хочет, мне тоже лень.
+1 к оптимизированности, про запутанность кода — мне так не показалось, объектные «плюсы», большая часть логики, которую имеет смысл «затачивать» в одном методе — insert_peer. впрочем, это скорее спор о вкусе и цвете фломастеров :)
замечу что разница не только количественная, но и в качестве предоставляемых «услуг».
обмен данными торрент-клиентов с трекером происходит каждые 5 минут, на других — до 50 минут, поэтому новые пиры быстрее находят друг друга. поддерживается scrape, на многих php-движках он вообще отключен.
многие трекеры вообще отключили поиск в тексте сообщений форума, оставив только по названиям тем. мы не только оставили, но отдаём даже по RSS.
качество поиска выше. поищите «s.t.a.l.k.e.r» например. у многих слова короче 2-3 букв не индексируются вообще.
1) что-то я не понял. то Вы пишете «отсутствие смысла в этом составном индексе вам покажет...», то, наоборот, настаиваете на подобном индексе?
2) составной индекс отсортирован только по одному полю — первому. если есть несколько строк с одинаковым значением этого поля — они сортируются по второму, если есть совпадающие — по третьему и т.д. поэтому если поле в составном индексе не на 1 месте — потребуется отдельная сортировка результатов.
3) данных в индексе недостаточно. например, там нет поля topic_title. поэтому дополнительные действия мускул выполнять будет — построчно читать данные из самой таблицы.
при этом оптимизатор сначала оценивает, какую долю записей позволяет отбросить индекс. ибо построчное обращение к таблицы намного медленее чем её полное сканирование подряд без индекса. поскольку условие NOT IN, я не исключаю что оптимизатор решит вообще индексов не использовать, а сделать FULL TABLE SCAN. с хинтом он заведомо будет использовать указанный индекс, потому я и написал «попробовать».
4) никакого составного индекса «p.topic_id + p.post_id» не существует.
1) явная форма: phpbb_topics AS t JOIN phpbb_posts AS p ON p.topic_id = t.topic_id AND p.post_id = t.topic_last_post_id
2) есть 2 способа выполнения запроса. либо мы сначала собираем все данные (join+where), сортируем, и потом возвращаем первые 6 строк. либо мы начинаем обходить данные в порядке необходимой сортировки, т.е. от максимального topic_last_post_id к минимальному, и как только набрали указанное в LIMIT число строк — остановить обход.
3) обходить в нужном порядке можно по индексу, где первым полем стоит либо t.topic_last_post_id, либо p.post_id. предложенный Вами индекс этого не позволяет.
4) в каком месте, по вашему, у нас проблемы?
5) опишите подробно план исполнения запроса с ипользованием предложенного Вами индекса.
1) любой оптимизатор не идеален, он не знает того, что знает программист. в данном случае идёт выборка специфических данных — 6 последних постов, оптимизатор же решает задачу в общем виде, поскольку не знает специфики выбираемых данных.
2) составной индекс бесспорно тяжелее простого. фильтр по forum_id в большинстве случаев ничего не отбрасывает — практически все форумы открыты, активность в закрытых очень небольшая, поэтому в большинстве случаев результат выборки по простому и составному индексу совпадут.
3) какое поле будет первым в составном индексе принципиально. оптимальный план выполнения данного запроса — частичный обход индекса на topic_last_post_id пока не найдётся 6 подходящих строк, в большинстве случаев ими будут самые первые 6.
4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.
5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.
6) если topic_last_post_id вообще не индексировать, то оптимальным планом исполнения будет обход по post_id, построчный JOIN с phpbb_topics по первичному ключу, проверка условий, пока не наберётся нужный лимит. без хинтов такого плана добиться тоже не удаётся.
(topic_last_post_id,forum_id) можно было бы попробовать, но оно и сейчас отлично работает, поэтому трогать не хочется, вдруг не поможет. конкретно этот запрос можно вообще по p.post_id делать, а индекс topic_last_post_id выкинуть. но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
до этого что-то подобное было в RSS где тоже надо было отобрать несколько последних сообщений с ещё большим числом условий, но подробностей сейчас не помню и по-моему хватило хинта STRAIGHT_JOIN
есть мод к phpBB который показывает несколько последних тем. там запрос с проверкой прав доступа и т.п. и заканчивается на ORDER BY id-последнего-поста LIMIT 5; поле, естественно, проиндексировано, но в WHERE стоят условия и на другие поля, видимо поэтому мускул использовал другие индексы, после чего делал дисковую сортировку результата и отбирал 5 первых строк. добиться от него, чтобы он выбирал по индексу последние посты, пока не наберётся нужный LIMIT тупым переписыванием запроса сходу не получилось, хинт с явным указанием имени индекса помог. есть подозрение, что мускул предпочитает индексы, поля которых фигурируют в WHERE, а не в ORDER BY, но глубоко на эту тему не гуглили и не экспериментировали. надеюсь понятно написал, если надо — могу сам запрос привести.
это уже скорее оффтоп, но пару лет назад я искал — оказалось что XBTT прикрутили практически ко всем популярным php-трекерам. не все бесплатные, сейчас вроде даже к phpBB3 прикрутили но баблос хотят. сам автор XBT, Olaf van der Spek, писал морду к… IPB по-моему, так что выбор «морд» к XBTT широкий, на любой вкус есть.
на самом деле ситуация с торрентами в россии и в мире принципиально отличается. в мире есть огромные полностью свободные трекеры и индексы типа пиратской бухты или мининовы. там не надо регистрироваться, берёшь и тупо качаешь. закрытые (приватные) трекеры есть, но они менее популярны. Россия же как всегда идёт своим путём, самый популярный трекер рунета — закрытый, с учётом трафика, регистрацией и т.п. несколько открытых трекеров есть, но о них мало кто знает.
изначально железо было хуже, был 2006 год, когда только начался появляться массовый широкополосный инет в крупных городах, наплыв народа на все трекеры был огромный, и на торрентс.ру который тоже не справлялся с нагрузкой и постоянно падал. рекламы первое на трекер на ставили, так что баблос на железо был ограничен. и как только выпадёт свободных пара дней — подкручивали что-то по мелочи, вроде легчало
как я понимаю у нас разница в масштабах. у вас офис, штатные программеры, возможность свой трекер с нуля писать, у нас же всё в исключительно свободное время, поэтому выбор идёт в первую очередь — что меньше времени потребует. над переводом морды на JForum думали изначально, но столько времени просто нет
однопоточность в данном случае не идеал, просто так сложилось исторически, на мой взгляд всё-таки работу с базой стоило бы вынести в отдельный thread, но автор не хочет, мне тоже лень.
обмен данными торрент-клиентов с трекером происходит каждые 5 минут, на других — до 50 минут, поэтому новые пиры быстрее находят друг друга. поддерживается scrape, на многих php-движках он вообще отключен.
многие трекеры вообще отключили поиск в тексте сообщений форума, оставив только по названиям тем. мы не только оставили, но отдаём даже по RSS.
качество поиска выше. поищите «s.t.a.l.k.e.r» например. у многих слова короче 2-3 букв не индексируются вообще.
2) составной индекс отсортирован только по одному полю — первому. если есть несколько строк с одинаковым значением этого поля — они сортируются по второму, если есть совпадающие — по третьему и т.д. поэтому если поле в составном индексе не на 1 месте — потребуется отдельная сортировка результатов.
3) данных в индексе недостаточно. например, там нет поля topic_title. поэтому дополнительные действия мускул выполнять будет — построчно читать данные из самой таблицы.
при этом оптимизатор сначала оценивает, какую долю записей позволяет отбросить индекс. ибо построчное обращение к таблицы намного медленее чем её полное сканирование подряд без индекса. поскольку условие NOT IN, я не исключаю что оптимизатор решит вообще индексов не использовать, а сделать FULL TABLE SCAN. с хинтом он заведомо будет использовать указанный индекс, потому я и написал «попробовать».
4) никакого составного индекса «p.topic_id + p.post_id» не существует.
2) есть 2 способа выполнения запроса. либо мы сначала собираем все данные (join+where), сортируем, и потом возвращаем первые 6 строк. либо мы начинаем обходить данные в порядке необходимой сортировки, т.е. от максимального topic_last_post_id к минимальному, и как только набрали указанное в LIMIT число строк — остановить обход.
3) обходить в нужном порядке можно по индексу, где первым полем стоит либо t.topic_last_post_id, либо p.post_id. предложенный Вами индекс этого не позволяет.
4) в каком месте, по вашему, у нас проблемы?
5) опишите подробно план исполнения запроса с ипользованием предложенного Вами индекса.
2) составной индекс бесспорно тяжелее простого. фильтр по forum_id в большинстве случаев ничего не отбрасывает — практически все форумы открыты, активность в закрытых очень небольшая, поэтому в большинстве случаев результат выборки по простому и составному индексу совпадут.
3) какое поле будет первым в составном индексе принципиально. оптимальный план выполнения данного запроса — частичный обход индекса на topic_last_post_id пока не найдётся 6 подходящих строк, в большинстве случаев ими будут самые первые 6.
4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.
5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.
6) если topic_last_post_id вообще не индексировать, то оптимальным планом исполнения будет обход по post_id, построчный JOIN с phpbb_topics по первичному ключу, проверка условий, пока не наберётся нужный лимит. без хинтов такого плана добиться тоже не удаётся.