- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Как Вы планируете кешировать редкие запросы? Я анализировал запросы Rambler. Там на фразы с частотой более 3-х запросов в месяц (250К фраз) приходится только 25% всех запросов пользователей. Никакие memcached не помогут. Запрос должен отдаваться менее, чем за 3 секунды. Особенность психологии человека. На PHP для 200К документов это очень трудно будет сделать из-за сортировок, скорости доступа к MySQL, общей скорости выполнения большого количества операторов.
Вопрос не ко мне, но я отвечу.
Для быстрого поиска есть два варианта:
1. Организация сортированого списка
2. Организация большого к-ва мелких не сортированных списков.
Например разделим запросы по первым двум буквам аа, аб, ав, ..., яя можно еще по к-ву символов.
Есть третий вариант комбинированный
Вопрос не ко мне, но я отвечу.
Для быстрого поиска есть два варианта:
1. Организация сортированого списка
2. Организация большого к-ва мелких не сортированных списков.
Например разделим запросы по первым двум буквам аа, аб, ав, ..., яя можно еще по к-ву символов.
Есть третий вариант комбинированный
Это работает только для поиска идентификаторов слов, чтобы вытащить обратные индексы для слов в фразе. Проблема не в поиске идентификаторов. Проблема в сливании этих обратных индексов и, особенно, в ранжировании. Самая медленная часть поисковика - ранжирование результатов перед выдачей.
волшебные хэши спасут мир.
волшебные хэши спасут мир.
Может и спасут. Не знаю как сортировать с помощью хеша :-)) Можно попробовать использовать методику Google MapReduce. Но не знаю, что быстрее: в L1 сортировкой искать первые 10 записей или вычислять Map, а потом по нему бежать и собирать значения (Reduce), с учётом возможности одинаковых значений. Хотя можно попытаться Map в L2 запихнуть...
Может и спасут. Не знаю как сортировать с помощью хеша :-)) Можно попробовать использовать методику Google MapReduce. Но не знаю, что быстрее: в L1 сортировкой искать первые 10 записей или вычислять Map, а потом по нему бежать и собирать значения (Reduce), с учётом возможности одинаковых значений. Хотя можно попытаться Map в L2 запихнуть...
http://en.wikipedia.org/wiki/Bloom_filter
ps. не уловил ход мыслей... а зачем нам сортировать?
Да, кстати, не понял почему кэш нельзя хранить на диске. Сколько нужно трафа выдавать? Гигабит? Мы ночью тут по другой теме чуть спорили, но тем не менее задача аналогичная.
Поставьте под кэш корзинки infortrend и результаты поиска держите там - полгигабита с одной корзины на 5к конектов более чем реально. Это реальная цифра с SATA2SCSI320 корзинки. Ну соберите там террабайт надцать на SATA и этих корзинах... вот вам и кэш уже реальный. Чо сразу в мемкашед то перется, оператива она в любом случае дороже SATA... главное 3 секунды озвучили, так что memcached берем назад... а тут понимаешь ли выдув наманый устроить можно. Секунды какие-то еще мерять... в мегабитах давайте - так проще.
ps. Такие корзины в данный момент ликвиднее серверов с кучей оперативы.... инвестор просто кончит от радости.
Дешевле. Однозначно. Пока не встают сложные задачи, когда знания и интеллект стоят больше умения работать на том или ином языке.
Слава, ну это все из области - а зачем ставить linux, когда и на freebsd можно затюнить kern.nbuf? Ну да, хреновый во FreeBSD read cache буфер... а шо делать?
ps. Ну и на пехапе конфетку сделать же можно.
Да, кстати, не понял почему кэш нельзя хранить на диске. Сколько нужно трафа выдавать? Гигабит? Мы ночью тут по другой теме чуть спорили, но тем не менее задача аналогичная.
Сам кеш трудно создать из-за того, что подавляющее большинство запросов - редки. Проще говоря, если обновлять базу раз в неделю и держать неделю данные в кеше, то только пятая часть запросов будет идти через кеш. Остальные будут строиться с нуля.
P.S. Спасибо за ссылку и за железку. Недавно ставил оценку в репутацию и жалко, что форум не даёт поставить вторую.
Сам кеш трудно создать из-за того, что подавляющее большинство запросов - редки. Проще говоря, если обновлять базу раз в неделю и держать неделю данные в кеше, то только пятая часть запросов будет идти через кеш. Остальные будут строиться с нуля.
sata2scsi дешевое решение..... 30Тб могут спасти поисковик на пехапе?
sata2scsi дешевое решение..... 30Тб могут спасти поисковик на пехапе?
Нет. Повторюсь: кеш можно делать для многоразовых запросов (спросили три раза и более). В поисковиках с этим проблема - более 3/4 всех запросов уникальны.