- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
kxk, тут проблема, что БД нестатична. Просто тяжело представить, сколько времени займет индексация такой БД сфинксом, каждый раз после обновления.
В NoSql лезть не стоит?
Структура простая - пять полей - ид ключа, ид рекламы, просмотры, клики, цтр. Индексы присутствуют. Сортировка по цтр. Вроде все.
Применение Percona не сделает вашу базу автоматические быстрее. Это все тот же самый код mysql с дополнительной диагностикой. Ей нужно уметь пользоваться и думать.
Факты, которые вы храните в базе в крайне больших масштабах создаются автоматами. В какой базе их не храни - быстро они не станут обрабатываться никак. Уже понятно что стоимость их хранения несоразмерна с вашей выгодой.
Выбор максимума из большого списка, подсчет суммы - это все агрегация и она не оптимизируется никак. Только если эту работу сделать заранее.
Например, незаслуженно забытый вебмастерами openx просто не хранит отдельные факты о кликах и просмотрах в бд . Действительно не хранит, но выполняет свои задачи по оценке CTR и лимитированию показов по разным факторам.
Как ? Он предагрегирует данные. Хранит клики и просмотры за час. Если там какие-то условия - пересчитывайте правила показа не на ходу, а в некоторые промежутки. Ужасно подробная детализация не нужна. Измените условия. Даже откажитесь от определенных вещей, обещанных пользователями, которые вы считаете плюсами и фишками - и она заработает быстрее.
Вот что на самом деле является оптимизацией приложения.
netwind, порекомендуйте куда смотреть, если перкона не выход.
Сферическая база с множеством сферических запросов с сортировкой...
sidorka, так я и написал куда. Короткий ответ : смотреть на себя и в предметную область.
Не надо думать как математик. Ответа на такой вопрос нет. Никакая база не может являться "сферической в вакууме". Программисты и инженеры решают частные практические задачи.
В реляционной теории sql-базы ведь возвращают ответ как бы мгновенно. Абстракция sql считает, что план работы запроса отсутствует как предмет обсуждения. Но он существует и влияет на реальность.
sidorka, База на 10G монстро сервером (благо сейчас процессор и память дешёвые) индексировалась менее 5 минут :)
офтопик... обычно есть две проблемы: недостаток данных и избыток ненужных данных(как у Вас).
Вроде тизерки личной ваяю - под каждый ключевик наиболее кликабельный результат выбирается. Структура простая - пять полей - ид ключа, ид рекламы, просмотры, клики, цтр. Индексы присутствуют. Сортировка по цтр. Вроде все.
Наверное, вы пытаетесь сохранять все показы/клики и т.д. - тупиковый путь.
Сохраняйте и оперируйте только итоговыми цифрами за час, сутки, неделя, месяц. Может вы немного потеряете в точности, но значительно выиграете в скорости и в устойчивости своей системы.
К примеру, по таблице с подробными данными(bulk), можно раз в час считать итоговые данные и эти итоговые данные сохранять, а саму табличку bulk очищать.
Для истории(отладки), можно накапливать bulk в виде текстовых логов по дням. Сделайте удобный для себя формат логов и вперед.
Согласен с admak, у вас, скорее всего, избыточные данные в таблице хранятся. Если вам нужна статистика, то проще накапливать итоговые значения, чем каждый раз их вычислять.
Все это уже есть - на запись данные накапливаются, бд только на чтение, кэширование присутствует.
Только вот ввиду большого размера - 10гиг это неделя работы только и уже начинаются проблемы, устаканившийся в будущем размер БД - неизвестен, все проверяется в бою вживую, только хардкор - разброс запросов все таки достаточно большой выходит, кэширование снимает проблему лишь частично. Как вариант увеличивать размер кэша, но рано или поздно все равно ведь упрусь в потолок и низкочастотные запросы, которые не попали в кэш, все равно положат сервер.
Сначала все же попробую перкону - уж больно тесты красиво выглядят :)
Использование MongoDB и подобных может кардинально решить проблему со скоростью доступа?
---------- Добавлено 16.02.2015 в 21:15 ----------
iBrains, я не вычисляю ничего при чтении. Цтр пишется только при обновлении, потом статичен до следующего апа. Показы-клики - для вычисления при апе, сортировка не по ним идет все равно.
Как вариант увеличивать размер кэша
ТС, вам не про кеш запросов говорят, а про избыточность данных и архитектуру бд. netwind вам правильно сказал "Применение Percona не сделает вашу базу автоматические быстрее."
sidorka, А, если показы клики держать в мемкеше скажем те что в реальном времени, а почасовые и тп скидывать в мемкеш?