Рубрика «postgresql» - 29

Когда твой парень - fullstack

Когда твой парень — fullstack

Работая программистом и проживая в пяти минутах ходьбы от офиса, крайне тяжело успеть «отойти» от работы, отойдя от работы.

Я думаю, многим это знакомо: последние полчаса ты сидишь и думаешь над непонятно откуда взявшейся неочевидной ошибкой и в итоге, так и не решив проблему, проверяешь, что все твои сегодняшние коммиты улетели в корпоративный репозиторий, выключаешь машину и выходишь из кабинета, зная, что завтра с утра на свежую голову всё решится.

Как бы не так!

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

И вот однажды она приходит к тебе и торжественно заявляет:
— Я готова! Готова учиться программированию! Давай!

В этой статье не будет исходных кодов, в ней я постараюсь ответить на вопросы, которые встали передо мной на этапе планирования курса по программированию для собственной девушки.

О том, как я, не имея никакого практического опыта в обучении, решил ввести в программирование человека, объяснившего, что «ты же умный» и «всё у нас получится», расскажу под катом.

Добро пожаловать!

Читать полностью »

Буквально на днях Яндекс открыл доступ для beta-пользователей к своему новому сервису — Яндекс.Облако. Так вышло, что это событие совпало с необходимостью выбора облачной платформы для одного из наших внутренних проектов и я решил сразу протестировать производительность решений Яндекса.

Для теста я взял PostgreSQL и старый добрый pgbench. Выбор на СУБД пал потому что было интересно протестировать и сравнить производительность не только виртуальных машин, то и managed database сервисов.

Disclaimer: автор не является ни профессиональным админом, ни DBA, ни специалистом по настройке облачных решений. Тестирование проводилось сугубо в личных целях и на объективность не претендует, поэтому прошу воспринимать статью «as is». Внутри не будет какого-то глубокого разбора, но будет экспресс-сравнение с Selectel VPC (на разных дисках) и различными конфигурациями AWS EC2/RDS в части производительности и стоимости решений. Возможно, это сэкономит кому-то немного времени.

Подробности Yandex.Cloud vs Selectel VPC vs AWS под катом.
Читать полностью »

Часть I. R извлекает и рисует

Конечно, PostgreSQL с самого начала создавалась как универсальная СУБД, а не как специализированная OLAP-система. Но один из больших плюсов Постгреса — в поддержке языков программирования, с помощью которых из него можно сделать что угодно. По изобилию встроенных процедурных языков ему просто нет равных. PL/R — серверная реализация R — любимого языка аналитиков — один из них. Но об этом позже.

R – удивительный язык со своеобразными типами данных — list, например, может включать в себя не только данные разных типов, но и функции (вообще, язык эклектичный, и говорить о принадлежности его к определенному семейству не будем, чтобы не порождать отвлекающие дискуссии). В нем есть симпатичный тип данных data.frame, который подражает таблице РСУБД — это матрица, у которой столбцы содержат разные типы данных, общие на уровне столбца. Поэтому (и по другим причинам) работать в R с базами данных довольно удобно.

Мы будем работать в командной строке в среде RStudio и соединяться с PostgreSQL через драйвер ODBC RpostgreSQL. Их несложно установить.

Поскольку R создавался как этакий вариант языка S для тех, кто занимается статистикой, то и мы приведем примеры из простенькой статистики с простенькой графикой. У нас нет цели знакомить с языком, но есть цель показать взаимодействие R и PostgreSQL.

Обрабатывать данные, хранящиеся в PostgreSQL, можно тремя путями.
Читать полностью »

Привет! Представляю вашему вниманию перевод статьи «Architecture of a high performance GraphQL to SQL engine».

Это перевод статьи про то, как устроен изнутри и какие оптимизации и архитектурные решения несет в себе Hasura — высокопроизводительный легковесный GraphQL сервер, выступающий прослойкой между вашим веб-приложением и базой данных PostgreSQL.

Он позволяет генерировать GraphQL схему на основе существующей базы данных или создать новую. Поддерживает GraphQL Subscriptions из коробки на основе Postgres-триггеров, динамический контроль прав доступа, автоматическую генерацию join’ов, решает проблему N+1 запросов (batching) и многое другое.

Hasura. Архитектура высокопроизводительного GraphQL to SQL сервера - 1

Читать полностью »

