Я уже не раз поднимал в статьях тему [не]эффективной работы с json[b] в PostgreSQL — и как его лучше превращать в выборку, и как можно «транспонировать». Сегодня же рассмотрим некоторые возможности по его генерации на стороне базы.
Pandas — это основная библиотека для работы с данными. Вот несколько приёмов, которые я использую, чтобы быстрее и проще выполнять повторяющиеся задачи по работе с данными.
В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.
Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.
Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?
В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.
Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).
В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.
На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.
Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.
Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?
Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять пусть те же самые настройки 1С.
Цель статьи — подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С.
Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU — 100%, пользователи в истерике». Но начну как раз с процессора :-). Тут есть что рассказать.
Привет, меня зовут Степан Золотухин, я разработчик в Битрикс24. Моя команда работает над такими продуктами, как Почта, Маркетинг, Структура компании, Подписание, CRM-Формы.
Мы делаем очень много клевых и интересных фич, но в этой статье я расскажу о том, как мы работаем с «деревьями» на примере нашего продукта «Структура компании».
Сегодня посмотрим на примере задачки из Advent of Code зачем и как можно обойти ошибку aggregate functions are not allowed in a recursive query's recursive term, возникающую при попытке агрегировать какие-то данные внутри шага рекурсии на PostgreSQL — «если нельзя, но очень хочется, то можно».
Сегодня поговорим о мощной штуке в PostgreSQL, которая одновременно помогает и открывает портал в ад: динамические SQL‑запросы. Динамика — это когда SQL собирается на лету, а не пишется заранее статичным текстом. Звучит неплохо, но при неправильном подходе легко превращается в катастрофу.
В первой части обсуждалось как отличие реализации MVCC в Firebird и PostgreSQL может привести к сложностям при миграции информационной системы. Напоминаю девиз этой серии статей – "Ваши ожидания – это Ваши проблемы". Рассмотрим еще некоторые моменты, которые позволят Вам не находится в состоянии "обманутых ожиданий" при миграции с Firebird на PostgreSQL.
Исторически платформа lsFusion долгое время разрабатывалась как платформа разработки бизнес-приложений. В современном же мире грань между бизнес-приложениями и веб-приложениями постепенно стирается, соответственно одной из основных целей последних версий lsFusion стало превращение ее в том числе в платформу разработки веб-приложений.
Для достижения этой цели в 5-й версии (как и в 4-й) гораздо больше внимания было уделено UI/UX, а не бизнес-логике. Так, существенно расширились возможности кастомизации пользовательского интерфейса, осовременился дизайн, асинхронность большинства процессов вышла на новый уровень и вообще произошло значительное улучшение многих метрик, критически важных при разработке любого современного веб-приложению. Впрочем, обо всем по порядку.
Приветствую! В этой статье поговорим про триггеры в PostgreSQL.
Начнём с базы: триггер в PostgreSQL — это такая функция, которая запускается автоматически при определённом событии в таблице. С триггерами можно автоматизировать массу рутины и освободить приложение от сложных проверок и вычислений, но это палка о двух концах.
MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!
В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.
Но как можно понять из наличия этой статьи, что-то пошло не так...
Продолжаем цикл статей по асинхронной SQLAlchemy в стиле ORM!
Если вы ещё не успели ознакомиться с первой частью, настоятельно рекомендую сделать это, так как сегодняшний материал будет опираться на уже освоенные знания.
Что нас ждёт сегодня?
- Сессии и фабрики сессий: Узнаем, как эффективно управлять сессиями для взаимодействия с базой данных.
- Добавление данных в таблицы: Освоим безопасные методы добавления новых записей с использованием ORM-методов.
- Извлечение данных из таблиц: Погрузимся в мир извлечения данных. Рассмотрим простые запросы и более сложные фильтры для работы с данными.
После прочтения этой статьи вы сможете уверенно добавлять и извлекать данные с помощью SQLAlchemy для любых табличных баз данных.
Не пропустите, будет интересно и полезно!
Написание запросов для решения аналитических задач — это основное занятие тех, кто работает с данными Pinterest. Но подбор подходящих данных и преобразование описания проблемы в корректный и эффективный SQL‑код могут оказаться непростыми делами. Ведь речь идёт о среде, которая быстро меняется, и о значительных объёмах данных, разбросанных по разным местам.
ORM были призваны восполнить пробел между объектно-ориентированными языками программирования, которые предоставляют разработчикам возможность работать с сущностями путем обращения к их интерфейсам, определяемым их чертежами (интерфейсы, классы, структуры), и процедурным подходом, реализуемым движками SQL-серверов. В некоторых случаях сюда же пытаются включить и адаптеры NoSQL хранилищ, вроде MongoDB, но конкретно с ней сильно проще, поскольку документ и так, в целом, предствляет из себя вполне себе сносно организованный объект с полями, маппинг которых в объекты языка программирования весьма тривиален, по сравнению с SQL.
Другая проблема, которую пришлось решать ORM в процессе решения первой — сформировать инструмент, который позволил бы составить правильный SQL-запрос в терминах языка программирования, при этом постараться не потерять в доступных "в сыром виде" средствах выражения на соответствующем SQL-серверу диалекте.
