SQL *

Много лет в комьюнити PostgreSQL никто не верил что эта СУБД в принципе может использоваться в системах с большой транзакционной нагрузкой. То есть, какие-то тестовые лаборатории, бэкенд веб-приложений средней руки и так далее — вот его типичные задачи. А когда нужна серьёзная нагрузка, это уже надо брать СУБД за много денег и не сомневаться. Ну и раз никто не верил, то и не развивал особенно его в эту сторону, оставляя всё больше повисших в воздухе вопросов.

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

Trino — высокопроизводительный распределённый SQL-движок, с возможностью объединения данных из разнородных источников, таких как: реляционные БД, файловые хранилища, шины данных, inmemory-хранилища, облачные сервисы и тд. Архитектура ориентирована на выполнение аналитических запросов с минимальной задержкой. Т.е. с его помощью можно отправлять SQL-запросы в MongoDB и Kafka, например. Благодаря скорости, развитию, и удобству захватывает популярность у инженеров и аналитиков, работающих с bigdata.

Я познакомился с Trino 1 год назад, за это время настроил с нуля кластер на baremetal и помог с проблемами в нескольких других. В этой статье делюсь краткой выжимкой опыта эксплуатации, накопленным за это время. Большая часть информации будет актуальна и для российского форка Trino: CedrusData.

Думаю, почти все читатели хотя бы раз играли в Колонизаторов.
Настольная игра "Колонизаторы" стала одним из лучших новогодних подарков для автора текста.
Мы с друзьями провели много времени, играя в эту игру, и, должен сказать, нам было довольно весело.

В этой небольшой статье мы нарисуем игровое поле для Колонизаторов с помощью SQL.

Первая часть перевода статьи с пятью шагами по улучшению производительности Firebird на разных операционных системах с примерами.

GPT: Революция или Апокалипсис

Человек против машины. Нейросети — конец эпохи человеческого интеллекта?

Привет, меня зовут Георгий Ломакин, и я инженер по нагрузочному тестированию в компании Picodata — разработчике одноимённой NewSQL СУБД. В этой статье я поделюсь своим опытом нагрузочного тестирования и расскажу, как мы строили эту практику с нуля.

Мы выбираем распределённые системы за производительность и надёжность. Однако без постоянного нагрузочного тестирования и анализа отчётов после него, и то и другое лишь обещания. Конечно же, нагрузочное тестирование обязательно и в нашей команде, разрабатывающей распределённую NewSQL — базу данных Picodata.

В то время, как пользователи видят позитивные стороны технологий, мы, разработчики, обычно сталкиваемся с ограничениями/недоработками/багами и видим наш продукт с совсем другой стороны. Вот и в этот раз: после публикации результатов сравнительного тестирования где я прогонял запросы теста Join-Order-Benchmark на базе с партициями и без, меня не отпускало ощущение, что всё-таки что-то я не досмотрел и при наличии партиций постгрес должен строить план хуже, чем без них. И это должен быть не просто баг, а технологическое ограничение. И вот, методом разглядывания потолка удалось-таки найти тонкое место - запросы с лимитами.

Сегодня посмотрим на примере задачки из Advent of Code зачем и как можно обойти ошибку aggregate functions are not allowed in a recursive query's recursive term, возникающую при попытке агрегировать какие-то данные внутри шага рекурсии на PostgreSQL — «если нельзя, но очень хочется, то можно».

"Trino — это PostgreSQL для аналитики" — нескромно охарактеризовали Trino в одном из блогов. Я не люблю кликбейтные заголовки, но эта фраза действительно емко описывает одну из самых сильных сторон Trino — расширяемость.

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

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

