SELECT
rec_num,
idx,
JSON_EXTRACT(jdoc, CONCAT('$.fish[', idx, ']')) AS fishes
FROM t1
-- Inline table of sequential values to index into JSON array
JOIN (
SELECT 0 AS idx UNION
SELECT 1 AS idx UNION
SELECT 2 AS idx UNION
-- ... continue as needed to max length of JSON array
SELECT 3
) AS indexes
WHERE JSON_EXTRACT(jdoc, CONCAT('$.fish[', idx, ']')) IS NOT NULL
ORDER BY rec_num, idx;
А почему отказались от Performance Monitoring в Sentry в пользу Kibana?
Он в SDK предоставляет неплохой инструментарий для управления транзакциями…
блок в “нашей панельке с «небоскребами»…”
У нас разнообразный стек из python, java, kotlin, php, node, c#, javascript и возможно чего-то ещё… Мы "пробовали" openzipkin & kibana, но сейчас переходим на on-premise sentry, т.к. готовый инструментарий гораздо удобнее в поддержке.
ИМХО: Для подобных процессов стоит собирать проекты на отдельной машине ;)
Мне на E480 помогала настройка TLP в linux. Он мог работать вполне шустро на частоте 1.8 ГГц без тротлинга 4/8 CT, "тяжелые" задачи – выгружались на ПК c 3700x и 32 Гб ОЗУ.
БД — также размещенна в Kubernetes, или на "железе"?
Если размещена на железе, то как ограничиваете коннекты к БД от консюмеров? Django любит подключить все что указано в settings.py…
Twitch ожидает звук AAC 128~160kbps (lossy) — можно предварительно скопировать звуковую дорожку с искажениями через loopback и сжать её. Но мне кажется, что у вас должно быть много свободного времени для этого ;)
В TB3 — можно передавать до DisplayPort 1.4. USB3.2 — ограничен DisplayPort 1.2, чего достаточно для паралельной передачи картинки 4k100Hz, USB2.0 хаба и PowerDelivery.
Не вводите людей в заблуждение — вас нет необходимости в TB3, если ваш монитор может работать по DP1.2, т.е. до 4k100Hz с HDR10 включительно.
maybe_elf если уже и делаете копипаст с нескольких англоязычных ресурсов, то хотя бы не ленитесь открывать полноразмерную картинку из оригинала и публиковать её на habrastorage.
ИМХО: Инфографику на картинках при 1440p читать не реально, она — мыльная.
Они в курсе.
Вместо swap-раздела — используется виртуальное раздел с zram. Настройки по умолчанию для earlyoom предусматривают завершение процессов, если памяти осталось менее 1,25% и менее 10% swap (можно настроить список исключений и рекомендаций). Сам демон earlyoom — также ограничен в потреблении памяти с помощью CGroup.
Готов "по-красноглазить", но хотелось в светлом будущем видеть список команд BLE и описание к ним в каком-нибудь GitHub-репозитории, чтобы не пришлось выискивать их в коде Android/iOS приложения ;)
Теперь, о elasticsearch — если есть необходимость, можно реализовать, или использовать готовый обработчик логов, который сразу будет слать логи в elk.
Например, django-structlog. В нем реализовано почти все, кроме генерации traceid — нужно будет добавлять менеджеры контекста и/или middleware, там где необходимо.
Список того, что делать не следует:
Не логгируйте с помощью print — логи должны приходить туда, где их ожидают. При print, нужно вручную отслеживать контекст приложения, добавлять форматирование, а также передавать io.Stream, если у вас более одного обработчика логов.
Не сериализуйте в prod среде с помощью встроенного json. Он достаточно медленный, если вводные данные не являются объектом io.Stream. Есть достаточное количество оберток над native-библиотеками (orjson, ujson, rapidjson).
Павел, скажите пожалуйста, планируется ли десктоп-клиент, или спецификация bt/ble-комманд для взаемодействия с флиппером, или это останется "фичей" только для ios/android?
Приходилось один раз это использовать. В сравнении с PGSQL – поддержка слабая. Лично мне не хватило аналога
unnestпри работе с mariadb.source.
А почему отказались от Performance Monitoring в Sentry в пользу Kibana?
Он в SDK предоставляет неплохой инструментарий для управления транзакциями…
У нас разнообразный стек из python, java, kotlin, php, node, c#, javascript и возможно чего-то ещё… Мы "пробовали" openzipkin & kibana, но сейчас переходим на on-premise sentry, т.к. готовый инструментарий гораздо удобнее в поддержке.
Sentry можно поставить на своё железо, но не уверен, что Business Source License – oss.
ИМХО: Для подобных процессов стоит собирать проекты на отдельной машине ;)
Мне на E480 помогала настройка TLP в linux. Он мог работать вполне шустро на частоте 1.8 ГГц без тротлинга 4/8 CT, "тяжелые" задачи – выгружались на ПК c 3700x и 32 Гб ОЗУ.
БД — также размещенна в Kubernetes, или на "железе"?
Если размещена на железе, то как ограничиваете коннекты к БД от консюмеров? Django любит подключить все что указано в
settings.py…Twitch ожидает звук AAC 128~160kbps (lossy) — можно предварительно скопировать звуковую дорожку с искажениями через loopback и сжать её. Но мне кажется, что у вас должно быть много свободного времени для этого ;)
Каюсь, с некоторых пор оборачиваю int в строку, т.к. libjson (а за ним Chrome, Firefox и почти все electron приложения) умеет считать только до 2^53.
Напоминаю, что оффтопик — J4125. Его встроенная графика ограничена 4k60Hz.
А TB3 — это почти 70$ за порт сверх стоимости устройства ;)
В TB3 — можно передавать до DisplayPort 1.4. USB3.2 — ограничен DisplayPort 1.2, чего достаточно для паралельной передачи картинки 4k100Hz, USB2.0 хаба и PowerDelivery.
Не вводите людей в заблуждение — вас нет необходимости в TB3, если ваш монитор может работать по DP1.2, т.е. до 4k100Hz с HDR10 включительно.
Там есть PCIe/NVMe, но это — уже сложнее.
100-144hz, низкий отклик, для владельцев ноутбуков — возможность подобрать модель с Type-C и PowerDelivery. 4K/144Hz/HDR10 — очень дорогое решение.
ТВ — игры для компании (тот же overcooked). Монитор — все остальное, когда хочется поиграть в кресле. Очень жаль что у PS5 не будет поддержки 21:9.
Не путайте USB3.0 (а также 3.1 & 3.2 с DisplayPort и PowerDelivery) с Thunderbolt — это разные протоколы, которые имеют один разьем (Type-C).
Жаль что DP в порту нет. Выходит как в NUC — только наоборот (там нет питания, но есть TB3).
maybe_elf если уже и делаете копипаст с нескольких англоязычных ресурсов, то хотя бы не ленитесь открывать полноразмерную картинку из оригинала и публиковать её на habrastorage.
ИМХО: Инфографику на картинках при 1440p читать не реально, она — мыльная.
В J4125 — PCIe 2.0, на нем не будет работать TB3.
Очень интересно, как бы вы использовали TB3 c j4125?
Использовал OpenAPI-схему актуальную на тот момент времени и aiohttp, т.к. нужно было отправлять HTTP-запросы и подключатся к WebSocket'ам.
Увы, судя по активности lkml — сложнее.
ИМХО: Внесение изменений в ядро ОС — требует большей ответственности и больше времени, чем user-space решение.
Они в курсе.
Вместо swap-раздела — используется виртуальное раздел с zram. Настройки по умолчанию для earlyoom предусматривают завершение процессов, если памяти осталось менее 1,25% и менее 10% swap (можно настроить список исключений и рекомендаций). Сам демон earlyoom — также ограничен в потреблении памяти с помощью CGroup.
Готов "по-красноглазить", но хотелось в светлом будущем видеть список команд BLE и описание к ним в каком-нибудь GitHub-репозитории, чтобы не пришлось выискивать их в коде Android/iOS приложения ;)
Мне почему-то кажется, что автор пытается переизобрести opentracing, sentry (beta), или opencensus (beta)…
Теперь, о elasticsearch — если есть необходимость, можно реализовать, или использовать готовый обработчик логов, который сразу будет слать логи в elk.
Например, django-structlog. В нем реализовано почти все, кроме генерации traceid — нужно будет добавлять менеджеры контекста и/или middleware, там где необходимо.
Список того, что делать не следует:
print— логи должны приходить туда, где их ожидают. Приprint, нужно вручную отслеживать контекст приложения, добавлять форматирование, а также передаватьio.Stream, если у вас более одного обработчика логов.json. Он достаточно медленный, если вводные данные не являются объектомio.Stream. Есть достаточное количество оберток над native-библиотеками (orjson, ujson, rapidjson).Павел, скажите пожалуйста, планируется ли десктоп-клиент, или спецификация bt/ble-комманд для взаемодействия с флиппером, или это останется "фичей" только для ios/android?