Comments 39
поэтому не удивительно, что все три варианта используют SQLite
У меня сложилось впечатление что админы не знают про prometheus, про существование отдельного вида БД — Time-Series Database (который используется в prometheus). Если прям так необходимо написать своё решение руками, то для задачи можно выбрать или OpenTSDB, или InfluxDB, или еще какую-нибудь БД, такого же типа.
В условии используется стандартная ловушка подобных тестов: говорится, что к примеру, у нас есть 1000 серверов по 2CPU и они создают по 1440 записей за день. И сразу человек начинает думать, что этим все и ограничится, нужно решение для работы всего с 3 миллионами записей, это очень мало и все можно сделать весьма быстро. Хотя никто и не смотрит, что постановка расплывчата и данных может быть намного больше. Я думаю, если бы было сказано о миллиардах записей в сотнях гигабайт логов, то никто бы на SQLite и не смотрел, пропала бы вся интрига.
это игра из разряда «Детектив». Вы пишите детективный роман, перечисляете улики и предоставляете читателю догадаться о том, какой же садовник убийца. А перед раскрытием добавляете, что это оказался Том, сигаретный окурок которого был заслонен телом убитого. Поменять условие в любую сторону — это же так умно!
Просить сделать проект дачного домика, а потом спрашивать почему фундамент такой маленький, ведь я планирую тут построить небоскреб.
Просить сделать проект дачного домика, а потом спрашивать почему фундамент такой маленький, ведь я планирую тут построить небоскреб.
Это не проблема того, кто пишет код.
Это проблема того, кто ставит задание.
Это проблема того, кто ставит задание.
Вот только есть одна проблема — значительное количество Time-Series Database имеют проблему со вставкой назад. Например, в prometheus это сделать нормальными способами нельзя, насколько я знаю. Ну и с ними надо работать, я вот работаю с prometheus, но в этой задаче он помочь не может. А sqlite знают почти все.
Но я думаю, был упущен момент, что задача немного наркоманская и я очень плохо представляю, насколько надо быть странным, что бы настроить мониторинг так.
Как вариант, пропарзить все данные, отгрупировать по ип-процессор и создать чисто таймлайн загруженности процессора, 1 байт на 1 минуту/проц, за день набежить около 3мб, за год 1гб. А если еще точность не очень важна, можно еще и запаковать.
Olap cube? И любую статистику по срезам делать.
А если еще точность не очень важна, можно еще и запаковать.
Полагаю, при схеме "дельта-кодирование + lzma" (если загрузка ритмична или более-менее постоянна) можно получить дичайшее сжатие (в ~1000 раз) даже без потери точности (если загрузка процессора кодируется целым значением).
Еще одно очень большое допущение — что сервера всё время исправно работают, и логи исправно создаются.
Если бы не команда QUERY, имело бы смысл делать препроцессинг, считать частичные суммы и прочие программистские оптимизации. Но с ней (и учитывая, что 1 секунду будут измерять по ней) смысл имеет только как-то похранить данные. А для этого имхо лучше воспользоваться стандартным решением под данные нужды — упомянутыми выше RouR Time-Series Database или любой другой БД, если о них пишущий не знает.
P.S. Pyhon поправьте))
Если бы не команда QUERY, имело бы смысл делать препроцессинг, считать частичные суммы и прочие программистские оптимизации. Но с ней (и учитывая, что 1 секунду будут измерять по ней) смысл имеет только как-то похранить данные. А для этого имхо лучше воспользоваться стандартным решением под данные нужды — упомянутыми выше RouR Time-Series Database или любой другой БД, если о них пишущий не знает.
P.S. Pyhon поправьте))
Почему же можно было делать оптимизации с группировкой за год/за месяц/за день/за час и тд
А потом агрегировать данные разных группировок в случае полного попадания в запрошенный диапазон. К примеру просят 1год 3 месяца 4часа значит если год четко полный попал в диапазан — берем из индекса годов, что осталось смотрим целые месяцы и т.п.
Но в целом создание индексов это читерство, мы переносим время исполнения запроса в прошлое и обманываем замер скорости
А потом агрегировать данные разных группировок в случае полного попадания в запрошенный диапазон. К примеру просят 1год 3 месяца 4часа значит если год четко полный попал в диапазан — берем из индекса годов, что осталось смотрим целые месяцы и т.п.
Но в целом создание индексов это читерство, мы переносим время исполнения запроса в прошлое и обманываем замер скорости
Довольно много таких «теоретических» статей на этом ресурсе. Есть стойкое ощущение от них, что их авторам просто занять себя нечем
Есть стойкое ощущение, что авторы могут сами решить, как им тратить свое время. А если их время и эксперименты окажутся полезными кому-либо еще — сообщество только выиграет. Если нет — статья утонет сама по себе, тоже не принеся вреда.
Не соглашусь по поводу безвредности. Люди, которые не понимают, что статья на самом деле бесполезна, будут пытаться подражать. Вред будет нанесен именно им
Будут пытаться писать статьи, бенчмарки, учиться использовать базы данных, читать о time-series DB, изучать разные точки зрения в комментариях? И это по-вашему вредно? Позвольте выразить мое полное несогласие с данной мыслью.
На мой взгляд, вредно будет, лишь если кто-то решит подобные тестовые решения использовать в продакшене, но как бы, если у человека настолько выражена проблема с критичным мышлением, то он споткнется о любые грабли в любом месте.
На мой взгляд, вредно будет, лишь если кто-то решит подобные тестовые решения использовать в продакшене, но как бы, если у человека настолько выражена проблема с критичным мышлением, то он споткнется о любые грабли в любом месте.
Собственно сами и подтверждаете, что ваша статья лишь для абстрактного «саморазвития», с реальными задачами мало пересекается
Конечно! Это же задача для собеседования, оценка возможностей и мышления кандидатов, а не попытка решить что-то их руками.
На хабре с месяц назад была хорошая статья про собеседования. Резюмируя ее и исходя из своего опыта — не стоит давать такие задачи для оценки специалистов. Во-первых, тратишь и свое время и время человека. Во-вторых, у человека может быть отличное от вашего мышление и можно отсечь хорошего кандидата из-за своих профессиональных пробелов
Там чуть ниже писали, что бывает, что у человека нет гитхаб профиля, нет доступных проектов, нет возможности оценить его уровень вообще. А исходя из моего опыта, неправильно поставленный вопрос на собеседовании может выбить из колеи и создать гораздо худшее мнение о кандидате. В то время как небольшое «домашнее здание» в целом безвредно, да и на его основе можно задать 100500 полезных вопросов. Особенно хорошо, когда подобные тестовые задачи оплачиваются.
В любом случае, это отдельная тема для обсуждения и оригинальным автором задачи был не я, поэтому не могу судить о мотивации HR, который ее выдал.
В любом случае, это отдельная тема для обсуждения и оригинальным автором задачи был не я, поэтому не могу судить о мотивации HR, который ее выдал.
Можно создать индекса по полю: год-месяц-день-час от поля timestamp. Тогда и память не будет сильно тратится и скорость может стать быстрее.
Точнее добавить в индекс.
Вполне может быть. К сожалению, у меня не вышло сделать такой объем данных и такие тесты, чтобы была существенная разница в формате индекса — при повторяющихся запросах, БД кеширует активный участок данных, значит нужен авто-тест, который генерирует много не пересекающихся запросов на большом промежутке времени и только так мы узнаем, эффективна ли вообще полная или частичная индексация по timestamp.
Мне кажется, наиболее «инженерным» подходом в решении данной задачи было бы предложить отказаться от записи логов в файл, переведя всё это на какую-то более-менее подходящую СУБД, а заодно ещё уточнить(и предложить свои?) способы использования и максимальное требуемое хранение данных. Вариант «мы тут каждую минусу создаём кучу файлов и для выборки их каждый раз долго и мучительно парсим», какой-то уж больно подозрительный.
Это и называется «задача для собеседования» — описать какую-то адскую ситуацию, которую нельзя исправить, но надо ее направить в разумное русло. Вот вам схожий вариант, о котором я когда-то слышал на одном из форумов: все access.log апачей с двух десятков веб-серверов пишутся на NFS шару, где должны складироваться и анализироваться.
Просто интересно, а почему не elastic search, например, или что-то подобное из готовых решений?
А вот в такой ситуации не надо придумывать велосипеды, а нужно развернуть ELK, и настроить Logstash на сбор логов из директорий.
Благодаря Docker-образам и большому количеству мануалов с примерами в сети, ELK можно развернуть примерно за пару часов и это будет работать отлично.
Сразу отвечу на комментарий Nomad1 выше: да, Elasticsearch нормально прожуёт структурированные данные и более того, в Kibana можно будет получить хорошую аналитику из этих данных.
А для "задачи на собеседование" годится любое из решений в статье, потому что если человек смог его написать — уже хорошо. В любом случае, в продакшене использовать любое из них одинаково не надо.
Чтож вы такие серьёзные. Мне кажется вполне нормальный тест, никто не говорит же что так нужно делать, но бывают подобные задачи, особенно в старых монолитах в условиях острой нехватки времени или ресурсов. Зато такие задачки дают наглядное представление о навыках программирования у человека.
Та задача, что в статье — это one-off task. Хороший разработчик будет сразу исходить из этого факта и решит задачу максимально быстро. При этом допустим и плохой код, и медленный, пока он выполняется за разумное время. Измерять время работы кода тут бессмысленно, задача-то одноразовая, без разницы, выполнится она за три минуты или за секунду.
В такой формулировке задачи надо смотреть не на код и его производительность, а на другие признаки мастерства собеседуемого: спросит ли он про контекст задачи, уточнит ли требования поддерживаемости кода, предложит ли развернуть агрегатор логов, быстро ли напишет конечный скрипт.
Вы наверное не совсем поняли смысл такой задачи. Мне как раз недавно довелось проводить собеседования на DevOps'а и тут речь вообще не про архитектуру хранения логов. Просто вот сидит перед вами человек, он 10 лет занимался opsом в эксплуатации и процесс погружения в DevOps может быть только в самом начале. В резюме у него написано «программирую на Python», в гитхабе его нет. Нужно хоть как-то оценить навыки программирования, а они, поверьте, бывают на уровне от «не могу split'ом поделить строку» до «написание собственного CI\CD инструментария с RESTful API». Вот на таких незамысловатых тестах проверяется вообще способность строить алгоритмы, хоть и способ оценки по скорости работы, выбранный автором статьи, у меня тоже вызывает вопросы.
«Жевать» структурированные данные будет Logstash, Elasticsearch получит уже разложенные в JSON данные с типами.
Ой как знакомо. Двадцать лет назад (да, в 1998-ом) я столкнулся с очень похожей задачей. С тех пор иногда люблю ее задавать на собеседованиях по SQL.
Постановка задачи:
Мы интернет провайдер раздающий dial-up. У нас есть, скажем, 128 входных модемов объединенных в hunting группы по 16. Cisco 2511 помните? ;-)
Каждый модем может быть либо занят клиентом либо свободен. Время нахождения клиента на линии не может быть более 3-х часов.
Информация об этом сохраняется таблицу MySQL в следующем виде:
Timestamp, ID терминала, ID клиента, Время занятия линии в секундах.
Информация хранится несколько месяцев.
Требуется построить почасовой суточный график загрузки всего пула с помощью одного SQL запроса. Без сохраненных процедур и view. При этом нужно учитывать какой процент времени в течении каждого часа модем был свободен, пользователь мог прийти позавчера и отсоединится вчера и так далее. Так же нужно учитывать что этот запрос должен отрабатывать в разумное время на SPARCStation 5 c 70MHz процессором. ;-)
Постановка задачи:
Мы интернет провайдер раздающий dial-up. У нас есть, скажем, 128 входных модемов объединенных в hunting группы по 16. Cisco 2511 помните? ;-)
Каждый модем может быть либо занят клиентом либо свободен. Время нахождения клиента на линии не может быть более 3-х часов.
Информация об этом сохраняется таблицу MySQL в следующем виде:
Timestamp, ID терминала, ID клиента, Время занятия линии в секундах.
Информация хранится несколько месяцев.
Требуется построить почасовой суточный график загрузки всего пула с помощью одного SQL запроса. Без сохраненных процедур и view. При этом нужно учитывать какой процент времени в течении каждого часа модем был свободен, пользователь мог прийти позавчера и отсоединится вчера и так далее. Так же нужно учитывать что этот запрос должен отрабатывать в разумное время на SPARCStation 5 c 70MHz процессором. ;-)
Sign up to leave a comment.
Как я эволюцию админов в программистов измерял