Ние правим нашата услуга за наблюдение на потребителите на VKontakte

Разбор или API

Знам, че за мнозина въпросът ще изглежда смешен, но все пак си струва да се обмисли, защото. половината от тези проекти работят върху анализиране.

Плюсове на анализирането

  • практика при използване на регулярни изрази ;)

Минуси на анализирането

  • прости молби - прости отговори
  • за една заявка към API можете да получите информация за не повече от 1000 потребители
  • ако възникне грешка, можете да разберете защо и да я отстраните правилно
  • бързо време за изпращане на заявка и получаване на отговор (до 3 секунди)
  • получаваме отговора в един от най-удобните формати: XML или JSON
  • в допълнение към статуса можете да получите и много друга информация за потребителя
  • наличие на подробна документация

Против на API

Мисля, че вече е очевидно за всички, чеимате нуждада използвате API. За достъп до метода getProfiles API е достатъчно да направите заявка https://api.vkontakte.ru/method/getProfiles?u >

Принципът на работа на тази функция:на входа получаваме името на метода, който ще се извиква и масив с необходимите за метода параметри. След това формираме подписаsigчрез сортиране на всички параметри по азбучен ред във възходящ ред ислепванев низ катоparam1=value1&param2=value2&.. След това функцията изпраща заявка и в отговор получаваме отговорJSON, койтодекодирамев масив и накрая го връщаме.

Правилна организация на структурата на базата данни

Ако не искате да възстановявате базата данни няколко пъти за по-големи натоварвания, трябва незабавно да разчитате на голям брой потребители. Нека да разгледаме случая, когато имаме 3000 проследени потребители, които ще се актуализират на всеки 2 минути. Тези. Наза всеки потребител заедин денще получим30*24=720записа, а за всички заедно вече е720*3000=2 160 000записа! Твърде много, нали? Тези, които разбират как можете да намалите броя на записите със 70-80%, прочетете статията до края, защото десертът се сервира следтежкомазно пиле;) И така, мисля, че всеки има няколко различни структури:

uid— VKontakte IDfirst_name— имеlast_name— фамилиястатус— статус на потребителя (0 — офлайн, 1 — онлайн)datetime— време за проверка от тип ГГГГ-ММ-ДДТ hh:mm:ss±h (според към ISO 860 1, но всеки може да съхранява както иска!) илиunix_timestampнапримерtable_num— номер на таблицаОпция 1.В таблицаusersсъхранявамеuid,first_name,last_name<1 1>, в таблицапроверки<1 4> съхраняваме резултатите от проверките във форматаuid,datetime,статус.

Недостатъци:

  • голям брой записи (на първия ден -2 160 000, след седмица вече -15 120 000, можете ли да си представите колко ресурсоемко ще бъде разглеждането на записите? ;)
  • изтриването на потребител ще отнеме доста време
  • с чести изтривания, голям процент на фрагментация
  • ако няколко души гледат статистика едновременно, сървърътще се огъне
Плюсове:
  • най-малък брой маси
Опция 2.В таблицатаusersсъхранявамеuid,first_name,last_name, отделна таблицаuNNNNN(къдетоNNNNNе потребителският идентификатор) се създава за всеки потребител със следната структура:da tetime,състояние.

Недостатъци:

  • колкото повечепотребители - колкото повече маси
Плюсове:
  • една таблица ще съхранява данните на един потребител, което намалява броя на записите
  • просто изтриване на потребител - DROP TABLE `u123456`
Вариант 3.В таблицатаusersсъхранявамеuid,first_name,last_name, за всеки ден се създава отделна таблица2011-06-10със структура, подобна на първата опция:uid,дата и час,състояние.

Недостатъци:

  • колкото по-дълго ще работи услугата, толкова повече маси
  • ще бъде проблематично да се покаже статистика за посетителите за седмица, месец и 3 месеца вече е напълно страховито.
  • сложно изтриване на потребители - трябва да преминете през всяка таблица
  • с чести изтривания - голям процент на фрагментация
