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

Question

Теперь предложенные структуры таблиц: -

data_table
->impressions
->clicks
->ctr

OR

data_table_1
->ctr

data_table_2
->impressions
->clicks

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

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

В настоящее время запрос на обновление похож на «ОБНОВИТЬ data_table SET. Показы = Показы + 1, CTR = Клики / Показы, ГДЕ что-то = что-то

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Другое мнение, которое вы можете рассмотреть, - это использование Memcache и массовая передача данных на диск после некоторого времени.период времени.

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

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

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

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