БД гигантского размера

123 4
sidorka
На сайте с 17.08.2012
Offline
211
#11

kxk, тут проблема, что БД нестатична. Просто тяжело представить, сколько времени займет индексация такой БД сфинксом, каждый раз после обновления.

В NoSql лезть не стоит?

Дешевые домены для дорвеев и не только - от 55р (https://goo.gl/Wtnwqp)
N
На сайте с 06.05.2007
Offline
419
#12
sidorka:

Структура простая - пять полей - ид ключа, ид рекламы, просмотры, клики, цтр. Индексы присутствуют. Сортировка по цтр. Вроде все.

Применение Percona не сделает вашу базу автоматические быстрее. Это все тот же самый код mysql с дополнительной диагностикой. Ей нужно уметь пользоваться и думать.

Факты, которые вы храните в базе в крайне больших масштабах создаются автоматами. В какой базе их не храни - быстро они не станут обрабатываться никак. Уже понятно что стоимость их хранения несоразмерна с вашей выгодой.

Выбор максимума из большого списка, подсчет суммы - это все агрегация и она не оптимизируется никак. Только если эту работу сделать заранее.

Например, незаслуженно забытый вебмастерами openx просто не хранит отдельные факты о кликах и просмотрах в бд . Действительно не хранит, но выполняет свои задачи по оценке CTR и лимитированию показов по разным факторам.

Как ? Он предагрегирует данные. Хранит клики и просмотры за час. Если там какие-то условия - пересчитывайте правила показа не на ходу, а в некоторые промежутки. Ужасно подробная детализация не нужна. Измените условия. Даже откажитесь от определенных вещей, обещанных пользователями, которые вы считаете плюсами и фишками - и она заработает быстрее.

Вот что на самом деле является оптимизацией приложения.

Кнопка вызова админа ()
sidorka
На сайте с 17.08.2012
Offline
211
#13

netwind, порекомендуйте куда смотреть, если перкона не выход.

Сферическая база с множеством сферических запросов с сортировкой...

N
На сайте с 06.05.2007
Offline
419
#14

sidorka, так я и написал куда. Короткий ответ : смотреть на себя и в предметную область.

Не надо думать как математик. Ответа на такой вопрос нет. Никакая база не может являться "сферической в вакууме". Программисты и инженеры решают частные практические задачи.

В реляционной теории sql-базы ведь возвращают ответ как бы мгновенно. Абстракция sql считает, что план работы запроса отсутствует как предмет обсуждения. Но он существует и влияет на реальность.

kxk
На сайте с 30.01.2005
Offline
990
kxk
#15

sidorka, База на 10G монстро сервером (благо сейчас процессор и память дешёвые) индексировалась менее 5 минут :)

Ваш DEVOPS
A
На сайте с 19.07.2010
Offline
130
#16

офтопик... обычно есть две проблемы: недостаток данных и избыток ненужных данных(как у Вас).

sidorka:
Вроде тизерки личной ваяю - под каждый ключевик наиболее кликабельный результат выбирается. Структура простая - пять полей - ид ключа, ид рекламы, просмотры, клики, цтр. Индексы присутствуют. Сортировка по цтр. Вроде все.

Наверное, вы пытаетесь сохранять все показы/клики и т.д. - тупиковый путь.

Сохраняйте и оперируйте только итоговыми цифрами за час, сутки, неделя, месяц. Может вы немного потеряете в точности, но значительно выиграете в скорости и в устойчивости своей системы.

К примеру, по таблице с подробными данными(bulk), можно раз в час считать итоговые данные и эти итоговые данные сохранять, а саму табличку bulk очищать.

Для истории(отладки), можно накапливать bulk в виде текстовых логов по дням. Сделайте удобный для себя формат логов и вперед.

.............
iBrains
На сайте с 06.11.2011
Offline
67
#17

Согласен с admak, у вас, скорее всего, избыточные данные в таблице хранятся. Если вам нужна статистика, то проще накапливать итоговые значения, чем каждый раз их вычислять.

sidorka
На сайте с 17.08.2012
Offline
211
#18

Все это уже есть - на запись данные накапливаются, бд только на чтение, кэширование присутствует.

Только вот ввиду большого размера - 10гиг это неделя работы только и уже начинаются проблемы, устаканившийся в будущем размер БД - неизвестен, все проверяется в бою вживую, только хардкор - разброс запросов все таки достаточно большой выходит, кэширование снимает проблему лишь частично. Как вариант увеличивать размер кэша, но рано или поздно все равно ведь упрусь в потолок и низкочастотные запросы, которые не попали в кэш, все равно положат сервер.

Сначала все же попробую перкону - уж больно тесты красиво выглядят :)

Использование MongoDB и подобных может кардинально решить проблему со скоростью доступа?

---------- Добавлено 16.02.2015 в 21:15 ----------

iBrains, я не вычисляю ничего при чтении. Цтр пишется только при обновлении, потом статичен до следующего апа. Показы-клики - для вычисления при апе, сортировка не по ним идет все равно.

siv1987
На сайте с 02.04.2009
Offline
427
#19
sidorka:
Как вариант увеличивать размер кэша

ТС, вам не про кеш запросов говорят, а про избыточность данных и архитектуру бд. netwind вам правильно сказал "Применение Percona не сделает вашу базу автоматические быстрее."

kxk
На сайте с 30.01.2005
Offline
990
kxk
#20

sidorka, А, если показы клики держать в мемкеше скажем те что в реальном времени, а почасовые и тп скидывать в мемкеш?

123 4

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий