Комментарии 39
поэтому не удивительно, что все три варианта используют SQLite
У меня сложилось впечатление что админы не знают про prometheus, про существование отдельного вида БД — Time-Series Database (который используется в prometheus). Если прям так необходимо написать своё решение руками, то для задачи можно выбрать или OpenTSDB, или InfluxDB, или еще какую-нибудь БД, такого же типа.
Просить сделать проект дачного домика, а потом спрашивать почему фундамент такой маленький, ведь я планирую тут построить небоскреб.
Это проблема того, кто ставит задание.
Вот только есть одна проблема — значительное количество Time-Series Database имеют проблему со вставкой назад. Например, в prometheus это сделать нормальными способами нельзя, насколько я знаю. Ну и с ними надо работать, я вот работаю с prometheus, но в этой задаче он помочь не может. А sqlite знают почти все.
Но я думаю, был упущен момент, что задача немного наркоманская и я очень плохо представляю, насколько надо быть странным, что бы настроить мониторинг так.
Olap cube? И любую статистику по срезам делать.
А если еще точность не очень важна, можно еще и запаковать.
Полагаю, при схеме "дельта-кодирование + lzma" (если загрузка ритмична или более-менее постоянна) можно получить дичайшее сжатие (в ~1000 раз) даже без потери точности (если загрузка процессора кодируется целым значением).
Если бы не команда QUERY, имело бы смысл делать препроцессинг, считать частичные суммы и прочие программистские оптимизации. Но с ней (и учитывая, что 1 секунду будут измерять по ней) смысл имеет только как-то похранить данные. А для этого имхо лучше воспользоваться стандартным решением под данные нужды — упомянутыми выше RouR Time-Series Database или любой другой БД, если о них пишущий не знает.
P.S. Pyhon поправьте))
А потом агрегировать данные разных группировок в случае полного попадания в запрошенный диапазон. К примеру просят 1год 3 месяца 4часа значит если год четко полный попал в диапазан — берем из индекса годов, что осталось смотрим целые месяцы и т.п.
Но в целом создание индексов это читерство, мы переносим время исполнения запроса в прошлое и обманываем замер скорости
На мой взгляд, вредно будет, лишь если кто-то решит подобные тестовые решения использовать в продакшене, но как бы, если у человека настолько выражена проблема с критичным мышлением, то он споткнется о любые грабли в любом месте.
В любом случае, это отдельная тема для обсуждения и оригинальным автором задачи был не я, поэтому не могу судить о мотивации HR, который ее выдал.
А вот в такой ситуации не надо придумывать велосипеды, а нужно развернуть ELK, и настроить Logstash на сбор логов из директорий.
Благодаря Docker-образам и большому количеству мануалов с примерами в сети, ELK можно развернуть примерно за пару часов и это будет работать отлично.
Сразу отвечу на комментарий Nomad1 выше: да, Elasticsearch нормально прожуёт структурированные данные и более того, в Kibana можно будет получить хорошую аналитику из этих данных.
А для "задачи на собеседование" годится любое из решений в статье, потому что если человек смог его написать — уже хорошо. В любом случае, в продакшене использовать любое из них одинаково не надо.
Та задача, что в статье — это one-off task. Хороший разработчик будет сразу исходить из этого факта и решит задачу максимально быстро. При этом допустим и плохой код, и медленный, пока он выполняется за разумное время. Измерять время работы кода тут бессмысленно, задача-то одноразовая, без разницы, выполнится она за три минуты или за секунду.
В такой формулировке задачи надо смотреть не на код и его производительность, а на другие признаки мастерства собеседуемого: спросит ли он про контекст задачи, уточнит ли требования поддерживаемости кода, предложит ли развернуть агрегатор логов, быстро ли напишет конечный скрипт.
Постановка задачи:
Мы интернет провайдер раздающий dial-up. У нас есть, скажем, 128 входных модемов объединенных в hunting группы по 16. Cisco 2511 помните? ;-)
Каждый модем может быть либо занят клиентом либо свободен. Время нахождения клиента на линии не может быть более 3-х часов.
Информация об этом сохраняется таблицу MySQL в следующем виде:
Timestamp, ID терминала, ID клиента, Время занятия линии в секундах.
Информация хранится несколько месяцев.
Требуется построить почасовой суточный график загрузки всего пула с помощью одного SQL запроса. Без сохраненных процедур и view. При этом нужно учитывать какой процент времени в течении каждого часа модем был свободен, пользователь мог прийти позавчера и отсоединится вчера и так далее. Так же нужно учитывать что этот запрос должен отрабатывать в разумное время на SPARCStation 5 c 70MHz процессором. ;-)
Как я эволюцию админов в программистов измерял