Началось все с небольшого эксперимента по установке сервера обмена сообщениями Synapse на смартфоне с операционной системой Ubuntu Touch, а закончилось созданием маленького домашнего дата-центра на 5 ARM мини-серверах (Raspberry Pi и ODROID-XU4), основная функция которых — обеспечение работы системы обмена сообщениями / звонками по протоколу Matrix и WebRTS для 10 пользователей.
Готовим Matrix в домашних условиях - 1
Matrix — это открытый протокол мгновенного обмена сообщениями (базирующийся на децентрализованных серверах), который позволяет пользователям осуществлять обмен текстовыми сообщениями и файлами, выполнять голосовые и видео звонки, создавать чат-каналы и т.п.

Наиболее известный клиент для сети Matrix — Riot.im, реализован в виде мобильного, web или десктопного приложения. По функциональности не уступает клиентам современных мессенджеров Slack / Telegram / WhatsApp.
Читать полностью »

Генерал Авайлабилити PostgreSQL 11 - 1

Специальный выпуск POSTGRESSO, посвященный выходу официального релиза версии 11.


На улице PostgreSQL праздник. После четырех beta вышла PostgreSQL 11 General Availability, то есть официальная версия. В анонсе есть даже приветственное слово Брюса Момжана: «готовя этот релиз, сообщество особенно заботилось о добавлении функциональности, необходимой для работы с очень большими базами данных. Доказано, что PostgreSQL хорошо работает с транзакционными нагрузками, а теперь новая версия — PostgreSQL 11 — облегчит разработчикам еще и создание приложений для Big Data».

В release notes выделяют

  • секционирование:
    • добавлено секционирование по хешу;
    • PRIMARY KEY, FOREIGN KEY, индексы (см. ниже на эту тему) и триггеры;
    • секция по умолчанию для записей, вышедших за границы созданных секций;
    • UPDATE по ключу секционирования теперь может автоматически перемещать запись в соответствующую секцию;
    • PostgreSQL научился исключать ненужные секции (partition pruning) во время исполнения запросов SELECT;
  • распараллеливание:
    • теперь можно параллельно создавать индекс в случае B-tree;
    • при CREATE TABLE… AS, CREATE MATERIALIZED VIEW и в некоторых случаях запросов с UNION;
    • улучшена производительность в параллельных HASH JOIN и SEQUENTIAL SCAN;
  • появились хранимые процедуры, и в них возможно управление транзакциями;
  • JIT-компиляция некоторых запросов, выигрыш на вычислении выражений;
  • оконные функции теперь поддерживают все фреймовые опции SQL:2011 стандарта, в том числе расстояния по RANGE у PRECEDING/FOLLOWING, режим GROUPS, возможность исключения строк из фрейма;
  • появились покрывающие индексы [не покрывающие, а инклюзивные, строго говоря — прим. POSTGRESSO], использующие выражение INCLUDE при CREATE INDEX;
  • из раздела «разное»: ALTER TABLE… ADD COLUMN c значениями NOT NULL по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.

Читать полностью »

Вышел PostgreSQL 11 - 1

Специальный выпуск POSTGRESSO, посвященный выходу официального релиза версии 11.


На улице PostgreSQL праздник. После четырех beta вышла PostgreSQL 11 General Availability, то есть официальная версия. В анонсе есть даже приветственное слово Брюса Момджана: «готовя этот релиз, сообщество особенно заботилось о добавлении функциональности, необходимой для работы с очень большими базами данных. Доказано, что PostgreSQL хорошо работает с транзакционными нагрузками, а теперь новая версия — PostgreSQL 11 — облегчит разработчикам еще и создание приложений для Big Data».

