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, приглашаю под кат!

Мы выпустили новый технический каталог для аналитических платформ, который поддерживает спецификацию Iceberg REST API. Рассказываем, зачем это нужно вам и нам

Сегодня поговорим о том, как устроены модели данных в BI-платформах. Рассмотрим два основных типа моделей данных, которые используются в BI: физическую и логическую.

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

Привет, Хабр! Меня зовут Дмитрий Капралов, я работаю в команде консалтинга компании Arenadata. Одной из наших задач является проведение аудита кластеров СУБД Arenadata DB (ADB). Проектирование физической модели данных и настройка квотирования ресурсов кластера проводятся на этапе разработки хранилища. Однако при переходе системы в продуктивный режим профиль нагрузки кардинально меняется, и первоначальные настройки СУБД и архитектура данных нередко оказываются не готовы к такой нагрузке. В процессе эксплуатации могут возникнуть узкие места, замедляющие работу системы. В этой статье я хочу поделиться опытом нашей команды по выявлению и оптимизации подобных проблем.

Spring Data JPA считается швейцарским ножом для работы с БД в Java. Однако Spring Data JPA не заслуживает своего триумфа и вот почему...

Пользователи PostgreSQL нередко оперируют аналитическими запросами, при выполнении которых данные сортируются и группируются по разным правилам. За счёт оптимизации вычисления агрегатов и сортировок можно значительно сократить время и стоимость выполнения запросов. Об одной из таких оптимизаций — выборе порядка колонок в выражении GROUP BY — расскажем в этой статье.

Postgres уже умеет перестраивать список группируемых выражений в соответствии с порядком колонок из условия ORDER BY, чтобы исключить дополнительную сортировку и сэкономить вычислительные ресурсы. Мы пошли дальше, реализовали свою идею в дистрибутивах Postgres Pro Standard и Enterprise и вынесли патчи на обсуждение сообщества Postgres (первое и второе) в надежде, что они войдут в ближайшую версию ванильного PostgreSQL.

Привет, Хабр! Язык запросов DAX популярен и эффективен для построения дашбордов в Business Intelligence, и за счет свой функциональной природы DAX в чем-то ближе к реляционной алгебре, по сравнению с SQL. Особенности DAX удобно рассмотреть на основе примеров DAX-запросов, переведенных на реляционную алгебру. В частности, использование ALL в итераторе SUMX в рамках наиболее популярной DAX функции SUMMARIZECOLUMNS позволяет рассмотреть некоторые нюансы DAX. Если интересно описание ALL в DAX с точки зрения реляционной алгебры — добро пожаловать под кат! :)

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

Приветствую! В этой статье поговорим про триггеры в PostgreSQL.

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

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

Привет, Хабр и его читатели! 

Меня зовут Дарья Четыркина, я программист SQL в IT-компании «Автомакон». Предлагаю обсудить проблему, которая может «съедать» производительность вашего SQL Server — фрагментация индексов, в конце статьи будут решения этой ситуации. Если вам важно, чтобы SQL Server всегда работал на полную мощность, эта статья — для вас.

Когда дело касается SQL Server, индексы — это ваши верные помощники: они организуют данные так, что сервер может находить нужные записи быстрее, чем обычный поиск. При этом со временем индексы начинают «разваливаться» и создают массу проблем. Фрагментация индексов — невидимый враг, который замедляет запросы, увеличивает нагрузку на сервер и лишает ваш SQL Server той оптимальной скорости, ради которой и создаются индексы. Разберемся, почему возникает фрагментация индекса, как она вредит производительности и что можно с этим сделать.