jl-sql: SQL-запросы по JSON-логами в командной строке

[TimsTims]

Много слов действительно никому не интересно. Поэтому просто: Неплохо!

[iqmaker]

Любопытно, спасибо за статью, а есть какой правоверный способ вывода логов nginx в json?

[Arepo]

К сожалению, на данный момент нет. В планах есть реализация user-defined шаблона как раз для парсинга обычных логов, ну а пока только sed и генерация JSON с помощью такой-то метери :)

[iqmaker]

Благодарю за ответ, вроде вместо sed можно использовать декларацию формата, таким способом:
https://blog.pkhamre.com/logging-to-logstash-json-format-in-nginx/
либо плагином:
https://github.com/jiaz/nginx-http-json-log

подумал, может есть нативная поддержка

[ChALkeRx]

Да, весьма неплохо именно в юзкейсе такой утилиты с простыми декларативными правилами на SQL-подобном языке. Мне в целом нравится.

[Arepo]

Именно для этого и писалось: замучало под каждый формат своих логов писать огромные пайпы на grep + sed + awk + cut + sort + uniq

[Mingun]

Напомнило q для Python, только там работа ведётся с csv'шками.

[Arepo]

Отличная утилита, к сожалению, не знал о ней. Спасибо за наводку на конкурента — будет с кем соревноваться.

[Mingun]

В ней меня немного разочаровал тот факт, что таблицу нельзя использовать в подзапросе. То есть, такой запрос работает:

q "select * from data.csv"

а такой — уже нет:

q "select * from (select * from data.csv) t"

Пришлось делать через временный файл. А у вас как с этим дела?

[Arepo]

А разве нельзя то же самое сделать через обычный pipe?

q "select * from data.csv" | q "select * from - t"

Я только из соображений ненужности не стал реализовывать подзапросы. Думаете, стоит?

[Mingun]

Можно и через канал, но через временный файл было удобнее. Реальный запрос был сложнее.

Я только из соображений ненужности не стал реализовывать подзапросы. Думаете, стоит?

Я думаю, они были бы очень полезны, особенно в сочетании с фразой with.

[Arepo]

Посмотрел более внимательно и обнаружил, что перед выполнением запроса все входные данные читаются в оперативную память, а потом уже идёт их обработка. Это фактически делает невозможным обработку действительно больших логов. Кроме того, в связки с tail -f работать не будет даже для самых простых запросов вида SELECT * WHERE f = "value"

[Arepo]

Описываемый в статье jl-sql заточен именно под огромные логи, которые заведомо либо не влезают в память, либо вообще потенциально-бесконечны (реалтайм-поток). Поэтому jl-sql использует временное хранилище только там, где без него не обойтись, например, при сортировках.

Если сортировка не нужна, то результат на stdout будет выводиться сразу после получения отдельного объекта в stdin, не дожидаясь окончания всего потока объектов. Так работают запросы вида:

SELECT smth WHERE condition

Простые агрегационные запросы без GROUP BY тоже не будут требовать временного хранилища

SELECT SUM(`field`) WHERE condition

А вот JSON Path имеет смысл сделать в следующей мажорной версии, спасибо

[georgas]

Классная вещь! Для PHP такого нет, случайно?

Еще немного непонятно — как делать выборку по частичному совпадению? Тот же «like %...%», например?

[Arepo]

Я для PHP подобного не встречал.

Еще немного непонятно — как делать выборку по частичному совпадению? Тот же «like %...%», например?

LIKE и регулярные выражения появятся в ближайшее время (пара дней)

[georgas]

LIKE и регулярные выражения появятся в ближайшее время (пара дней)

Отлично, спасибо! Уже нашел начал использовать, а с like будет вообще идеально.

Еще заметил, что не работает конструкция в WHERE:

ts > (now() - INTERVAL 24 HOUR)

где ts — дата-время в формате «2017-01-19 14:50:45».
Работает как-то так:

(ts + INTERVAL 1 SECOND) > (now() - INTERVAL 24 HOUR)

т.е. получается, что время приводится к единому формату и только потом сравнивается. При этом в SELECT подобные манипуляции не нужны.

[Arepo]

Хорошее замечание. К сожалению, о таком очевидном юзкейсе я не подумал заранее, но ничего, это исправимо.

Если ещё что-то заметите, то обязательно пишите — будем допиливать ;)

[georgas]

Если ещё что-то заметите, то обязательно пишите — будем допиливать ;)

Хорошо :-)

[Arepo]

Зарелизил новую версию jl-sql v1.2.0 (jl-sql-api v2.4.0) с поддержкой LIKE и ILIKE (регистро-независимый LIKE). Ещё сделал поддержку автоматического приведения типов для дат, так что теперь

ts > (now() - INTERVAL 24 HOUR)

должно работать.

Поддержки регулярных выражений пока нет.

[Arepo]

Вот и регулярки подоспели

jl-sql-api v2.5.0 (2017-01-23)

• REGEXP support: "string" REGEXP "/pattern/im"
• BETWEEN support
• IS support:
  
  • IS [NOT] NULL
  • IS [NOT] BOOL and alias IS [NOT] BOOLEAN
  • IS [NOT] NUMBER
  • IS [NOT] ARRAY
  • IS [NOT] OBJECT
  • IS [NOT] STRING

[foxmuldercp]

Автору на заметку — есть очень интересная консольная утилита для json — jq, советую тоже обратить на неё внимание

[Arepo]

Утилита хорошая, я её тоже использую, но jq и jl-sql совсем для разного.