В release notes выделяют

  • секционирование:
    • добавлено секционирование по хешу;
    • PRIMARY KEY, FOREIGN KEY, индексы (см. ниже на эту тему) и триггеры;
    • секция по умолчанию для записей, вышедших за границы созданных секций;
    • UPDATE по ключу секционирования теперь может автоматически перемещать запись в соответствующую секцию;
    • PostgreSQL научился исключать ненужные секции (partition pruning) во время исполнения запросов SELECT;
  • распараллеливание:
    • теперь можно параллельно создавать индекс в случае B-tree;
    • при CREATE TABLE… AS, CREATE MATERIALIZED VIEW и в некоторых случаях запросов с UNION;
    • улучшена производительность в параллельных HASH JOIN и SEQUENTIAL SCAN;
  • появились хранимые процедуры, и в них возможно управление транзакциями;
  • JIT-компиляция некоторых запросов, выигрыш на вычислении выражений;
  • оконные функции теперь поддерживают все фреймовые опции SQL:2011 стандарта, в том числе расстояния по RANGE у PRECEDING/FOLLOWING, режим GROUPS, возможность исключения строк из фрейма;
  • появились покрывающие индексы [не покрывающие, а инклюзивные, строго говоря — прим. POSTGRESSO], использующие выражение INCLUDE при CREATE INDEX;
  • из раздела «разное»: ALTER TABLE… ADD COLUMN c значениями NOT NULL по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.

Читать полностью »

Введение

Привет!

Хочу поделиться опытом написания миграций для postgres и django. Речь в основном пойдёт про postgres, django же здесь хорошо дополняет, так как из коробки имеет автоматическую миграцию схемы данных по изменениям модельки, то есть имеет довольно полный список рабочих операций по изменению схемы. Django можно заменить на любой любимый фрэймворк/библиотеку — подходы скорее всего будут похожи.

Не буду описывать как я к этому пришёл, но сейчас читая документацию ловлю на мысли, что нужно было с большей внимательностью и осознанием делать это раньше, поэтому очень рекомендую.

Перед тем как пойти дальше позволю себе сделать следующие предположения.

Можно разделить логику работы с базой данных большинства приложений на 3 части:

  1. Миграции — изменение схемы базы данных (таблиц), предположим мы всегда запускаем их в один поток.
  2. Бизнес логика — непосредственная работа с данными (в пользовательских таблицах), работает с одними и теми же данными постоянно и конкурентно.
  3. Миграции данных — не изменяют схемы данных, работают по сути как бизнес логика, по умолчанию, когда будем говорить про бизнес логику, будем также подразумевать и миграции данных.

Даунтайм — это состояние, когда часть нашей бизнес логики не доступна/падает/грузится на заметное для пользователя время, предположим это пару секунд.

Отсутствие даунтайма может быть критическим для бизнеса условием, которого любыми усилиями нужно придерживаться.Читать полностью »

Репликация является одной из хорошо известных функций, позволяющих создавать идентичную копию базы данных. Она поддерживается практически в любой реляционной системе управления базой данных (РСУБД). Возможность репликации обеспечивает значительные преимущества, в особенности высокую доступность и распределение нагрузки. Но как быть, если требуется репликация между двумя базами данных (БД) с разной структурой, такими как MySQL и PostgreSQL? Можно ли непрерывно осуществлять репликацию изменений из БД MySQL в БД PostgreSQL? Ответом на этот вопрос является инструмент репликации pg_chameleon.

image

Читать полностью »

Дайджест новостей из мира PostgreSQL. Выпуск №10 - 1

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11 Beta 4
В этом релизе починили баги, выявленные после выхода Beta 3. В том числе:

  • теперь отключена по умолчанию JIT-компиляция.
  • имена в constraint-ах должны быть уникальны.
  • убрали утечку памяти при обращении к XMLTABLE
  • исправили ошибки в хранимых процедурах
  • доработали секционирование, в том числе выбор секций в момент исполнения (runtime partition pruning)

Подробнее здесь.

PostgreSQL 10.5
В этом релизе несколько десятков исправлений, касающихся WAL, libpq, VACUUM и FREEZE, индексов GIN, распараллеливания запросов, OpenSSL. Вот их список.

Postgres Pro Enterprise 10.5.2.
В этой версии есть следующие нововведения по отношению к Postgres Pro Enterprise 10.5.1, они касаются pgbench:

  • pgbench теперь поддерживает составные команды;
  • с помощью параметра --latency-limit теперь можно ограничить время, отведённое на повторение транзакций. Если при использовании данного параметра значение --max-tries=0, транзакции могут повторяться неограниченное число раз, пока не истечёт время, заданное параметром --latency-limit;
  • при вычислении количества обработанных транзакций и скорости выполнения (TPS) пропущенные и неуспешные транзакции больше не учитываются.

Напомним, за время между нашими выпусками вышел релиз Postgres Pro Enterprise 10.5.1.. Там есть существенные изменения, о них можно прочитать здесь.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js