В этом году наша компания впервые провела конкурс по базам данных в рамках международной олимпиады 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, тоесть ее можно распространять совершенно свободно.

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

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

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

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

GiST

GIN

Общая идея

Привет, Хабр! Меня зовут Денис Захаров. Я занимаюсь разработкой веб приложений на протяжении уже 14 лет, но история будет не об этом. Расскажу о том, как и почему я создавал эргономичное рабочее место, которое в последствии превратилось в проект Easyworkstation. Эта штука уже несколько лет полностью заменяет мне и еще нескольким десяткам пользователей привычное компьютерное кресло и рабочий стол.

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

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

Приветствую!

В этой статье рассмотрим какой путь проходит простой SELECT запрос. От стадии сырой строки до отправки ответа клиенту.

А еще:

• Работу со статистикой приложения через API Linux.

• Реализацию динамического списка.

• «Наследование» в C.

• Как ведется работа с диском в БД.

• Немного легаси.

Добрый день! Меня зовут Михаил Емельянов, недавно я опубликовал на «Хабре» небольшую статью с примерным путеводителем начинающего Python-разработчика. Пользуясь этим материалом как своего рода оглавлением книги, я написал первые четыре главы мини-учебника «Ядро планеты Python», где постарался коротко, но достаточно ёмко раскрыть специфику, удобство, красоту и силу этого прекрасного языка.

Оригинал учебника лежит на GitHub, вы вольны сколько угодно дополнять и переделывать его. Самое главное — учебник написан на Jupiter Notebook, а это значит, что вы можете интерактивно редактировать код, мгновенно добавляя новые сущности или проясняя непонятные моменты.

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

В этом видосике сошлись в смертельной схватке два «блогера‑сантехника», каждый из которых считал, что только он прав.

По результатом этой баталии у меня возникли альтернативные решения, не совпадающие полностью ни с одним из дуэлянтов.

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

Особый интерес к этой теме у меня возник потому, что я сам лично как‑то собрался поменять такую старую облезлую «гармошку» (см.рис.1) на новый белый и красивы биметаллический радиатор (см.рис.2).

Привет Хабр! Возможно тема возврата денежных средств за приобретенный товар поднималась и ранее, но положения законодательных актов и судебные позиции склонны со временем меняться. Решил для читателей собрать в одном месте все правовые нормы, разложить по полочкам права покупателя и обязанности продавца, а также объяснить с точки зрения законодательства процесс осуществления возврата денежных средств за технически сложный товар. И заодно раз и навсегда ответить на вопрос, почему в случае обнаружение неисправности устройства надо всегда фиксировать все совершенные действия.

Рассмотрим следующий пример:

CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)

Теперь предположим, что мы выполним обновление:

UPDATE T SET A = 1 – A

Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:

  _{|--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
       |--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
            |--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
                 |--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
                      |--Top(ROWCOUNT est 0)
                           |--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))}

Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.

_{Оперативно узнавать о новостях MS SQL Server можно в телеграмм-канале: MS SQL Server - дело тонкое...}

Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.