Плюсове:
  • в началото не толкова голям брой маси, отколкото във 2-рия вариант
  • удобно е едновременно да преглеждате посещения на ден от няколко потребители
Реших да избера вариант номер 2. Той ми хареса най-много. Но за тези, за които тези опции не са достатъчни, ще осигуря още няколко екзотични.Екзотичен 1.В таблицатаusersсъхранявамеuid,first_name,last_name, има още 9 таблици с имеendN(където N е номерът на таблицата от 1 до 9), със следната структура:uid,дата и час,състояние. Потребителските данни се съхраняват в различни таблици, в зависимост от последната цифра на техния ID, т.е. ако следваме потребителя с id 6018035, тогава записите на неговите посещения се съхраняват в таблицатаend5.Защо с последната цифра?Сега да отидем ID 1NNNNNNNN и първата цифра ще се променя за много дълго време, така че таблицата end1 ще бъде най-натоварена с този метод. И вземане на последнотофигура, ние максимално разпределяме броя на потребителите в таблицата.

Недостатъци:

  • относително голям брой записи в една таблица
  • с чести изтривания - процентът на фрагментация е много по-висок, отколкото при опция № 3
  • проблематично е да видите статистика за два дни или повече.
Плюсове:
  • фиксиран брой маси
  • всичко е подредено в таблици
Екзотичен 2.Този метод е много подобен на предишния, но е по-гъвкав. В таблицатапотребителисъхранявамеu >Недостатъци:
  • в зависимост от броя на масите
Плюсове:
  • в зависимост от броя на масите

Принцип на действие

Когато актуализирате всички потребители (нека ви напомня, имаме 3000 от тях), трябва да създадете списъци, всеки с 1000 души (не обичам да го приемам направо, затова правя 990, никога не се знае), списъци във формат uid1,uid2,uid3, например 1,6018035,133895545 и да изпратите заявка до методаAPIgetProfilesв допълнителни полета (полета), указващиonline, т.е. когато използвам моята функция, ще изглежда така:

При успех скриптът ще изведе нещо подобно: Array ( [response] => Array ( [0] => Array ( [uid] => 1 [first_name] => Pavel [last_name] => Durov [online] = > 1 )

[1]=> Масив ( [uid] => 6018035 [first_name] => Roman [last_name] => Smirnov [online] => 1 )

[2]=> Масив ( [uid] => 133895545 [first_name] => Dima [last_name] => Hex [online] => 0 )

) Получените потребителски статуси се записват в базата данни, според избраната опция за организация, в моя случай опция №2.

Някои трикове

1.Защо трябва да записваме резултатите от всички проверки? В крайна сметка можете да записвате само когато статусът е променен. Тези. ако потребителят е станал онлайн в12:00и в12:30вече е офлайн, тогава без измама ще има 15 влизания онлайн и след това офлайн влизания. С този трик ще имаме едно онлайн влизане ("12:00", "1") и едно офлайн влизане ("12:30", "0"), така че можем да намалим броя на влизанията с90%, особено когато потребителят е влязъл веднъж. Без трика ще има720записа за този ден, с трика —2записа, един за влизане онлайн, втори за напускане.

2.Ако забележите, VKontakte има онлайн таймаут. Това време варира от 12 до 16 минути. Тези. ако потребителят не е извършил никакви действия в рамките на 12-16 минути от момента на влизане, тогава той ще се счита за офлайн, ако са изминали само 10 минути (дори ако вече е изключил компютъра), той все още се счита за онлайн. Сега нека помислим ... Можем ли да използваме това? Когато даден потребител е влязъл и нашият скрипт види това, ние ще поискаме неговия статус само следващия път след 10 минути (като по този начин спестяваме 4 заявки за този потребител). Този трик не е толкова важен, трик#1помага повече

Който се интересува от изходните кодове- готов да предостави, пишете на сапунаadmin[@]ubar.su

Ако не разбирате нещоилинещо липсва, не се колебайте да пишете, аз ще отговоря на всички въпроси / ще допълня статията.