Меню
Что нового?

Алгоритм логов.

  • Автор темы Автор темы Opik
  • Дата начала Дата начала

Opik

Новичок
Алгоритм логов.

Не стал поднимать свою старую тему. там много лишнего. Надеюсь не смертельно =)
К делу. Не буду писать как сделано сейчас. сделаю как думаю.

Собственно какие логи:
Логи боев, кто, кого, во сколько и куда ударил.

Хочу сделать на 1 бой - 1 файл. "свежие" удары писать сверху. (Т.к в текущем бою нужно выводить 10-15 последих записей). И гораздо проще серверу прочитать первые 10 строк, чем последние.

Ещё один вопрос - ЧТО хранить в логах.
а) готовый текст, который нужно просто вывести. (проблема в объеме)
б) "код" текста. т.е хранить через разделитель только данные. и потом их постоянно собирать в читабельный вид (когда логов много - довольно частая операция, которую в принципе можно избежать при методе а) . т.е меньше грузить и без того нагруженный сервер.) не самое узкое место, но тем не менее.

Как считаете?
 
100 боев - большая таблица. с уже замедленной скоростью обработки.
100 боев - 100 файлов - всё равно в принципе. файлы обрабатывать. объем сравнительно не большой и должно быть всё шустро. собтвенно поэтому и склонняюсь к файлам.
 
Тоже кажеться, что MySQL-сборка - самый оптимальный вариант.
 
Opik
> ...
Копирайт поставишь? :D
На самом деле файлы для данной задачи в любом случае медленее чем СУБД. Не спрашивай почему, просто поверь.
 
Ладно. верю. пусть будет медленее.
Но как тогда сделать? Ведь в 1 таблицу не будешь же все городить. Можно конечно разбить на 2 таблицы - текущая, и архивная. Других вариантов видимо нет.
 
Сколько будет записей в таболице? Я не думаю, что больше 100 тыс. При 100 тыс. тормозов точно не будет... По любому, если будешь писать в файлы, в последствии будет тормозить файловая система.. а это ещё хуже.
 
Opik
В одну таблицу. Для снижения нагрузки на СУБД при запросах, время от времени переноси в архивную таблицу записи с законченными боями.
Solid
> При 100 тыс. тормозов точно не будет...
No comments.
 
Ну сейчас у меня сделано так: текущий лог идет в мемкеш.
а потом уходит в базу.
В базе уже 2617830 записей. что больше 100 тыс =)))
файловая система тормозить не будет, если разбивать по папкам (я так думаю. хотя может обишаюсь)
 
Автор оригинала: white phoenix
Opik
В одну таблицу. Для снижения нагрузки на СУБД при запросах, время от времени переноси в архивную таблицу записи с законченными боями.
Solid
> При 100 тыс. тормозов точно не будет...
No comments.
Нажмите для раскрытия...
Хм... Если таблица вида:
id, bid, text
где id - int, bid - int, text - char(255)
томрозов не будет точно, конечно если машина не pent II 200mhz с 32мб ОП на борту. Правда с другой стороны ещё сильно зависит от настроек mysql сервера, но т.к. я предполагаю, что сервер настроен стандартным образом, т.е. storage engine ISAM или MyISAM.
При >100 записей такого вида уже потребуется BerkeleyDB + большие выделения оперативной памяти.

-~{}~ 27.01.06 01:11:

Кстати, смотрел benchmark'и mysql и sqlite: иногда lite выигрывает. Так что, думаю, стоит попробовать.
Но файловую систему использовать строго не рекомендуется. Торможение - раз, во вторых сложность обработки (составление отчётов) и т.д. Много минусов, плюсов почти нет.
 
Я тут единственный думаю, что БД все в файлах хранит? :)))
А что бы из юазы быстрее дергать информацию, надо некоторые поля индексировать.
 
Renny, в некоторых случаях индексация даёт больший вред чем пользу. При частых вставках - перестройка индексов будет занимать львиную долю времени и бывает на больших таблицах выгоднее отказаться от индексов, чем использовать их. Но тут нужно смотреть на результаты эксплейна.
 
Solid
Ты правда такой каким кажешься, или ты придуриваешься?
Renny
>Я тут единственный думаю, что БД все в файлах хранит? )
Ты прав. Но в СУБД более быстрый механизм, и кеширование. При работе с файлами надо каждый раз писать на жесткий диск, а это очень кладно, в то время как СУБД сносит буфера на диск лишь время от времени.
>А что бы из юазы быстрее дергать информацию, надо некоторые поля индексировать.
Индексы хороши когда преобладают запросы выборки (SELECT), а когда частый (INSERT, UPDATE), то можно серьезно проиграть в скорости.
 
Интересно, чем это я придуриваюсь? То что говорю, что то что думаю и знаю? Мне кажется, это не тот форум, где можно выяснять отношения. Так что давай впредь больше не будем касаться данной темы.

-~{}~ 27.01.06 07:51:

Впринципе у меня всегда ответы такие, какие вопросы. Так что ты не в ту сторону смотришь.

-~{}~ 27.01.06 07:57:

Только лишь кеширование и "более быстрый механизм"? Смотря какой движёк для хранения информации выберешь.
...Данные можно расположить в оперативной памяти, от чего скорость выборки/вставки возрастает даже не в несколько раз.

-~{}~ 27.01.06 08:00:

Впринципе то, что тебе надо: http://dev.mysql.com/doc/refman/5.0/en/archive-storage-engine.html
+ компрессия
- медленный select
 
Re: Алгоритм логов.

Автор оригинала: Opik
Хочу сделать на 1 бой - 1 файл. "свежие" удары писать сверху. (Т.к в текущем бою нужно выводить 10-15 последих записей). И гораздо проще серверу прочитать первые 10 строк, чем последние.
Нажмите для раскрытия...
Серверу как раз совершенно все равно, последние или первые строки читать. А вот писать в конец однозначно проще, чем в начало.
 
Как я понимаю, у тебя есть таблица, где есть слова:
id - int
word - char(255)
примерно так, да?
Тогда поставь barkley engine, выставь там побольше выделяемой памяти и вперёд.
battle: id, sid (step)
step: id, wid (word)
 
Войдите или зарегистрируйтесь для ответа.
Сверху