Программирование, т. 7

Подскажите пожалуйста за архитектуру   
Есть зарождающийся большой проект, в котором будет великое разнообразие логики работы с данными(загрузка данных из файлов различных форматов, обработка этих файлов по крону, обращения к апишкам всех сортов, перезагрузка/удаление данных за периоды и тд). Каким образом наиболее пиздато(эффективно && расширяемо) реализовать логгирование происходящего? Для каждого типа действия пилить таблицу в БД с описанием случившихся событий? 

На анриле 4 дохрена чего идет в лог и туда оно идет с типом лога (error/warning/info) и откуда(модули разные), офк потом это все легко можно фильтерить если нужно.

общее для всех строк лога + критерии поиска в колонки таблицы, а остальное можно в колонку сплошным текстом\хмл\жсон\говном\етц.

Всё равно в 99% случаев ты будешь эти данные только доставать чтобы показать юзеру, раз их структура еще не определена.

Не, вывод-то понятно
Мне интересно как хранить такие разношёрстные данные

А зачем прям бд для всего этого, почему нельзя просто текстом с ключевыми словами по типу того как хтмл работает для типов данных ([f]3.14f[/f], ну а потом парсить тот текст как нужно.

Тяжко представить, как организовать что-то такое массивное. Вот на примере: пользователь залил файл формата xlsx, а затем этот файл спустя 10 минут распарсился автозадачей неудачно, ебанув в процессе. Как выглядит логгирование такого? Исходя из твоего сообщения это будет что-то вроде 
[t]10.07.2017 10:00:30[/t] Файл [f]pizda.xlsx[/f] залит пользователем hui с результатом [r]успешно[/r] 
[t]10.07.2017 10:10:30[/t] Файл [f]pizda.xlsx[/f] распаршен автозадачей с результатом [r]въебало[/r]  ?
А если в этот лог врывается что-то не-такое-как-все типа обращения к апи с несколькими доп. тегами? А если таких вариантов происходящего ещё 10? Типа сохранить-то я всё это может и смогу, но не ебанусь ли я потом писать парсер всего этого, чтоб можно было фильтровать? 

Изменено 10 июля 2017 пользователем Feanaro

А как ты организуешь это по другому, я в бд вообще не шарю и ниразу в глаза не видел, но разве можно там динамически генерить ключевые данные для каждой строки?
Тип у тебя один ивент и именем файла и пользователем, второй с результатом а третий вообще с какой то рандомной хуйней, как это можно сохранить?

Я в анриле парсю описание спелов например именно таким подходом, оригинальная строка написанная дизайнером в таблицу с тагом, UI знает какой таг кокому стату пренадлежит.
В итоге "Ability Cooldown: [float.cooldown]." парсится и берет текущие данные прям из абилки и выводит их в интерфейс, чтоб дизайнер и переводчик не лез каждый апдейт в текст.
Это единственный подход к такого рода задачам который я знаю, вот о нем и говорю. У меня это быстро все ибо [float.cooldown] там же на месте парсится еще раз под индекс статы у персонажа, так что поиска никаого нет, просто берется переменная за индексом.

А как ты организуешь это по другому, я в бд вообще не шарю и ниразу в глаза не видел, но разве можно там динамически генерить ключевые данные для каждой строки?

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

я когда-то юзал БД для логгирования событий (ток это было лет 6-7 назад если что), это в принципе неплохо, но есть свои минусы

можно например пихать в разные таблицы, по таблице на каждый тип лог-записи

можно сделать одну, где все общие поля будут выведены отдельно (таймстамп, айди), будет поле "тип события" и поле "описание" куда пихается всё что не подадает под предыдущие поля

 

основной плюс БД что можно лог легко просматривать если запилить ему минимальный UI, у тебя будут в руках фильтры по таймстампу, типам событий, а больше толком ничего и не надо от лога (обычно)

проблемы начинаются если лог стаёт слишком большим

Изменено 11 июля 2017 пользователем TheDeadSkin

Ну для питона например есть сентри, сервис куда отправляются логи об ошибках и там уже можно их через сайтик смотреть, уведомления получать и так далее

В других средах я хз как делают, но вообще специальные бд для логов есть 100%

про logstash когда-то чето слышал, но не помню ничего, может стоит посмотреть
 

Подскажите какую среду разработки для питона удобнее/лучше pycharm или visual studio?

Изменено 11 июля 2017 пользователем zEnergie

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

Подскажите пожалуйста за архитектуру   

Есть зарождающийся большой проект, в котором будет великое разнообразие логики работы с данными(загрузка данных из файлов различных форматов, обработка этих файлов по крону, обращения к апишкам всех сортов, перезагрузка/удаление данных за периоды и тд). Каким образом наиболее пиздато(эффективно && расширяемо) реализовать логгирование происходящего? Для каждого типа действия пилить таблицу в БД с описанием случившихся событий? 

если вам важна производительность + логгирование данных важно - БД плохой вариант

аппенд в файл и потом парсинг-обработка его на чем-то типа ELK 

вопрос что вам нужно

Тяжко представить, как организовать что-то такое массивное. Вот на примере: пользователь залил файл формата xlsx, а затем этот файл спустя 10 минут распарсился автозадачей неудачно, ебанув в процессе. Как выглядит логгирование такого? Исходя из твоего сообщения это будет что-то вроде 

[t]10.07.2017 10:00:30[/t] Файл [f]pizda.xlsx[/f] залит пользователем hui с результатом [r]успешно[/r] 

[t]10.07.2017 10:10:30[/t] Файл [f]pizda.xlsx[/f] распаршен автозадачей с результатом [r]въебало[/r]  ?

А если в этот лог врывается что-то не-такое-как-все типа обращения к апи с несколькими доп. тегами? А если таких вариантов происходящего ещё 10? Типа сохранить-то я всё это может и смогу, но не ебанусь ли я потом писать парсер всего этого, чтоб можно было фильтровать? 

elk и полнотекстовый поиск

а в логи сбрасывать произвольный json (или key-value)

что лучше выбрать зависит от многих параметров

какая нагрузка

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

какая цель логгирования

какие есть спецы в команде

 

но так кажется elasticSearch подходит

Изменено 11 июля 2017 пользователем Just.Doit

а python курсы есть какие-нибудь годные ?

или обучалки там.

то что в первом посте не подходит

 

 

если вам важна производительность + логгирование данных важно - БД плохой вариант

Почему? 

 

если вам важна производительность + логгирование данных важно - БД плохой вариант

 

Почему?

 

не эксперт, но мне кажется что файловая система производительнее и надёжнее чем файловая система вместе с бажагом юзлессного для логов функционала БД

 

если вам важна производительность + логгирование данных важно - БД плохой вариант

 

Почему? 

 

ну производительность как требование дает то что нужно делать запись логов асинхронно (чтобы никак не мешало работе основного приложения), а важность логгирования дает то что нельзя проебать логи (соотв их нужно персистить чтобы если база затупит или упадет не проебалось логов за 1-5-10-180 минут.

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

в итоге вы изобрели велосипед из ELK

 

если в смысле БД как просто конечное хранилище данных - ну да, только бд и подойдет (не обязательно реляционная), хранить где-то всёравно надо

Изменено 11 июля 2017 пользователем Just.Doit

 

А как ты организуешь это по другому, я в бд вообще не шарю и ниразу в глаза не видел, но разве можно там динамически генерить ключевые данные для каждой строки?

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

я когда-то юзал БД для логгирования событий (ток это было лет 6-7 назад если что), это в принципе неплохо, но есть свои минусы

можно например пихать в разные таблицы, по таблице на каждый тип лог-записи

можно сделать одну, где все общие поля будут выведены отдельно (таймстамп, айди), будет поле "тип события" и поле "описание" куда пихается всё что не подадает под предыдущие поля

 

основной плюс БД что можно лог легко просматривать если запилить ему минимальный UI, у тебя будут в руках фильтры по таймстампу, типам событий, а больше толком ничего и не надо от лога (обычно)

проблемы начинаются если лог стаёт слишком большим

 

можешь бэкапить табличку и чистить

в чем проблема то?

 

 

если вам важна производительность + логгирование данных важно - БД плохой вариант

 

Почему?

 

не эксперт, но мне кажется что файловая система производительнее и надёжнее чем файловая система вместе с бажагом юзлессного для логов функционала БД

 

ты потом охуеешь как эта штука будет вести себя когда логов станет очень много.

тут сразу возникает куча вопросов: как ты будешь хранить записи? каждую запись - в отдельный файл? файл может расти до какого-то размера?

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

лог на диске - это по сути помойка для галочки

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

 

откуда мне знать? я специально оба раза указал что мой опыт в этом на 100% кустарный

 

 

А как ты организуешь это по другому, я в бд вообще не шарю и ниразу в глаза не видел, но разве можно там динамически генерить ключевые данные для каждой строки?

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

я когда-то юзал БД для логгирования событий (ток это было лет 6-7 назад если что), это в принципе неплохо, но есть свои минусы

можно например пихать в разные таблицы, по таблице на каждый тип лог-записи

можно сделать одну, где все общие поля будут выведены отдельно (таймстамп, айди), будет поле "тип события" и поле "описание" куда пихается всё что не подадает под предыдущие поля

 

основной плюс БД что можно лог легко просматривать если запилить ему минимальный UI, у тебя будут в руках фильтры по таймстампу, типам событий, а больше толком ничего и не надо от лога (обычно)

проблемы начинаются если лог стаёт слишком большим

 

можешь бэкапить табличку и чистить

в чем проблема то?

 

 

если вам важна производительность + логгирование данных важно - БД плохой вариант

 

Почему?

 

не эксперт, но мне кажется что файловая система производительнее и надёжнее чем файловая система вместе с бажагом юзлессного для логов функционала БД

 

ты потом охуеешь как эта штука будет вести себя когда логов станет очень много.

тут сразу возникает куча вопросов: как ты будешь хранить записи? каждую запись - в отдельный файл? файл может расти до какого-то размера?

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

лог на диске - это по сути помойка для галочки

 

все зависит от того что нужно и какие требования

иногда помойки хватает

иногда кластера эластика не хватает