Популярни търсения

Ticketa

Registered
Привет,
в момента обмислям два варианта за създаване на "популярни търсения" - въпроса е, кой начин ще е най-правилен и въобще дали съм на прав път (това някой по кадърен ще го каже в темата :D :) )

Вариант 1:
- създавам нова таблица , в която записвам всяко едно търсене извършено през търсачката, като тези които се "дублират" имат колона с брояч на търсенията (тук имам опасението, че това ще затормозява излишно търсенето на клиента, както и че ще затормозява излишно базата данни)

Вариант 2:
- използвам текущата таблица с категории и градове/села/квартарили, добавям нова колона с брояч и при всяко търсене в дадена категория или град/село/квартал добавям +1 , по този начин ще изведа в сайта "най-популярни търсения: ИМЕ_НА_КАТЕГОРИЯ В ИМЕ_НА_ГРАД" (тук имам съмнение, че може също да се затормози базата данни? или ми е излишно притеснението? Трафика на реални онлайн потребители е от 1360 до 3490 в пикове) не е много, не е и малко.

Вариант 3: оставам на вас. (обмислях вариант да се създадът тагове и т.н. но не смятам, че отговаря на изискванията, а именно - популярни търсения)

Какво бихте ми препоръчали?

Търсачката предлага: търсене по думи/изречения , търсене по категории, търсене по градове/села/квартали(които ги имам налични)
 
Замисли се кой вариант е най-лесен за разширяване в случай, че други изисквания се наложат.

Аз бих използвал вариант 1.
Един ден може да има изискване да се добави анализ на търсенията по дата. По-лесно е да добавиш тази информация в нова таблица, защото това, което ти дава добавянето на колона е само един брояч. Нито можеш да записваш уникални търсения за 24ч., нито по IP, а ако имаш потребители не можеш да запишеш и кой потребител какво е търсил.

Представи си, че имаш потребители и също искаш да им представиш история на търсенията им.

Базата данни няма с какво да се затормози, ако е нормализирана и индексирана. Един ден, ако се затормози, винаги можеш да имплементираш кеширане и примерно да обновяваш резултати на 5-10 минути. В твоя случай може и по-рядко. Едва ли ще се налага във всяка една секунда при всеки един рефреш на страницата, да правиш трип до базата данни, за да вземеш данните.
 
А защо топлата вода?
Дори и системата която ползва форума го има вградено?
 
Предполагам ти трябва full-text search но няма да имаш проблеми според мен. Ако базата ти стане дооооста голяма и ще имаш проблеми за напред то може още от сега да си сложиш Sphinx и няма да имаш никакви ядове. Тествано работи безотказно за милиони записи в бази от по 6 TB. Тествано е на такава база в Raid 6 и си лети цялото нещо.
 
Вариант едно е най-добрият. Ако имаш търсене по много критерии, то е удачно да ги сортираш и да ги сериализираш някак си. Така ще си сугурен, че всеки път когато влезнат данните, то ще са в правилният ред и няма да имаш ситауция където {a:a , b:b } i { b:b , a:a}
 
Ако имаш 5000 потребителя, които търсят нещо и ти изпълниш 5000 заявки да ти слага +1 на брояча + заявката за търсене в базата... Не ми се мисли.

По-скоро да записваш търсенията в Redis..
 

Горе