еще по таргетингу

[zaartix]

еще по таргетингу

В общем задачка - для контекстной рекламы (типа бегуна) реализовать таргетинг.
Возможные варианты: география, дни недели, часы.

Как бы это все поэффективнее реализовать? Чтоб поменьше запросов к бд было.

Очень хочется обойтись стандартными средствами, т.е. пхп и мыскль, но возможно и демона написать, если есть смысл.

Сейчас перед выводом объявления у меня идет единственный запрос к бд - забираются данные объявления по primary key, данные таргетинга в результате есть, в виде сериализованного массива. id сайта, далее его таргетинг: по часам - часы, по дням - дни, по географии - id регионов.

В случае если есть геотаргетинг - идет один дополнительный запрос к бд для определения id региона текущего айпи.

Как Вам такая схема? Можно-ли как-то еще оптимизировать.

Сейчас у меня схема примерно такая:
Раз в час формируется таблица (truncate->drop index->insert->create index):

CREATE TABLE `cron_adv` (
`key_id` int(11) NOT NULL default '0', // id ключевого слова (фразы)
`adv` text, // сериализованный массив самого рекламного блока (ну сам текст объявлений + некоторые нужные данные)
`targ` tinyint(1) NOT NULL default '0', // таргетинг (нехочу пока делать ему enum)
`targeting` varchar(128) default NULL, // сериализованный массив таргетинга (id сайта, таргетинг по времени суток, дням недели, массив id регионов)
PRIMARY KEY (`key_id`),
KEY `i6` (`targ`)
) ENGINE=MyISAM

p.s. Как вариант (гораздо более увеличивающий нагрузку на кроновскую задачу) - это формировать эту таблицу уже с учетом таргетинга. Т.е. если сейчас понедельник, то в таблице не будет объявлений, где эти дни запрещены. Правда - геотаргетинг при таких раскладах пока не знаю как реализовать.

В общем очень хочется, чтобы подсказали или поделились опытом

 

[clevel]

1. в nginx насколько я помню, есть модуль geoip, который в окружение ставит помимо айпишника - страну(город).
Это позволит убрать демон/запрос по определению города.

2. Поиграйся с таблицей своей:
- разбить на две: первая с фиксированной длиной строки - ключ фразы, айди сайтов, таргетинг (id+char), вторая - с плавающей, там уже по айди можно текст объявления вытащить и т.д.

 

[zaartix]

Автор оригинала: clevel
1. в nginx насколько я помню, есть модуль geoip, который в окружение ставит помимо айпишника - страну(город).
Это позволит убрать демон/запрос по определению города.

2. Поиграйся с таблицей своей:
- разбить на две: первая с фиксированной длиной строки - ключ фразы, айди сайтов, таргетинг (id+char), вторая - с плавающей, там уже по айди можно текст объявления вытащить и т.д.

1. Я в серверных делах не силен, но насколько понимаю это как из снайперки в обычном пневматическом тире стрелять, ну в смысле мощность инструмента гораздо выше, чем требуется, хотя вариант рабочий, спасибо.
Я вот чего надумал: ведь для геотаргетинга нужна только россия (и не россия как факт), соответственно создаем скриптик, внутри которого просто прописываем массив:

$ip[63][from_ip] = 1042350592;
$ip[63][to_ip] = 1042351103;

ну и так по всем регионам, а дальше, если нужен геотаргетинг - то инклудим этот скрипт и ищем id региона (скорее всего структуру хранения данных в скрипте можно оптимизировать для более быстрого поиска, но это уже отдельная задача). Что думаете? Эффективнее? Размер такой таблицы в бд ~500kb, т.е. превратив в скрипт, размер должен не сильно увеличится.
......
Но с другой стороны, коннект к бд уже есть, т.к. один запрос при любых раскладах должен быть. А раз так - может все-таки быстрее будет сделать еще один для поиска региона (тем более по primary key)?

Что-то я снова хз в общем прошу помощи в это вопросе.

2. а разве не оптимальнее будет обойтись без джойнов (держать все необходимое в отдельной таблице)? хотя я скорее всего не совсем понял смысла предложения

 

[clevel]

Что тебе мешает:
1. реализовать поиск города по айпишнику через базу и через текствоый файл, а потом сравнить результаты по скорости?

2. разбить таблицу на две - и замерить скорость поиска. Потом сравнить со скоростью выборки, когда одна таблица?
Народ тут активно в сое время обсуждал тем - что скорость поиска первичного по фиксированной (длине строки) таблице намного выше, чем по не по фиксированной.

Ну и ключи у тебя странно сформированны к таблице. Зачем ключи по id сайта ставить?
Почитай про explain и оптимизацию ключей.

 

[zaartix]

Автор оригинала: clevel
Что тебе мешает:
1. реализовать поиск города по айпишнику через базу и через текствоый файл, а потом сравнить результаты по скорости?

2. разбить таблицу на две - и замерить скорость поиска. Потом сравнить со скоростью выборки, когда одна таблица?
Народ тут активно в сое время обсуждал тем - что скорость поиска первичного по фиксированной (длине строки) таблице намного выше, чем по не по фиксированной.

Ну и ключи у тебя странно сформированны к таблице. Зачем ключи по id сайта ставить?
Почитай про explain и оптимизацию ключей.

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

2. понял, а фиксированная длина - это числовое или md5?

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

 

[clevel]

фиксированная длина строки таблицы - это когда все поля числовые + char. нету всяких text,varchar и др. полей с переменной длиной.

Поэтому скорость поиска данных по такой таблицы выше. Ибо в индексе хранится номер строки. И высчитать его можно по формуле длина строки*на порядковый номер строки.