- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
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, А, если показы клики держать в мемкеше скажем те что в реальном времени, а почасовые и тп скидывать в мемкеш?