50/50 встает и выбирает. Создайте две таблицы или одну таблицу

Question

Теперь предлагаемые структуры таблицы:-

data_table
->impressions
->clicks
->ctr

ИЛИ ЖЕ

data_table_1
->ctr

data_table_2
->impressions
->clicks

Какие запросы выполнены? Для впечатлений около 500 обновлений в секунду. Есть около 1 обновления для кликов каждую секунду. Для CTR около 500 обновлений в секунду.

Теперь мое приложение сортирует данные, используя CTR. CTR - это скорость просмотра кликов, которая разрабатывается ctr = clicks/impressions. Анкет Теперь я понял, что, если нет обновления клика, CTR не нужно обновлять, поскольку все впечатления для статей увеличиваются быть обновленным.

В настоящее время запрос на обновление подобен «Обновление data_table setipressions = впечатления + 1, ctr = клики / впечатления, где что -то = что -то

Это означает, что хотя 2 поля обновляются сразу только 1 запрос.

Теперь узкое место заключается в том, что эти 500 обновлений об этом, вызывая замедление на выборах в этой таблице. Есть около 20 выборов в секунду. Поэтому я подумал о разделении таблиц. Новый стиль таблицы предлагает, чтобы обновления происходили в отдельной таблице, а выборы происходили в отдельной таблице. Таблица данных, которая содержит впечатления, обновляется очень часто, поэтому обновления для показов, выполненных на нем, действительно ускоряет производительность в этой таблице. Это означает, что выборы на data_table_2 тоже будут быстрее, а CTR может быть обновлен каждый раз, когда кто -то делает щелчок.

Итак, я просто хотел знать, должен ли я использовать новую структуру таблицы или нет. Какие вы предложения? Плюсы и минусы моих предложений!

Answer 1

Может быть, это не прямой ответ на ваш вопрос, но я думаю, что важно отметить.

Я думаю, что вам следует рассмотреть возможность использования баз данных NOSQL, таких как Redis, Memcachedb, Mongdb, Couchdb. Реляционные СУБД не подходят для такого рода использования. Например, каждый раз, когда вы обновляете любой столбец (UPDATE data_table SET impressions = impressions + 1) Кэши стерты, и БД должен попасть в диск.

Другие думают, что вы можете рассмотреть вопрос о использовании MEMCACHE и объем данных для диска в течение некоторого периода времени.

Например, если вы можете позволить себе потерять некоторые отзывы (помните, что Memcache не сохраняет данные), вы можете выполнять отзывы ++ в Memcache и обновлять данные в БД каждые 5 минут. Это значительно уменьшит вашу нагрузку.

Надеюсь, это поможет вам.

РЕДАКТИРОВАТЬ:

Хранение CTR - хорошая идея, она называется «денормализацией» и может работать в вашем приложении, если это часто требуемое значение.

Answer 2

Прежде всего, я предполагаю, что таблица хорошо проиндексирован, поэтому something = something Предикат быстро приведет к соответствующей строке, верно?

Кроме того, предполагая, что ваше узкое место пропускается на диск из-за высокой скорости обновления, а что касается значения CTR вообще, так как его можно легко рассчитать на лету? Поскольку вы, кажется, ограничены своим обновлением, обновление только одного поля должно примерно вдвое влияние необходимости записать данные на диск. Учитывая такой сценарий, когда ЦП, вероятно, относительно простоя, расчет кликов/впечатлений для каждого результата должен быть не проблема. Ваш подход окупится (опять же, предполагая, что диск является ограничивающим фактором, который предполагает, что он является и может быть легко обнаружен, рассматривая использование ЦП), тогда ваш подход даст значительные преимущества, IFF столы или на двух разных дисках.

Если процессор оказывается ограничивающим фактором, то это, вероятно, потому что something = something Предикат довольно сложный для оценки, в этом случае упрощение этого должно быть основной проблемой, а не разделять таблицы.