Приветствую! В этой статье поговорим про триггеры в 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 той оптимальной скорости, ради которой и создаются индексы. Разберемся, почему возникает фрагментация индекса, как она вредит производительности и что можно с этим сделать.
База данных — это сердце многих приложений, от полнофункциональных корпоративных сайтов до сравнительно простых инструментов, например, для ведения списков покупок и финансовых трекеров. Популярны реляционные базы данных на основе SQL, но в Linux можно собрать более простую и прозрачную альтернативную базу данных.
Посчитаем по пунктам потенциальные грабли и проблемы, с которым встречается DBA на своем рабочем месте. Сколько получилось у вас? Отпишитесь в комментариях.
Привет, Хабр! Одной из важных задач в аналитических запросах является расчет долей, который позволяет узнать, какая часть записей из общего количества по всей таблице соответствует какому-либо критерию. Также нередко полезными оказываются коэффициенты проникновения (в общем-то тоже являющиеся долями). Они позволяют оценить продажи, найти взаимосвязи признаков и сделать много еще чего полезного. Чтобы проводить такого рода расчеты идеально подходит язык DAX. Если Вам интересно, насколько это удобно и как именно сделать это в DAX — добро пожаловать под кат :)
Вход в профессию Data Engineer требует не только владения инструментами для построения данных, но и уверенного знания SQL для решения задач различной сложности.
Несмотря на то, что многие SQL-запросы могут казаться «аналитическими», на практике именно Data Engineers часто отвечают за их написание и оптимизацию. Ведь аналитикам и специалистам по продукту требуется быстрый и точный доступ к данным для их анализа, а это означает, что DE должны обеспечить доступ к нужным данным и помочь в создании запросов для обработки больших объемов информации.
В этой статье я привожу примеры SQL-запросов, которые соответствуют уровню владения языком, необходимому для Junior Data Engineer.
Эта статья открывает цикл о новостях будущей, 18-ой, версии PostgreSQL. Рассмотрим следующие возможности попавшие в июльский коммитфест.
Планировщик: поддержка правого полусоединения хешированием
Планировщик: материализация внутреннего набора строк для соединения вложенными циклами в параллельном плане
Вспомогательные функции планировщика для generate_series
EXPLAIN (analyze): статистика рабочих процессов узла Parallel Bitmap Heap Scan
Функции min и max для составных типов
Имена параметров для функций regexp*
Режим отладки в pgbench
pg_get_backend_memory_contexts: столбец path вместо parent и новый столбец type
Функция pg_get_acl
pg_upgrade: оптимизация работы pg_dump
Предопределенная роль pg_signal_autovacuum_worker
В последние годы большие языковые модели (LLM) стали важной частью бизнес-решений на базе ИИ, применяемых для генерации текста и анализа данных. Однако, большинство разработок ориентированы на англоязычные проекты, что создает сложности для компаний, работающих с русскоязычными данными.
Готовые LLM для русского языка часто показывают низкую точность и ограниченные возможности. Проблемы конфиденциальности также вынуждают компании выбирать локальные модели.
Наша компания давно занимается искусственным интеллектом и стала часто получать подобные запросы от клиентов — создание ИИ-решения с локальной обработкой данных. Мы задались вопросом, какие LLM хороши для таких решений, что мы можем предложить заказчику? Всё это вылилось в большой рисеч разных языковых моделей.
В статье рассмотрим, какие LLM подходят для задач на русском языке, протестируем их по разным параметрам и выявим лидеров. Мы оценили генерацию текста, ответы на вопросы, исправление ошибок и другие функции.
Это предупреждение, которое выведет хибернейт, если для осуществления пагинации ему придется загрузить ВСЕ данные из таблицы, а не по одной странице.
MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!
Третья статья цикла по асинхронному SQLAlchemy 2 посвящена оптимизации кода, обновлению и удалению данных. Рассмотрены улучшения базового класса, подходы к обновлению записей и методы удаления, с акцентом на повышение производительности. Нажмите «Читать», чтобы ознакомиться с материалом.
Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.
Привет, Хабр! При работе с Business Intelligence и дашбордами практически в любой предметной области встречаются даты и календари, поэтому от выбора представления дат и их составных частей (день, месяц, квартал, полугодие, год и т.д.), ключей дат и таблицы с датами зависит производительность всех дашбордов. В этой статье я расскажу о том, как можно оптимизировать работу с датами в Visiology — с использованием DAX и без него. Интересно? Добро пожаловать под кат! :)
Привет, Хабр!
Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.
На примере нашего продукта я расскажу, почему при загрузке CPU наполовину или меньше скорость параллельных вставок на SQL-сервере упирается в «невидимый» предел, а потом и вовсе замедляется. На нашем железе предел был в районе ~120 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.
Уверен многие тру-программисты и без меня знают их, но я решил собрать во едино все реализации циклов через while, которыми я активно пользуюсь, как автоматизатор, тестировщик и разработчик ETL.
Доброго времени суток, товарищи, эта статья, так скажем, продолжение предыдущей статьи об SQLAlchemy 2.0 для новичков, в этой статье мы узнаем что такое Python Generic и как его можно использовать в наших целях при взаимодействии с БД.
В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.
Но как можно понять из наличия этой статьи, что-то пошло не так...
DWH (Data Warehouse или по русски Хранилище данных) - это специализированная система для хранения и управления большими объемами данных, которые объединяются из разных источников с целью анализа и построения отчетов
Короче, это место, где все нужные данные из разных мест собираются и потом ими уже удобно пользоваться - строить разные отчетики, строить ИИ на благо всему человечеству и подобные вещи
Грубо говоря, задача при построении хорошего DWH состоит в том, чтобы построить Базу Данных и все необходимое вокруг него, в которой будут лежать правильные данные в удобном виде и в которую можно слать большие-сложные SQL запросы и не бояться, что что-то сломается и всем этим было удобно пользоваться
Мы, студенты из МИФИ, Даниил и Александр, пришли на стажировку в Сбербанк в департамент SberData, который занимается развитием внутренней корпоративной аналитической платформы (КАП).Это современная платформа с удобными инструментами созданная для закрытия полного спектра потребностей Сбера в работе с данными, таких как хранение, интеграция, разнообразная аналитика, отчетность, моделирование и контроль качества данных. Все эти направления было бы трудно развивать без отдельного R&D подразделения, в составе которого мы и работаем. Сегодня мы хотим поделиться нашим исследованием в области проектирования алгоритмов в выявлении «токсичных» SQL‑запросов с помощью машинного обучения. Почему же запросы называются именно «токсичные»? Они затрачивают на своё выполнение слишком большое количество ресурсов, а именно времени. На самом деле не только время, но для упрощения мы будем считать только время, так как это ключевой параметр.
Статья посвящена исследованию существующих подходов и их апробации на открытых данных. В качестве общедоступных данных были выбраны данные из таких бенчмарков, как TPC‑H и BIRD. Помимо этого, в статье рассматриваются некоторые трудности, с которыми мы столкнулись при работе над задачей, например, генерация данных и SQL‑запросов, а также миграция между диалектами SQL. В конце статьи мы опишем оригинальный подход, к которому по итогу пришли. В следующей статье мы расскажем о применении полученного опыта для реальной промышленной системы.
