Да я все понимаю, в локальной перспективе к ним претензий нет. Не правы они только в том, что запас по надежности напрочь отсутствует. За последние два года - то с питанием проблемы, то с жарой. В итоге сервера лежат часами, и uptime ой как не дотягивает даже до трех девяток :( Просто не надо брать столько клиентов, сколько не можешь обслужить.
Видимо, у них такой подход во всем :) Когда слишком большая нагрузка на базу - отрубают от базы. А когда в серверной слишком жарко - просто вырубают "лишние" сервера (на прошлой неделе половину наших серверов выключали где-то с 14 до 22 часов - несколько дней подряд).
Я бы не был так категоричен :) В больших (нагруженных) проектах граница между статикой и динамикой обычно весьма размыта: при формировании динамики почти всегда используется кэширование, а сформированная динамика часто пишется в файл, чтобы в дальнейшем отдавать этот результат как статику.
Различных комбинаций данных может быть потенциально бесконечное количество, но вот количество пользователей, в данный момент работающих с сервисом - всегда конечно. Поэтому вполне реально всем им угодить, рассчитав именно то, что нужно им.
Да, но это к вопросу об объеме данных, который поднят ниже. А на производительность вычислений не влияет, так как она пропорциональна количеству поступающих сообщений (еще конечно здесь будет время на подгрузку базы нужного пользователя - но это мелочи).
1. Да, внедрять такой сервис массово - это значит хранить большой объем данных. Однако, можно придумать разные ухищрения - например, хранить не полную базу, а только наиболее отличительные слова. Или объединять похожие профили пользователей, или сжимать их на лету (ведь не все одновременно лезут на сайт - а сжимаются такие данные хорошо). В общем, если бы это внедрял Яндекс - думаю они бы справились ;)
2. Конечно, это будет работать прежде всего как тематический фильтр. Но на мой взгляд, и это очень актуальная задача - ведь часто бывает, что в каком-либо блоге мне интересна малая часть постов. Конечно, есть теги - но, к сожалению, их далеко не всегда корректно расставляют. Кстати, подобный подход можно было бы использовать и для автоматического теггирования контента (мне пока такие системы неизвестны).
3. Наверное это и есть ответ на мой вопрос про то, как пропущенные классификатором хорошие посты попадут в ленту :)
На многих хостингах работают спам-фильтры, использующие байесовский классификатор. По моему, для большинства пользователей поток почты (включая спам, конечно) по объему больше, чем поток читаемых им rss. Так что особой проблемы с вычислениями не вижу.
Вообще-то (если я правильно понял) речь шла не о Байесовских сетях, а о Байесовском наивном классификаторе. Обычно в задачах классификации/фильтрации используется именно он, так как запрограммировать автоматическое построение сети довольно сложно.
Лог медленных запроов, безусловно, полезная штука. Но он не решает всех проблем - хотя бы потому, что минимальное время выполнения "медленного" запроса - 1 скеунда. Т.е. никак не заставишь mysql писать в него запросы, которые выполняются более 0.1 или 0.5 секунд. В то же время обычно наибольшее суммарное время приходится именно на такие запросы (а вове не на медленные). Обычно это довольно простые запросы, которые выполняются неэффективно из-за неправильно построенных индексов или неправильно формулированных запросов (и тем не менее, успевают отработать за секунду). Их можно (и нужно) отследить только аггрегируя полный лог запросов.
Идея отличная. Но есть проблема с обучением - байесовский классификатор лучше всего учится, когда ему подсовываешь те примеры, на которых он ошибся. С "плохими" темами все ясно - увидел плохой пост в ленте, кликнул "минус" - больше такого не увидишь. А как быть с "хорошими"? Как пользователь подсунет ему тот хороший пост, который не попал в ленту, а должен был бы? То есть, где пользователь будет искать такие хорошие посты?
машина умеет классифицировать на тематики, и не умеет делить на хорошее и плохое
Конечно, машина этого не умеет - но идея-то в том, что делить будет человек! Человек показывает машине, что лично для него является хорошим, а что - плохим. Машина учится и дальше классифицирует сама. И кстати, это совсем не модерация, ничуть - это лишь продвинутая логика составления персональной ленты.
На мой взгляд, для описанной задачи байесовская классификация как раз хорошо подойдет - словарь характерных слов тут весьма ограничен :) Кстати, она пригодна не только для того, чтобы разделять на плохой/хороший, но и для классификации по нескольким категориям.
Различных комбинаций данных может быть потенциально бесконечное количество, но вот количество пользователей, в данный момент работающих с сервисом - всегда конечно. Поэтому вполне реально всем им угодить, рассчитав именно то, что нужно им.
1. Да, внедрять такой сервис массово - это значит хранить большой объем данных. Однако, можно придумать разные ухищрения - например, хранить не полную базу, а только наиболее отличительные слова. Или объединять похожие профили пользователей, или сжимать их на лету (ведь не все одновременно лезут на сайт - а сжимаются такие данные хорошо). В общем, если бы это внедрял Яндекс - думаю они бы справились ;)
2. Конечно, это будет работать прежде всего как тематический фильтр. Но на мой взгляд, и это очень актуальная задача - ведь часто бывает, что в каком-либо блоге мне интересна малая часть постов. Конечно, есть теги - но, к сожалению, их далеко не всегда корректно расставляют. Кстати, подобный подход можно было бы использовать и для автоматического теггирования контента (мне пока такие системы неизвестны).
3. Наверное это и есть ответ на мой вопрос про то, как пропущенные классификатором хорошие посты попадут в ленту :)
Конечно, машина этого не умеет - но идея-то в том, что делить будет человек! Человек показывает машине, что лично для него является хорошим, а что - плохим. Машина учится и дальше классифицирует сама. И кстати, это совсем не модерация, ничуть - это лишь продвинутая логика составления персональной ленты.