Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

В серии статей я попытаюсь осветить неочевидные нюансы при работе с Redis и сегодня начну с основных концепций и понятий. А еще в конце статьи приведу небольшой чек-лист, который может помочь вам в оптимизации этого NoSQL решения.

А что мы все о грустном да печальном, ошибках да UB всяких? Давайте скрасим пятницу парой вредных советов ala Григорий Остер. В бытность мою работы в питерском офисе электроников (EA Spb), был у нас один замечательный QA инженер. В обычной жизни человек довольно замкнутый и неразговорчивый, но на вечеринках, приняв стопку-другую чаю, превращался в искрометного шутника, способного срифмовать все что угодно, чем мы неоднократно пользовались. Василий, за давностью лет, я к сожалению не помню твоей фамилии, если отзовешься в коментах, то обязательно поставлю авторство. Немного из тех виршей у меня сохранились, да смысла их записывать особо не было и некогда, потому что всегда был автор под боком, но кое что сохранилось.

Если ты с утра увидел
Багу в трекере своем
Не спеши её дебажить
Пусть немного полежит
В чате спрашивай побольше
И лида поотвлекай
Пусть о баге этом страшном
В фирме знает весь народ
А потом отправь на репро
И закрой как CNR

Около двух лет назад вышла небольшая статья Kafka Streams — непростая жизнь в production, в которой я описывал сложности, с которыми наша команда столкнулась при попытке решить задачи проекта с помощью kafka-streams. Эксперимент вышел неудачным, и мы в итоге совсем отказались от этой технологии. Вместо нее решили попробовать Clickhouse (CH), и сейчас уже можно сказать, что эта база нам очень хорошо подошла и отлично решает почти все задачи, которые нам ставит бизнес. В этой статье я расскажу об особенностях использования CH.

Туториал по работе с логами в Kibana для начинающих специалистов по тестированию ПО.

У Kibana имеется свой язык запросов KQL (Kibana Query Language) - официальный источник. С помощью этого языка можно составлять запросы, которые помогают отфильтровывать и найти необходимую информацию.

Подключение к Kibana для просмотра логов.

Говорят, собственный пример – это самое лучшее обучение для ребёнка. Рассказываю, как я проверил справедливость этого высказывания на себе, с нуля погрузился в робототехнику и в итоге у меня даже получилось сконструировать нечто стоящее. А ещё в процессе я поднаторел в вопросах экономии средств на покупке довольно дорогостоящих деталей для такого вида хобби.

Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.

Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.

В этой статье я рассмотрю причины такого подхода, его недостатки, а также способы решения проблем, к которым он приводит. Я  выделила несколько основных принципов, которые помогут прийти к чистой истории изменений проекта. Давайте же вместе исследуем эту темную, неизведанную сторону Git, которая нам в этом поможет.

В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как Wireguard и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера для всего этого.

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

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

Ходят слухи, что foreach быстрее for. А ещё ходят слухи, что for быстрее foreach. Пора разобраться, что быстрее!

Я начала пользоваться ClickHouse до того, как это стало мэйнстримом: первый раз я столкнулась c этой базой данных лет 8 назад. C тех пор я уверена, что это лучшая DB для аналитики. Большинство аналитиков, которых я знаю, в восторге от ClickHouse (иногда чтобы проникнуться, требуется немного времени: разобраться и привыкнуть к синтаксису).

В этой статье я расскажу что такое ClickHouse и почему я считаю его идеально подходящим мощным инструментом для аналитики. А также поделюсь tips & tricks из моего опыта. Поехали.

В этом году наша компания впервые провела конкурс по базам данных в рамках международной олимпиады IT-Планета по информационным технологиям. Раньше на олимпиаде использовалась СУБД Oracle; наш коллега Евгений Бредня в свое время делился таким опытом.

Олимпиада проходила в три этапа. Первым шел заочный теоретический тест, который преодолели примерно двести человек из двух тысяч зарегистрировавшихся.

На втором этапе участникам было предложено подумать над пятью задачами, каждую из которых следовало решить одним SQL-запросом. Этот этап также проводился заочно: на раздумья было дано примерно три недели. Условия всех задач были опубликованы одновременно, но у каждой был свой крайний срок; поэтому первыми шли задачи полегче, чтобы на более сложные осталось больше времени. Задачи проверялись на корректность (автоматическими тестами) и на качество кода (вручную). По результатам мы отобрали двадцать человек для последнего, очного этапа.

Третий этап состоялся 27 мая в Сочи. К сожалению, из двадцати приглашенных приехать смогли только четырнадцать; между ними и состоялось соревнование. Задачи этого этапа также предполагали решение одним запросом, но сами задания были объединены общей темой, навеянной игрой Го, и строились так, что решение одной задачи помогало подступиться к следующей.

Я занимался придумыванием задач для второго и третьего этапов. Хочу поблагодарить участников олимпиады, которым пришлось их решать, организаторов, собравших нас вместе, и своих коллег: Дарью Рисухину, взвалившую на себя все оргвопросы, Евгения Моргунова, предоставившего задания для первого этапа, а также всех помогавших мне с задачами.

Центр управления данными нашей компании занимается построением хранилищ, Data Lake, платформ данных и BI-систем. ETL — неотъемлемая часть нашей работы. Сегодня мы рассмотрим актуальные подходы к созданию подобных решений и расскажем о двух проектах, где они были реализованы нестандартными способами.

С одной стороны, в IT‑сфере распространено достаточно сильное убеждение, что IT‑специалист обязан менять работу раз в 3 года, иначе он теряет свои технические навыки, его зарплата становится меньше, чем могла бы, и происходит снижение его привлекательности, как потенциального кандидата. С другой — есть множество историй, когда человек уходил с нормального места, попадал в какой‑то треш и начинал жалеть о том, что решил сменить работу.

