Насколько надежен flock при очень большом кол-ве обращений?

[zxc]

Насколько надежен flock при очень большом кол-ве обращений?

Можно доверять flock'у хранить временные БД (с последующим импортом в MySQL) при большом (очень большом) кол-ве обращений?
Стоит ли вообще использовать временные файлы для хранения данных, которые каждые 15 минут будут импортироваться в MySQL? Или использовать MySQL напрямую?

при этом соотношение вставок и чтения записей MySQL ~1:5, и будет задействовано сразу 4 таблицы

 

[Tor]

flock'у хранить временные БД

это как?

большом (очень большом) кол-ве обращений

это сколько?

соотношение вставок и чтения записей MySQL ~1:5

это не имеет, скорее всего, большого значения

 

[zxc]

это как?

$f = fopen('file.txt', 'a');
flock($f, LOCK_EX)
fwrite($f, "newline\n")
flock($f, LOCK_UN);
fclose($f);

это сколько?

~10-15 запросов/сек. много это или нет для flock я не знаю

это не имеет, скорее всего, большого значения

напишу полностью описание моей задачи используя два варианта (временные файлы + MySQL или напрямую MySQL)

если напрямую использовать MySQL:
собирается:
1. статистика по user-агентам (сначала "вслепую" апдейтится кол-во хитов для user-агента, и если mysql_affected_rows вернула 0, - вставка нового значения)
2. статистика по языкам (также)
3. статистика по реферам (также)
4. статистика по IP (стоит индекс unique на колонку IP, сначала вслепую пытаюсь вставить ip (формат ip2long), если функция mysql_affected_rows вернула 0 - обновляю кол-во хитов для этого IP адреса)

в 0:00 делаю селект по всем таблицам, статистику первых трех сохраняю по файлам, 4-ая группируется по хитам и уникам и сохраняется в окончательной сводной таблице за дату. все 4 таблицы сбрасываются

если не использовать MySQL:
Для каждой из статистики пишу отдельный файл за дату, при запросе скрипта идет только добавление новой строки, при этом файл блокируется функцией flock;
раз в 15 минут файлы сортируются на кол-во хитов для каждой уникальной строчки:

было:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

стало:

array (
 'str' => 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)',
 'hits' => 3
);

эти значения добавляются/апдейтятся в MySQL;
файлы временной БД ресетятся;

в 0:00 делаю тоже самое что и в первом случае.

 

[agx]

Думаю, что лучше сразу писать данные в БД, и не хранить их в файлах. Или у тебя какая-то специфичная задача?

 

[Tor]

15 подобных запросов в секунду - это совсем не много

 

[zxc]

15 подобных запросов в секунду - это совсем не много

каких запросов? mysql или fopen?


если смотреть на оба варианта как примерно одинаковые:
какой всеже вариант в моей задаче, более рационален?

 

[Tor]

каких запросов? mysql или fopen?

первое

какой всеже вариант в моей задаче, более рационален

конечно база

 

[Demiurg]

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

 

[zxc]

У меня скромный опыт работы с MySQL, однако у меня часто ломались базы на совсем не сложных запросах, в связи с этим вопрос: нуждается ли MySQL в аналогичной функции LOCK TABLE?

подход верный.

какой именно?

 

[Tor]

нуждается ли MySQL в аналогичной функции LOCK TABLE

вне зависимости от твоих потребностей, у мускула есть эта функция

а вот нужна ли она тебе, это уже зависит от твоих потребностей

 

[zxc]

да конечно, я хотел спросить нуждается ли моя задача в этой функции?

 

[Tor]

если ты просто логи пишешь в базу, то нет
если обновляешь в несколько потоков, то, скорее, да

 

[betik]

Кхм.. А сервер СУБД МуСКЛ разве сама не разбирается чего лочить, а чего нет?
Во всяком случае на WIN NT создаётся такое впечатление что СУБД сама за всем следит...

 

[voituk]

betik: так оно и есть, но только в самом обычном случае.

А вот если задача требует блокирова таблицу до определенного момента, то откуда МуСКЛ знает чего тебе надо, и че у тебя за логика такая.
Приер задачи (надуманный): Надо запретить добаление/изменение данных, пока происходят какие-то пересчеты или переносы данных.