Предисловие
Простой python-cкрипт для парсинга спортивной статистики по баскетболу с популярного сайта
Свободная объектно-реляционная СУБД
Предисловие
Простой python-cкрипт для парсинга спортивной статистики по баскетболу с популярного сайта
Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер), до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.
Для пользователей explain.tensor.ru - нашего сервиса визуализации PostgreSQL-планов, в дополнение к плагину Jetbrains мы создали еще один - с возможностью форматировать запросы и анализировать планы в Eclipse IDE и DBeaver.
Очень часто можно услышать, как люди произносят название СУБД PostgreSQL в следующих вариантах: Постгре́ (наверное, на французский манер) или По́стгре (наверное, по аналогии с произношением названия немецкого бренда Pórsche). Возможно, имеет место быть еще вариант Постгр (по аналогии с Ogre — Огр, хотя на английский манер это бы превратилось по звучанию в Постгэр/Постгэ).
Подробное описание шагов при деплое web-проекта на Django с PostgreSQL, Nginx, Gunicorn.
Задачи статьи - агрегировать информацию из мануалов по деплою, избавить читателя от повторений ошибок и описать теоретически, для чего делаются те или иные шаги, чтобы избежать бездумного копирования и вопросов "почему у меня не работает".
В процессе разработки программ с обращениями к базам данных часто возникает проблема создания SQL-запроса по большому количеству таблиц. Существует два варианта: один сложный запрос с большим количеством Join’ов и условий или несколько простых SQL-запросов с последовательным применением результата обработанного запроса к следующим запросам. Какой более эффективный? Читайте в статье.
Привет, Хабр!
Supabase – это крутой open-source аналог Firebase, с его помощью можно организовать крутые штуки вроде ограничения скорости запросов.
Supabase – это инструмент, который дает возможность создавать масштабируемые серверные решения, используя PostgreSQL. С его помощью можно легко управлять базами данных, аутентификацией, хранением данных и реальным временем, но без всяких vendor lock-ins.
Rate Limiting контролирует поток запросов, чтобы ваш сервер не ушел в нокаут от перегрузки. Это спасает сервера от DDOS-атакти помогает обеспечить более равномерное распределение ресурсов среди пользователей.
В СУБД-строении есть не новая, но не теряющая актуальности задача. Сформулировать её можно примерно так: как убрать возможность суперпользователя взаимодействовать с данными, но оставить ему все возможности по управлению СУБД? Эта функция затребована не только большими компаниями с жёсткими требованиями к информационной безопасности, но и крайне нужна всем, кто попадает под различного вида государственные регуляции, вроде приказа ФСТЭК №64 или страшного GDPR.
Всё это необходимо, чтобы закрыть риски, связанные с доверием как к самому DBA, так и обезопасить себя на случай угона учётной записи злоумышленником.
В этой статье мы хотим поговорить о том, какие есть подходы к решению этой проблемы, какие можно найти реализации на рынке, и что решили сделать мы в Postgres Professional.
В век когда ORM шагает по планете обычный построитель запросов выглядит откатом назад. Однако тут есть нюанс — Sql Query Builder использует пакет версионирования shasoft/db-schema и владеет всей информацией о структуре базы данных. Это позволяет реализовать все стандартные для таких решений функции, прозрачно конвертировать типы данных SQL<=>PHP + реализовать нестандартные возможности в виде выборки данных с использованием КЭШирования. (Просьба не искать логику в SQL запросах в статье и примерах, её там нет. Искусственные примеры предназначены для демонстрации возможностей пакета и никакой другой смысловой нагрузки не несут).
Всем привет! Меня зовут Оксана, я системный аналитик из компании EvApps. Что побудило меня написать эту статью? Я обучаю стажеров – системных аналитиков, и недавно столкнулась с такими вопросами, о которых раньше даже не задумывалась.
Вопросы были связаны с разными видами ключей в базе данных и с тем, как они связаны между собой (тему с реляционными БД мы разбираем на примере PostgreSQL). Я начала искать разные статьи по этой теме, очень много крутого материала на том же «Хабре», но многие вопросы так и остались не раскрытыми. И мне стало интересно разобраться с этими вопросами и «пощупать» все это на практике. В итоге начала изучать документацию PostgreSQL и теорию реляционных баз данных, но чтобы получить ответы, пришлось все проверять на практических примерах.
В этой статье мне хотелось разобрать разные вопросы с доказательными примерами.
В этом посте мы расскажем о примере дедлока в TPC-C для PostgreSQL, причиной которого является исключительно переход на виртуальные потоки Java 21 - и никаких проблем обедающих философов.
Если проект использует реляционную СУБД обязательно возникнет вопрос - как организовать скрипты для сохранения гибкости и уменьшения трудозатрат.
Для пользователей explain.tensor.ru - нашего сервиса визуализации PostgreSQL-планов, мы создали плагин "Explain PostgreSQL" для всех IDE от JetBrains, теперь есть возможность форматировать запросы и анализировать планы непосредственно в IDE.
Как использовать плагин и детали о его разработке читайте ниже.
Часто специалисты, работающие с классическими реляционными базами данных, например, с PostgreSQL, испытывают затруднения в работе при переходе на систему хранения больших данных типа Apache Hive. Это связано с непониманием того, как можно использовать в новой среде уже наработанные подходы и методы работы с данными.
В данной статье рассмотрены некоторые особенности использования языка SQL в реляционных СУБД и Apache Hive. Кроме того, проведен сравнительный обзор возможностей и подходов, а также применение партиционирования на практике.
Материал будет полезен специалистам младших и средних грейдов, которые используют в своей практике SQL, но имеют мало опыта в Hive или Postgres.
Привет, Хабр!
Cколько раз вы сталкивались с ситуацией, когда что-то пошло не так и вам необходимо было в срочном порядке восстановить данные из бдшки, причем так, чтобы это было максимально близко к определенному моменту в прошлом? PITR – наш герой, спасающий наши нервы.
Быстрая установка PostgreSQL (PgAdmin 4, Adminer) на VPS через docker.
Подключиться к своему VPS по SSH.
Для установки надо перейти на Гитхаб
Скопировать одну команду, вставить в терминале и запустить.
Команды скачает bash скрипт, сделает его исполняемым и запустит его.
После ответить на пару вопросов и все готово.
Большинство проблем, связанных с БД, во время разработки остаются незамеченными, потому что мы пишем код и проверяем его правильность только при малой "заполненности" нашей БД. Поэтому, когда приложение выкатывается в продакшн, через некоторое время начинают появляться проблемы с производительностью БД, отдельные части приложения начинают работать всё медленнее и медленнее по мере роста самого БД.
Как выявить и отладить такие проблемы? В этой статье будет показано решение наиболее распространённых проблем с производительностью БД, вызванных неправильной индексацией. Примеры будут приведены для Postgres, MySQL и SQLite.
В процессе изучения бекэнда, как нового для меня направления в программировании, я столкнулся с необходимостью оптимизации управления соединениями. Поискав в интернете существующие решения для библиотеки pqxx
(C++ API для PostgreSQL), я обнаружил, что хотя они и выполняют свою задачу, ни одно из них не соответствовало моим требованиям.
Это побудило меня разработать собственную реализацию пула соединений, которая была бы не только эффективной и масштабируемой, но и предоставляла бы удобный API для работы с транзакциями. Моя цель - создать решение, которое могло бы быть легко интегрировано в любой проект, использующий pqxx
, обеспечивая при этом более высокую производительность и стабильность.
В данной статье я хочу поделиться процессом разработки и обсудить некоторые моменты реализации.
Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".
В этой лекции углубимся в расширенные возможности команды SELECT
: как можно "сложить" и "вычесть" выборки (UNION/INTERSECT/EXCEPT
), или запомнить и использовать в рекурсивных запросах (CTE
), что дают оконные функции (WINDOW
) и соединения (JOIN
).
Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись.
Управление конкурентным доступом является очень важной концепцией в Системе Управления Базами Данных. Оно гарантирует, что одновременное выполнение запросов несколькими процессами или пользователями оставит данные в согласованном состоянии. Особое место занимает доступ к Базе Данных в распределенной системе с множеством конкурирующих за ресурс узлов.
Ваш аккаунт