Поэтому в данной статье я изложу собственное мнение на healthcheck работодателя, чтобы трезво оценить: нужно ли менять работу или не стоит прыгать в омут с головой.

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

Подсчет статистики — это не сильно затратный с точки зрения производительности способ получить информацию о нагруженности системы с активным вводом-выводом. Но он имеет недостатки: усреднение, отсутствие бакетов, малая гранулярность системного таймера.

Нам, как конечным пользователям, будет полезно понимать, как устроен механизм сбора и накопления статистики внутри ядра и как читает и интерпретирует данные популярная утилита iostat. Что именно значат aqu-sz, util и другие данные из режима расширенной статистики? Почему многие значения усреднены? Чтобы ответить на эти и другие вопросы, мы пройдем путь от системного вызова до момента, когда запрос ушел в диск и вернулся, — а счетчики обновились. Поехали!

В процессе разработки витрин данных часто возникает задача предоставления клиентам данных в агрегированном виде. Если данных в хранилище немного, то их можно агрегировать “на лету”, но это плохая практика так как, чем больше будет копиться данных, тем дольше будут выполняться запросы, и тем больше Clickhouse будет съедать ресурсов. В этих случаях логично хранить данные в заранее агрегированном виде, вопрос лишь в том, как реализовать расчет данных агрегированных значений.

В интернете существуют много однотипных статей иллюстрирующих базовое использование материализованных представлений (далее - матвью) на движке AggregatingMergeTree, но если ваша задача выходит за рамки “1 нода, 1 метрика, 1 параметр агрегации” эти статьи вам мало чем помогут. Я посчитал, что моим коллегам может пригодиться своего рода гайд о том, как пользоваться данными представлениями для более сложных задач.

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

В рамках моей задачи хранилище данных (далее - DWH) реализовано в виде реплицированного кластера состоящего из 3 нод, данные на ноды распределяются равномерно в соответствии с ключом сортировки таблиц. Существует исходная таблица source, которая содержит столбцы id, timecode_1, metric_data - данные представляют собой временной ряд утилизации ресурсов с гранулярностью 1 минута. Данные поступают блоками каждые 2 минуты.

Продолжим погружение в код PostgreSQL. Сейчас посмотрим, что происходит, когда вы хотите выполнить запрос сложнее, чем в прошлый раз: добавим WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.

Плюс:

• Системный кэш

• Сходство обращения к столбцам и вызовов функций

• Предсказание количества возвращаемых кортежей

• Работа с простыми типами

• Маркировка столбцов при использовании FOR UPDATE

Wireshark – это широко распространённый инструмент для захвата и анализа сетевого трафика, который активно используется как для образовательных целей, так и для устранения неполадок на компьютере или в сети. Wireshark работает практически со всеми протоколами модели OSI, обладает понятным для обычного пользователя интерфейсом и удобной системой фильтрации данных. Помимо всего этого, программа является кроссплатформенной и поддерживает следующие операционные системы: Windows, Linux, Mac OS X, Solaris, FreeBSD, NetBSD, OpenBSD.

Работа по реализации компрессии WAL на разных уровнях предпринимались с самых ранних дней PostgreSQL. Некоторые из встроенных функций доступны нам еще с 2016 года, и почти все инструменты резервного копирования, прежде чем помещать WAL в резервный репозиторий, выполняют его сжатие. И вот наконец настало время еще раз взглянуть на встроенный wal_compression, потому что PostgreSQL 15 есть что предложить нам. В комбинации с остальными значимыми улучшениями в архивировании WAL в PostgreSQL 15 мы можем добиться впечатляющих результатов.

Я написал книгу и назвал ее "Электрообереги". Она рассказывает про те замечательные устройства в электрощитке, что спасают нас от погибели. Начиная от предохранителей, которые существуют более века, заканчивая новейшими устройствами защиты от дугового пробоя. (Включая АВ, АВДТ, ВДТ, УЗО, РН, УЗИП, СГД и т.д.) Рассказ построен так, чтобы даже блондинке стало ясно как эти устройства устроены и зачем они нужны. Кто давно на меня подписан подобные посты уже видел - книжка представляет собой собранные воедино и причесанные публикации за последние два года. Еще я перерисовал все сторонние иллюстрации и теперь книжка лицензионно чиста - ни один мерзкий копираст не подкопается.

А еще сегодня у меня день рождения. И это хороший повод сделать подарок миру - книжка публикуется под открытой лицензией CC BY-NC-SA, тоесть ее можно распространять совершенно свободно.

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

А ещё здесь ссылки… Много ссылок. На книги. На те, книги, которые в отличие от твоего знакомого «Гуру-трейдинга на крипте в позиционке» реально раскидывают по полочкам. Как торговать. Где торговать. Чем торговать. И почему тебе вообще лучше не торговать.

Много терминов. Много мемов. Немного сумбурная структура. Но, а как вы хотели? Если в одной статье есть и волновой анализ Элиота, и пару слов о превышении ликвидности криптовалют, да все это ещё и приправлено помесью Мартингейла, теории игр, мат-ожидания, Фиксированных фракций, и куче других непонятных слов. 

В общем, если ты всегда хотел, чтобы кто-то без рекламы «трейдер х, иди к нам и получи приветственный бездепозитный» рассказал тебе, как оно работает на самом деле, да ещё и комплексно (а не отрывочно по секретным методикам, которые сегодня работают, завтра нет). Тебе сюда!