Далее, для относительно сложных вариантов генерации SQL при изменениях бизнес-логики (или других изменениях) может измениться и сам динамически генерируемый SQL, причем результаты выполнения SQL могут остаться неизменными, однако производительность поменяется. В таких случаях изменения в производительности можно уловить при помощи бенчмарков, однако прогон бенчмарков может занимать значительное время, в связи с этим актуальна задача быстрого анализа изменений в производительности динамически генерируемого SQL. Интересны особенности анализа производительности приложения на основе SQL — добро пожаловать под кат :)

Миф о чистых данных: почему ваш аналитик похож на сапёра.

Как бороться с самым частым убеждением при работе с данными.

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

Для достижения этой цели в 5-й версии (как и в 4-й) гораздо больше внимания было уделено UI/UX, а не бизнес-логике. Так, существенно расширились возможности кастомизации пользовательского интерфейса, осовременился дизайн, асинхронность большинства процессов вышла на новый уровень и вообще произошло значительное улучшение многих метрик, критически важных при разработке любого современного веб-приложению. Впрочем, обо всем по порядку.

Для меня PL/SQL есть логичное продолжение изучения SQL, но по нему много и статей, и курсов, причем даже на русском языке. С другой стороны, PL/SQL раскрывается достаточно редко, особенно среди бесплатных ресурсов, так что… Начинаем :)

Всем привет. Меня зовут Сергей, я — эксперт компании Bercut. За плечами — более 20 лет работы с различными СУБД (PostgreSQL, Oracle, MS Access, MS FoxPro, Borland InterBase) и высоконагруженными системами на их основе.

В Bercut мы занимаемся разработкой и развитием IT‑продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24×7x365 в режиме онлайн сотни миллионов абонентов.

Сегодня поговорим о том, как оптимизировать хранение данных в PostgreSQL, снизив объем дискового пространства, потребляемого таблицами и ускорить выборку данных. Это может быть особенно актуально после перевода информационной системы с другой СУБД на PostgreSQL.

Это не лонгрид (как кажется с первого взгляда), а краткое практическое руководство.Есть навигация, можно сразу перейти на нужные пункты.

Сегодня поговорим о мощной штуке в PostgreSQL, которая одновременно помогает и открывает портал в ад: динамические SQL‑запросы. Динамика — это когда SQL собирается на лету, а не пишется заранее статичным текстом. Звучит неплохо, но при неправильном подходе легко превращается в катастрофу.

В статье исследуется использование DAX Studio, мощного инструмента, который помогает разработчикам Power BI извлекать и обрабатывать метаданные из дашбордов. Утилита позволяет оптимизировать рабочие процессы, делая задачи, такие как заполнение файлов метаинформацией, более эффективными.

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

Транзакция — это набор операций с базой данных. В этот набор может входить как одна операция, так и несколько. Операции внутри транзакции либо выполняются все и полностью, либо ни одна операция не выполняется. Это свойство еще называют атомарностью. Транзакция переводит базу данных из одного согласованного состояния в другое. Согласованность означает что данные в базе данных подчиняются определенным правилам, которые были заложены при ее создании. К примеру, у нас есть две таблицы — Покупатели (Customer) и Покупки (Purchase).

Недавно я писал статью - что такое 50% cpu? На системах с hyperthreading 50% cpu по метрикам означает, что большая часть ресурсов сервера уже использована. То есть cpu>50% - это уже "желтая зона", и мы ожидаем замедление всего, чего можно. Но я никогда не думал до экспериментов, что падение может быть столь катастрофическим.

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

Все мы любим ClickHouse, но прекрасно знаем, что у этой СУБД есть свои особенности и ограничения. В этой статье мы поговорим о том, почему нужно избавляться от лишних операторов JOIN, если вы работаете с большими нагрузками, а также оценим, какой эффект дает исключение JOINов, поднятие их на уровень выше, перестановка таблиц местами и некоторые другие хитрые трюки на уровне кода SQL. Всех, кто работает с ClickHouse, а также тех, кто не хочет работать с ClickHouse, но подумывает получить все готовенькое от Visiology, приглашаю под кат!