Предлагаю ознакомиться с расшифровкой доклада Романа Хавроненко "ExtendedPromQL"

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

Содержимое письма при таком способе приходится формировать plain-текстом, а рассылать почту либо через xp_sendmail, либо (более гибко) через почтовый COM-объект (например, CDO.Message), инстанциируя и управляя им через SQL-обертки для работы с OLE sp_OAxxxx.

И то, и другое работает, пока вам хватает выразительных средств плейнтекста, иерархичность ваших данных — околонулевая, и отчет потребляется исключительно олдскульным техническим пиплом, который

+-----------+--------------+--------------+
| АБСОЛЮТНО | НЕ ВИДИТ ПРО | БЛЕМ В ТАКОМ |
| ОФОРМЛЕНИ | И СЛУЖЕБНОГО | ВЫВОДА <EOT> |
+-----------+--------------+--------------+

Что делать, если подобный формат начинает напрягать, а регистрировать на сервере свои компоненты, или «выныривать» из уровня БД на уровень приложения для отправки чего-то более красивого ну очень не хочется:

Привет, Хаброжители! В сфере IT произошла настоящая революция — с инфраструктурой стали работать как с кодом. Этот процесс создает не только новые проблемы, но и возможности для обеспечения безотказной работы баз данных. Авторы подготовили это практическое руководство для всех, кто желает влиться в сообщество современных инженеров по обеспечению надежности баз данных (database reliability engineers, DBRE).

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

Всем привет!

Занимаюсь тестированием производительности. И очень люблю настраивать мониторинг и любоваться метриками в Grafana. А стандартом для хранения метрик в инструментах для подачи нагрузки является InfluxDB. В InfluxDB можно сохранять метрики из таких популярных инструментов, как:

• Apache.JMeter
• Gatling
• LoadRunner Enterprise
• Yandex.Tank

Работая с инструментами по тестированию производительности и их метриками, накопил подборку рецептов программирования для связки Grafana и InfluxDB. Предлагаю рассмотреть интересную задачу, которая возникает там, где есть метрика с двумя и более тегами. Думаю, это не редкость. И в общем случае задача звучит так: подсчёт суммарной метрики по группе, которая делится на подгруппы.

Интересно наблюдать за историей. Netflix, YouTube, Twitch постепенно вытеснили телевизор из нашей жизни. Сейчас похожий процесс происходит с подкастами и радио. За последние 2 года количество подкастов в мире выросло с 525 000 до 900 000, а количество эпизодов увеличилось с 18 000 000 до 30 000 000. В России эта волна началась в прошлом году, но уже сейчас становится сложно в них ориентироваться. Мы сделали для вас подборку из 57 техноподкастов и около того.

Данная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)

В начале хотелось бы отметить, что статья не призвана показать изобретение велосипеда, потому как многие приёмы уже давно существуют в культуре разработки баз данных. Однако обобщить, проанализировать проблемы, которые они могут решить и показать, как с ними можно работать. А проблем хватает несмотря на то, что нормативно-справочная информация (НСИ) не относится к бизнес-логике, а скорее находится в обслуживании у неё. Стандартный процесс по рисованию очередной таблички для хранения справочника очень скоро начинает обрастать костылями или трудоёмкими переделками.

Артикли — это самые распространенные слова в английском языке. Эти невзрачные a, an и the занимают около 8,5% объема любого текста. Если немного утрировать, то из каждого часа работы с текстом вы пять минут тратите только на прочтение артиклей.

Вместе с этим артикли — это одно из первых правил, с которым знакомятся студенты, изучающие английский язык. И одно из первых правил, которые они забывают и используют как попало.

В общем, сегодня мы решили рассказать вам именно об артиклях. Откуда появились, как развивались исторически и как их использовать правильно сегодня. Поехали!

В Ситимобил мы используем базу данных MySQL в качестве основного хранилища постоянных данных. У нас есть несколько кластеров баз данных под различные сервисы и цели.

Постоянная доступность мастера является критическим показателем работоспособности всей системы и ее отдельных частей. Автоматическое восстановление кластера в случае отказа мастера сильно снижает время реагирования на инцидент и время простоя системы. В этой статье я рассмотрю схему обеспечения высокой доступности (HA) кластера MySQL на основе MySQL Orchestrator и виртуальных IP адресов (VIP).

В Оксфордском словаре английского языка почти 450 000 слов! Но если вы учите язык как иностранный, их совсем не нужно запоминать все и сразу.

Чтобы полноценно общаться на английском языке, вполне достаточно всего лишь 2000–3000 слов. При должном усердии и небольшом количестве хитростей их вполне можно выучить за год.

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

Elasticsearch, вероятно, самая популярная поисковая система на данный момент с развитым сообществом, поддержкой и горой информации в сети. Однако эта информация поступает непоследовательно и дробно.

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

Знакомьтесь с Петей, шестиногом о трёх сервоприводах

Продолжаю публикацию статей из серии "ардуино головного мозга". Петя — это очень дешёвый (примерно десять баксов) гексапод. Он может быть прекрасным проектом на один ненастный выходной, который развлечёт как и взрослых, так и детей. Раз уж мы про развлечения, вот вам видеоролик с Петей, танцующим под фанк-музыку:

TL;DR;

В статье описано, как внедрялся Apache Airflow для управления заданиями обновления отчетности, построенной на QlikView в достаточно крупном внедрении.

Никогда не было, и вот опять!

На очередном проекте мы решили использовать Liquibase с самого начала, чтобы избежать проблем в будущем. Как оказалось, не все молодые члены команды умеют его правильно использовать. Я провёл внутренний воркшоп, который затем решил превратить в статью.

Статья включает в себя полезные советы и описание трех самых явных ловушек, в которые можно попасть, работая с инструментами миграции реляционных баз данных, в частности Liquibase. Рассчитана на Java разработчиков уровня Junior и Middle, для более опытных разработчиков может быть интересна для структуризации и повторения того, что, скорее всего, уже известно.

Что будет, если использовать всем известное in-memory-хранилище ключей и значений в качестве персистентной базы данных, не используя TTL? А если оно запущено с помощью надёжного, казалось бы, оператора в Kubernetes? А если в процессе увеличения реплик Redis мы внесём ещё одно маленькое и безобидное изменение?.. Отвечая на эти вопросы в данной статье, мы попутно расскажем, какие утилиты помогут найти пути к оптимизации размеров большой БД в Redis.

Проблемный кейс

Redis у нас используется внутри кластера Kubernetes в разных проектах. Для удобства управления и применения единых практик в рамках компании мы остановились на операторе от Spotahome. По нашему опыту, это наиболее стабильный вариант, хотя и у него есть свои проблемы, некоторые из которых будут затронуты далее в статье.

Вторая часть цикла переводов Redis Best Practices от «Redis Labs», и в ней рассмотрены паттерны взаимодействия и паттерны хранения данных.

Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"

В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.

В серии из нескольких статей я приведу свой адаптированный перевод раздела Redis Best Practices с официального сайта «Redis Labs».

Когда мы готовим ребенка к поступлению в школу и помогаем ему адаптироваться к школе, поддерживая его интеллектуальное развитие, то одно из классических игровых средств – это обыкновенные игральные карты. Обучая ребенка карточным играм, мы можем давать нагрузку на все когнитивные функции. Зрительное восприятие понадобится, чтобы различать символы мастей (не путать пики и червы, в частности). Память – чтобы следить за тем, какие карты уже сыграны. Мышление – чтобы составлять комбинации и просчитывать выгодные ходы. Внимание – чтобы не проморгать в своей руке те карты, которые позволят эти выигрышные ходы сделать. Играя по разным правилам одной и той же колодой, мы совершенствуем произвольную регуляцию деятельности и учим гибкому, нелинейному поведению. В общем, игральные карты – это замечательная вещь. Но у них есть существенный недостаток: в нашей культуре они плотно ассоциированы с азартной игрой на деньги и воспринимаются поэтому как нечто порицаемое. Это означает, что специалист, играя в карты с ребенком, будет провоцировать реакции вида «чему вы тут его учите?» со стороны семьи, а ребенок не сможет принести игральные карты в школу, чтобы поиграть на перемене, не провоцируя аналогичных реакций со стороны педагогов. Причем понятно, что этот культурный стереотип к жизни давно уже имеет весьма опосредованное отношение, и какая-нибудь браузерная многопользовательская игра с куда большим успехом приобщит ребенка к игре на деньги, чем колода карт на перемене. Но перед нами все же встает проблема того, что ребенок может начать ощущать, будто делает что-то аморальное и неприличное. Это его либо отвратит от игры (и потеряется смысл игры как самоподдерживающейся развивающей деятельности), либо негативно скажется на самовосприятии – а у нас нет цели заставить ребенка ощущать себя хулиганом и правонарушителем.

Вариант решения этой проблемы – играть с ребенком не в карты, а в маджонг.

Однажды ко мне обратились с просьбой помочь «исправить» одну базу данных. CHECKDB при проверке выдавал список ошибок, некоторые из которых отмечались как «неисправимые». Приложение при этом работало, но все равно было как-то неспокойно.

Да, правильным решением в такой ситуации было бы взять бэкап от того момента, когда ошибки еще не появляются, локализовать испорченные данные и перезаписать их из чистой копии. Но… как это часто бывает, ошибку поймали слишком поздно, так что восстанавливаться, по сути, было не с чего. С другой стороны – был бы бэкап, не было бы этой истории.

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

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

Чтобы не дать пользователю возможность просматривать обороты в разрезе клиентов, можно обыграть это через формулы в мерах и выводить пустое значение, если пользователь попытается посмотреть оборот конкретного клиента, один из подобных вариантов описан здесь. Однако это всё не то. Когда мер несколько десятков, то писать в каждой из них формулу… а если забудешь? Но ведь точно забудешь же когда-нибудь… А если пользователю нужны данные из конкретной карточки клиента, то ему ни что не помешает это увидеть без выбора фильтрующей меры. Что же делать?

Нам нужно было добиться вот такого отображения: