Для чего нужен postgresql

Курс молодого бойца PostgreSQL

Хочу поделиться полезными приемами работы с PostgreSQL (другие СУБД имеют схожий функционал, но могут иметь иной синтаксис).

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

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin‘e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

1. Использование временных таблиц

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

Такие таблицы создаются как обычные, но с ключевым словом TEMP, и автоматически удаляются после завершения сессии.

Ключ ON COMMIT DROP автоматически удаляет таблицу (и все связанные с ней объекты) при завершении транзакции.

2. Часто используемый сокращенный синтаксис Postgres

можно записать менее громоздко:

* (две тильды со звездочкой)

Поиск регулярными выражениями (имеет отличный от LIKE синтаксис)
оператор

* (одна тильда и звездочка) регистронезависимая версия

Приведу пример поиска разными способами строк, которые содержат слово text

‘%text%’

* ‘%text%’

3. Общие табличные выражения (CTE). Конструкция WITH

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

Примеры будут примитивны, чтобы уловить суть.

Таким способом можно ‘оборачивать’ какие-либо запросы (даже UPDATE, DELETE и INSERT, об этом будет ниже) и использовать их результаты в дальнейшем.

b) Можно создать несколько таблиц, перечисляя их нижеописанным способом

c) Можно даже вложить вышеуказанную конструкцию в еще один (и более) WITH

По производительности следует сказать, что не стоит помещать в секцию WITH данные, которые будут в значительной степени фильтроваться последующими внешними условиями (за пределами скобок запроса), ибо оптимизатор не сможет построить эффективный запрос. Удобнее всего положить в CTE результаты, к которым требуется несколько раз обращаться.

4. Функция array_agg(MyColumn).

Значения в реляционной базе хранятся разрозненно (атрибуты по одному объекту могут быть представлены в нескольких строках). Для передачи данных какому-либо приложению часто возникает необходимость собрать данные в одну строку (ячейку) или массив.
В PostgreSQL для этого существует функция array_agg(), она позволяет собрать в массив данные всего столбца (если выборка из одного столбца).
При использовании GROUP BY в массив попадут данные какого-либо столбца относительно каждой группы.

Сразу опишу еще одну функцию и перейдем к примеру.
array_to_string(array[], ‘;’) позволяет преобразовать массив в строку: первым параметром указывается массив, вторым — удобный нам разделитель в одинарных кавычках (апострофах). В качестве разделителя можно использовать

Выдаст результат:

Выполним обратное действие. Разложим массив в строки при помощи функции UNNEST, заодно продемонстрирую конструкцию SELECT columns INTO table_name. Помещу это в спойлер, чтобы статья не сильно разбухала.

5. Ключевое слово RETURNIG *

указанное после запросов INSERT, UPDATE или DELETE позволяет увидеть строки, которых коснулась модификация (обычно сервер сообщает лишь количество модифицированных строк).
Удобно в связке с BEGIN посмотреть на что именно повлияет запрос, в случае неуверенности в результате или для передачи каких либо id на следующий шаг.

Можно использовать в связке с CTE, организую безумный пример.

Таким образом, выполнится удаление данных, и удаленные значения передадутся на следующий этап. Все зависит от вашей фантазии и целей. Перед применением сложных конструкций обязательно изучите документацию вашей версии СУБД! (при параллельном комбинировании INSERT, UPDATE или DELETE существуют тонкости)

6. Сохранение результата запроса в файл

У команды COPY много разных параметров и назначений, опишу самое простое применение для ознакомления.

7. Выполнение запроса на другой базе

Не так давно узнал, что можно адресовать запрос к другой базе, для этого есть функция dblink (все подробности в мануале)

Если возникает ошибка:

«ERROR: function dblink(unknown, unknown) does not exist»

необходимо выполнить установку расширения следующей командой:

8. Функция similarity

Функция определения схожести одного значения к другому.

Использовал для сопоставления текстовых данных, которые были похожи, но не равны друг другу (имелись опечатки). Сэкономил уйму времени и нервов, сведя к минимуму ручную привязку.
similarity(a, b) выдает дробное число от 0 до 1, чем ближе к 1, тем точнее совпадение.
Перейдем к примеру. С помощью WITH организуем временную таблицу с вымышленными данными (и специально исковерканными для демонстрации функции), и будем сравнивать каждую строку с нашим текстом. В примере ниже будем искать то, что больше похоже на ООО «РОМАШКА» (подставим во второй параметр функции).

Получим следующий результат:

Если возникает ошибка

«ERROR: function similarity(unknown, unknown) does not exist»

необходимо выполнить установку расширения следующей командой:

Сортируем по similarity DESC. Первыми результатами видим наиболее похожие строки (1— полное сходство).

Необязательно выводить значение similarity в SELECT, можно просто использовать его в условии WHERE similarity(c_name, ‘ООО «РОМАШКА»’) >0.7
и самим задавать устраивающий нас параметр.

P.S. Буду признателен, если подскажете какие еще есть способы сопоставления текстовых данных. Пробовал убирать регулярными выражениями все кроме букв/цифр, и сопоставлять по равенству, но такой вариант не срабатывает, если присутствуют опечатки.

9. Оконные функции OVER() (PARTITION BY __ ORDER BY __ )

Почти описав в своем черновике этот очень мощный инструмент, обнаружил (с грустью и радостью), что подобная качественная статья на эту тему уже существует. Не вижу смысла дублировать информацию, поэтому рекомендую обязательно ознакомиться с данной статьей (ссылка — habrahabr.ru/post/268983/, автору низкий поклон ) тем, кто еще не умеет пользоваться оконными функциями SQL.

10. Множественный шаблон для LIKE

Задача. Необходимо отфильтровать список пользователей, имена которых должны соответствовать определенным шаблонам.

Как всегда, представлю простейший пример:

Имеем запрос, который выполняет свою функцию, но становится громоздким при большом количестве фильтров.

Продемонстрирую, как сделать его более компактным:

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

11. Несколько полезных функций

NULLIF(a,b)
Возникают ситуации, когда определенное значение нужно трактовать как NULL.
Например, строки нулевой длины ( » — пустые строки) или ноль(0).
Можно написать CASE, но лаконичнее использовать функцию NULLIF, которая имеет 2 параметра, при равенстве которых возвращается NULL, иначе выводит исходное значение.

COALESCE выбирает первое не NULL значение

GREATEST выбирает наибольшее значение из перечисленных

LEAST выбирает наименьшее значение из перечисленных

PG_TYPEOF показывает тип данных столбца

PG_CANCEL_BACKEND останавливаем нежелательные процессы в базе

12. Экранирование символов

Начну с основ.
В SQL строковые значения обрамляются ‘ апострофом (одинарной кавычкой).
Числовые значения можно не обрамлять апострофами, а для разделения дробной части нужно использовать точку, т.к. запятая будет воспринята как разделитель

результат:

Все хорошо, до тех пор пока не требуется выводить сам знак апострофа ‘
Для этого существуют два способа экранирования (известных мне)

результат одинаковый:

В PostgreSQL существуют более удобный способ использовать данные, без экранирования символов. В обрамленной двумя знаками доллара $$ строке можно использовать практически любые символы.

получаю данные в первозданном виде:

Если этого мало, и внутри требуется использовать два символа доллара подряд $$, то Postgres позволяет задать свой «ограничитель». Стоит лишь между двумя долларами написать свой текст, например:

Увидим наш текст:

Для себя этот способ открыл не так давно, когда начал изучать написание функций.

Заключение

Надеюсь, данный материал поможет узнать много нового начинающим и «средничкам». Сам я не являюсь разработчиком, а могу лишь назвать себя любителем SQL, поэтому то, как использовать описанные приемы — решать Вам.

Желаю успехов в изучении SQL. Жду комментариев и благодарю за прочтение!
UPD. Вышло продолжение

Источник

Возможности PostgreSQL для тех, кто перешел с MySQL

Крутой varanio буквально на прошлой неделе прочитал на DevConf забойный доклад для всех кто пересел на Посгрес с MySQL, но до сих пор не использует новую базу данных в полной мере. По мотивам выступления родилась эта публикация.

Мы рады сообщить, что подготовка к PG Day’17 Russia идет полным ходом! Мы опубликовали полное расписание предстоящего мероприятия. Приглашаем всех желающих прийти и похоливарить с Антоном лично

Поскольку доклад на DevConf вызвал в целом положительные отзывы, я решил оформить его в виде статьи для тех, кто по каким-то причинам не смог присутствовать на конференции.

Почему вообще возникла идея такого доклада? Дело в том, что PostgreSQL сейчас явно хайповая технология, и многие переходят на эту СУБД. Иногда — по объективным причинам, иногда — просто потому что это модно.

Но сплошь и рядом складывается такая ситуация, когда какой-нибудь условный программист Вася вчера писал на MySQL, а сегодня вдруг начал писать на Посгресе. Как он будет писать? Да в целом также, как и раньше, используя лишь самый минимальный набор возможностей новой базы. Практика показывает, что проходят годы, прежде чем СУБД начинает использоваться более менее полноценно.

Не холивар

Сразу disclaimer: это не статья «мускуль vs посгрес». Переходить на посгрес или нет — ваше дело. Uber, к примеру, перешел обратно на MySQL по своим каким-то причинам.

Надо отдать должное Oracle, они явно двигают MySQL в правильном направлении. В 5.7 сделали strict mode по умолчанию. В восьмой версии обещают CTE и оконные функции, а также избавление от движка MyISAM в системных таблицах. Т.е. видно, что в базу вкладываются ресурсы, и хотелки юзеров исследуются очень серьёзно.

Однако в PostgreSQL по прежнему полным полно уникальных фич. В итоге я попытался сделать краткий обзор возможностей базы для разработчика.

Встроенные типы данных

В базу встроено множество типов данных, помимо обычных числовых и строковых. А также операторы для их взаимодействия.

Например, есть типы cidr, inet, macaddr для работы с ip адресами.

Или например, время с таймзоной (timestamptz), интервал времени и т.д.

Когда я готовил этот слайд, я решил из любопытства посмотреть, а какое смещение времени относительно UTC было 100 лет назад, в 1917 году:

Т.е. москвичи жили по времени UTC+02:31:19.

Кроме перечисленных, есть и другие встроенные типы данных: UUID, JSONB, XML, битовые строки и т.д.

Тип array

Отдельно надо рассмотреть тип «array». Массивы давно и хорошо интегрированы в PostgreSQL. Многомерные массивы, слайсы, операторы пересечения, объединения и т.д. Существует множество функций для работы с массивами.

Есть очень удобная функция, которая так и называется: array. В качестве аргумента подается некий SELECT-запрос, на выходе — результат запроса в виде массива.

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

Создаем собственные типы

Собственные типы можно создавать тремя способами. Во-первых, если вы знаете язык Си, то вы можете создать базовый тип, наравне с каким-нибудь int или varchar. Пример из мануала:

Т.е. создаете пару функций, которые умеют делать из cstring ваш тип и наоборот. После чего можно использовать этот тип, например, в объявлении таблицы:

Второй способ — это композитный тип. Например, для хранения комплексных чисел:

И потом использовать это:

Третий вид типа, который вы можете создать — это доменный тип. Доменный тип — это просто алиас к существующему типу с другим именем, т.е. именем, соответствующим вашей бизнес-логике.

us_postal_code — это более семантично, чем некий абстрактный text или varchar.

Создаем собственные операторы

Можно делать свои операторы. Например, сложение комплексных чисел (сам тип complex мы определили выше):

Создаем собственные правила для преобразования типов

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

Собственно, это всё, теперь можно использовать. Сколько там будет 100 баксов в рублях?

Результат будет таким:

Типы в расширениях PostgreSQL

Описаны правила индексирования. Например, тип ip4r (диапазон IP-адресов) можно проиндексировать индексом GIST по оператору && (и другим). Таким образом, можно сделать таблицу для поиска городов по IP.

Индексы

Partial indexes

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

В посгресе можно сделать индекс не по всей таблице, а по строкам, определенным по заданному условию:

Этот индекс будет хорошо работать на запросах select * from my_money where status = 2 и при этом занимать мало места.

Индексы по выражению

В посгресе можно делать индексы не по одной колонке, а по любому выражению. Например, можно проиндексировать сразу имя с фамилией:

И потом такой запрос будет быстро работать:

Constraints

Помимо стандартных UNIQUE и NOT NULL, в базе можно делать еще и другие проверки целостности. В доменном типе можно прописать check:

который проверяет, что в колонку типа us_postal_code попадут только 5 цифр или 5 цифр, дефис и 4 цифры. Разумеется, сюда можно писать не только регулярки, но и любые другие условия.

Также check можно прописать в таблице:

Т.е. в имени должен быть хотя бы один символ, и не больше 300.

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

Таким образом, иногда композитный тип может быть предпочтительнее, чем jsonb, потому что в json вы можете напихать что угодно вообще.

Частичная уникальность и уникальность по выражению

В отличие от простой уникальности UNIQUE или PRIMARY KEY, в посгресе можно сделать уникальность среди определенного набора строк, заданного условием. Например, email должен быть уникальным среди неудаленных юзеров:

Еще забавная штука: можно сделать уникальность не по одному полю, а по любому выражению. К примеру, можно сделать так, что в таблице сумма двух колонок не будет повторяться:

Constraint Exclude

Ключевое слово EXCLUDE позволяет делать так, что при вставке/обновлении строки, эта строка будет сравниваться с другими по заданному оператору. Например, таблица, содержащая непересекающиеся диапазоны IP (проверяется оператором пересечения && ):

Хранимые процедуры

Хранимые процедуры можно писать на SQL, pl/pgsql, javascript, (pl/v8), python и т.д. Например, можно на языке R обсчитать какую-то статистику и вернуть из нее график с результатом.
Это отдельная большая тема, советую поискать доклад Ивана Панченко на этот счет.

CTE (Common Table Expressions)

Это будет и в MySQL 8, но всё равно давайте кратко остановимся на этом.

CTE — это просто. Вы берете какой-то кусок запроса и выносите его отдельно под каким-то именем.

С точки зрения оптимизации запросов, нужно учитывать, что каждый такой CTE-подзапрос выполняется отдельно. Это может быть как плюсом, так и минусом.

Например, если у вас 20 джойнов с подзапросами и группировками, планировщик запросов может не понять ваших намерений и план запроса будет неоптимальным. Тогда можно вынести часть запроса в cte-подзапрос, а остальное уже дофильтровать в основном запросе.

И наоборот, если вы решили просто для читабельности вынести часть запроса в CTE, то иногда это может выйти для вас боком.

В CTE можно использовать не только SELECT-запросы, но и UPDATE.

Пример: обновить юзеров с возрастом > 20 лет, и в том же запросе выдать имена обновленных вместе с какой-нибудь там страной.

Но тут надо понимать, что иногда с помощью CTE можно хорошо выстрелить себе в ногу.
Такой запрос синтаксически верен, но по смыслу полный бред:

Кажется, что мы прибавили рубль, потом отняли рубль, и должно остаться всё как есть.

Но дело в том, что update1 и update2 при своем выполнении будут брать начальную версию таблицы, т.е. по сути получится так, что один update затрет изменения другого. Поэтому с update внутри CTE надо точно знать, что ты делаешь и зачем.

Оконные функции

Про оконные функции я уже когда-то подробно писал здесь: https://habrahabr.ru/post/268983/. Оконные функции тоже обещают в MySQL 8.

Разное

FILTER

К агрегатным функциям (например, COUNT или SUM), можно дописывать условие FILTER, т.е. агрегировать не все строки, а только ограниченные неким выражением:

Т.е. мы посчитали людей, которым за двадцать, и тех, кому нет двадцати.

\watch

Materialized View

Это как View, только закешированное (материализованное). Кеш можно обновлять с помощью команды REFRESH MATERIALIZED VIEW. Есть также ключевое слово CONCURRENTLY, чтобы Postgres не лочил при обновлении SELECT-запросы.

Listen / Notify

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

Механизм Foreign Data Wrappers позволяет использовать некоторые внешние данные, как простые таблицы. Т.е. к примеру, можно заджойнить постгресовую таблицу, мускульную таблицу, и csv файл.

Sequences

SEQUENCE — это посгресовый аналог MySQL-ного AUTO_INCREMENT. В отличие от MySQL, sequence может существовать отдельно от таблиц или наоборот, «тикать» сразу для нескольких таблиц. Можно задавать различные параметры, например, размер инкремента, зацикливание и проч.

Вместо выводов

Это верхушка айсберга, на самом деле. Есть еще куча нюансов, вообще никак не затронутых в статье, потому что на всё никакой статьи не хватит. По одним только хранимым процедурам можно написать книгу. Или посмотрите, к примеру, полный список sql-команд текущей версии: https://www.postgresql.org/docs/9.6/static/sql-commands.html

Главное, что я хотел показать в статье: несмотря на хайповость, PostgreSQL — очень старая СУБД, в которой очень много чего есть, и которая очень хорошо расширяется. Поэтому при переходе на нее с MySQL рекомендуется полистать мануал, почитать статьи и т.д.

Источник

PostgreSQL или MySQL: какая из этих реляционных СУБД лучше впишется в ваш проект

MySQL — самая популярная реляционная СУБД, а PostgreSQL — самая продвинутая и функциональная. Технический директор компании Xplenty Марк Смоллкомб рассуждает, в каких ситуациях лучше выбрать первую или вторую систему управления базами данных. Мы перевели его статью для тех, кто хочет лучше разобраться в вопросе и понять, что что такое MySQL и PostgreSQL.

Функции СУБД MySQL и PostgreSQL

Практически любой разработчик скажет, что база данных MySQL лучше подходит для веб-сайтов и онлайн-транзакций, а PostgreSQL — для больших и сложных аналитических процессов. Он также добавит, что PostgreSQL поставляется с «множеством отличных функций», таких как расширяемость и нативный функционал NoSQL, что помогает в управлении сложной базой данных. Наконец, он напомнит вам, что MySQL не перегружена функциями, потому что ставит приоритетом «скорость и надежность».

По большей части эти тезисы верны. Хотя базы данных MySQL и PostgreSQL с каждой версией сближаются по функциям (см. таблицу), они все равно отличаются, так что в определенных ситуациях одна система может быть лучше другой.

Сравнение функций

PostgreSQL 10

MySQL 8

Обобщенные табличные выражения (CTE)

Есть (недавно добавили)

Есть (недавно добавили)

Геоинформационные системы (GIS) и идентификаторы системы координат (SRS)

Есть (недавно добавили)

Есть (недавно добавили)

Есть (недавно добавили)

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

Общий обзор MySQL и PostgreSQL

MySQL: общие характеристики

Что такое MySQL? Это быстрая, надежная и универсальная реляционная система управления базами данных (СУБД), самая популярная в мире: по итогам прошлого года ее использовали 39% разработчиков. Хотя ей не хватает обширных возможностей PostgreSQL, она отлично подходит для широкого спектра приложений, особенно для веба.

MySQL — идеальный выбор для масштабируемых веб-приложений. Эта СУБД входит в стандартный стек LAMP — набор веб-приложений с открытым исходным кодом: Linux, Apache HTTP Server, MySQL и PHP. Кроме того, на СУБД MySQL работают популярные системы управления контентом сайтов, такие как Drupal, Joomla и WordPress.

MySQL используют многие сайты в интернете

Вот некоторые характеристики MySQL:

Среди пользователей MySQL DB: Facebook, Google, Flickr, GitHub, NASA, Netflix, Spotify, Tesla, Twitter, Uber, ВМФ США, WeChat, Википедия, YouTube, Zappos, Zendesk.

PostgreSQL: описание и общие характеристики

Система управления базами данных PostgreSQL считается подходящим решением для сложных операций с большими объемами данных. Причина в том, что она лучше справляется с чрезвычайными ситуациями (обсудим это ниже).

Считается, что у PostgreSQL больше функций, чем в других СУБД (пользователи это подтверждают). Кроме того, PostgreSQL — расширяемая система, ее работа базируется на каталогах (подход catalog-driven). Другими словами, она хранит информацию не только о таблицах и столбцах, но и о типах данных, типах индексов, функциональных языках и так далее. Пользователи могут изменять всю эту информацию в системных каталогах, которые выглядят как обычные таблицы.

Другие отличительные черты базы данных PostgreSQL — это объектно-реляционная система, которая совместима с принципами ACID:

Также она поддерживает высокопараллельные вычисления и NoSQL (справедливости ради, база данных MySQL также поддерживает NoSQL с версии 8.0).

Вот некоторые характеристики PostgreSQL:

«PostgreSQL — одна из самых интересных РСУБД с открытым исходным кодом. Она бесплатная, кроме того, предлагает много продвинутых опций. На сегодняшний день PostgreSQL считается самой продвинутой системой управления базами данных. При совершении транзакции тут не нужно ставить блокировки чтения, что дает лучшую масштабируемость. Также этот инструмент управляется не человеком или компанией, а сообществом разработчиков».

Среди пользователей PostgreSQL: Apple, BioPharm, Cisco, Debian, Etsy, Facebook, Fujitsu, IMDB, Instagram, Macworld, Red Hat, Skype, Spotify, Sun Microsystem, Yahoo.

Когда разработчики выбирают MySQL, а когда PostgreSQL

Базу данных PostgreSQL часто выбирают как более функциональный вариант. Как вы увидите в дальнейшем описании, она действительно поставляется с большим количеством дополнительных опций. Тем не менее, когда речь заходит об архитектуре базы данных, в определенных случаях важнее простота, легкость и другие характеристики MySQL. В этом отношении каждая СУБД оптимально проявляет себя в разных областях.

Давайте посмотрим на ключевые особенности баз данных MySQL и PostgreSQL с точки зрения того, почему разработчики СУБД выбирают одну из них.

Основные преимущества базы данных MySQL для разработчиков

Высокая гибкость и масштабируемость: MySQL позволяет выбрать любой из широкого спектра движков хранения данных. Это обеспечивает гибкую интеграцию данных из различных типов таблиц. База данных MySQL 8.0 поддерживает следующие системы хранения таблиц:

Скорость и надежность: отказавшись от некоторых функций SQL, система MySQL сохранила легкость, отдавая приоритет скорости и надежности. Ее скорость особенно очевидна, когда речь заходит о высокопараллельных операциях без записи в базе данных (только чтение). Это отличный выбор для определенных приложений бизнес-аналитики. Но если вам нужно выполнить много сложных запросов под большой нагрузкой, то база данных PostgreSQL может справиться лучше.

Варианты оптимизации сервера MySQL: Предлагается множество вариантов настройки и оптимизации вашего MySQL database server путем настройки переменных, таких как sort_buffer_size, read_buffer_size, max_allowed_packet и так далее.

Простота в использовании и популярность: популярность базы данных MySQL означает, что будет несложно найти администраторов баз данных с большим опытом работы с этой СУБД. Пользователи говорят, что эта система проще в настройке, то есть не требует такой тонкой настройки, как другие СУБД. По этому руководству вы можете убедиться, как легко новичку настроить свою первую базу данных MySQL. Установка и настройка PostgreSQL будет сложнее.

Кроме того, ряд сервисов фронтенда — такие как Adminer, MySQL Workbench, HeidiSQL и dbForge Studio, добавляют к базе данных MySQL графический интерфейс, более удобный и простой, чем работа из командной строки.

Облачная СУБД: MySQL Database хорошо подходит для использования в облаке, многие облачные платформы предлагают соответствующие платные услуги: они готовы установить и поддерживать вашу базу данных.

Управление параллельным доступом посредством многоверсионности (MVCC) и соответствие ACID с движком InnoDB: в текущих версиях MySQL движок по умолчанию — это InnoDB. Он обеспечивает функциональность MVCC и соответствие требованиям ACID. Однако из-за формата таблиц MyISAM в InnoDB на MySQL все равно могут возникнуть проблемы с поврежденными таблицами.

Основные преимущества PostgreSQL для разработчиков

ОРСУБД, а не просто РСУБД. Что такое PostgreSQL? Это объектно-реляционная система, а ее программирование представляет собой своеобразный мостик между объектно-ориентированным и реляционным/процедурным программированием (как C++). Это позволяет определять объекты и наследование таблиц, что порождает более сложные структуры данных. ОРСУБД великолепно подходит для данных, которые не вписываются в строго реляционную модель.

Отлично подходит для сложных запросов, когда нужно выполнить сложные операции чтения-записи с одновременной валидацией данных. Однако ОРСУБД не так хорошо справляется с операциями только чтения (вот где ее превосходит MySQL).

Поддержка NoSQL и большое разнообразие типов данных: PostgreSQL является популярным выбором для функций NoSQL. Она изначально поддерживает большое разнообразие типов данных, включая JSON, hstore и XML. Можете также настроить исходные типы данных и задействовать нестандартные функции.

Спроектирована для управления очень большими базами данных: функции PostgreSQL не ограничивают размер ваших баз данных. Например, по словам администратора баз данных на Adjust.com, у них база данных PostgreSQL управляет базой «примерно на четыре петабайта». Далее он утверждает, что «окружение обрабатывает, а затем записывает в журнал, от 100 до 250 тысяч внешних запросов в секунду». Это действительно тяжелая нагрузка!

Управление параллельным доступом посредством многоверсионности (MVCC): это одна из главных причин, почему компании выбирают Постгрес SQL. MVCC предоставляет одновременный доступ к базе данных множеству агентов на чтение и запись. Это устраняет необходимость каждый раз блокировать чтение-запись, когда кто-то взаимодействует с данными. Таким образом, значительно повышается эффективность управления СУБД и ее производительность.

MVCC обеспечивает такую функциональность через «изоляцию снапшотов» (как ее называет Oracle). Моментальные снимки (снапшоты) представляют состояние данных в определенный момент времени.

Соответствие ACID: База данных PostgreSQL предотвращает повреждение данных и сохраняет их целостность на транзакционном уровне. Подробнее о важности ACID-соответствия читайте здесь (как упоминалось выше, база данных MySQL тоже предлагает соответствие ACID, но могут возникнуть осложнения).

Поддержка пользователей в MySQL и PostgreSQL

Вокруг обеих СУБД сформировались чрезвычайно обширные сообщества, которые всегда готовы помочь, в дополнение к платной поддержке от владельца СУБД или сторонних поставщиков.

Поддержка пользователей MySQL

Как проект с открытым исходным кодом, у базы данных MySQL большое сообщество активистов, готовых бесплатно помочь советами и рекомендациями. Лучший способ получить такую поддержку — обратиться на сайты MySQL и Percona.

«Мне больше всего понравилось, что для базы данных MySQL, как проекта с открытым исходным кодом, в интернете можно найти массу советов и получить помощь совершенно бесплатно. Это особенно полезно для проблем, которые затруднительно решить своими силами. Одно из главных преимуществ MySQL — большая популярность этой СУБД, так что вы найдете огромное сообщество людей, готовых помочь в любом вопросе».

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

Поддержка пользователей PostgreSQL

У базы данных PostgreSQL тоже большое сообщество активистов, которые дают бесплатные советы пользователям, в том числе по IRC и через списки рассылки. Кроме того, можно самостоятельно изучить многочисленные инструкции и книги по PostgreSQL.

Вот что говорит на G2 Crowd один администратор баз данных о поддержке PostgreSQL:

«…самую лучшую поддержку обеспечивает сообщество на форумах, где отвечают на вопросы».

Другой рецензент на G2 Crowd сказал следующее:

«Лично мне показалось, что здесь немного сложнее получить поддержку сообщества или загуглить проблему. Но по мере роста популярности базы данных PostgreSQL поддержка сообщества становится лучше».

Получить поддержку PostgreSQL может быть немного сложнее, потому что:

Что быстрее: MySQL или PostgreSQL

И MySQL, и PostgreSQL считаются одними из самых быстрых СУБД. Не совсем понятно, какая из них быстрее.

«В зависимости от аппаратного обеспечения и конфигурации легко найти бенчмарки, в которых будет побеждать та или иная СУБД. Одна может лучше работать на одноядерной машине с небольшим объемом памяти, а другая лучше масштабируется на несколько процессоров. Одна выигрывает по скорости операций на чтение, а другая — на запись».

Тесты производительности дают противоречивые результаты. Например, Windows Skills отдает предпочтение базе данных MySQL, а Benchw говорит, что PostgreSQL быстрее. В итоге скорость зависит от того, как именно вы используете базу данных. Известно, что PostgreSQL быстрее при обработке массивных наборов данных, сложных запросов и операций чтения-записи. Между тем, MySQL Database считается эффективнее в операциях только на чтение.

Какие языки программирования поддерживают MySQL и PostgreSQL

Поддерживаемые языки базы данных MySQL: C/C++, Delphi, Erlang, Go, Java, Lisp, Node.js, Perl, PHP, R.

С какими операционными системами работают MySQL и PostgreSQL

Рассмотрим, чем отличаются требования к операционной системе в базах данных MySQL и PostgreSQL.

Совместимость MySQL с операционными системами

СУБД MySQL предлагает облачную поддержку и локальную установку в следующих операционных системах и форматах:

Совместимость PostgreSQL с операционными системами

СУБД PostgreSQL предлагает облачную поддержку и локальную установку, обычно ее устанавливают на серверах Linux. Кроме того, доступен веб-сервер PostgREST для работы с базой данной через программные интерфейсы REST API.

«PostgREST является автономным веб-сервером, который превращает вашу базу данных PostgreSQL непосредственно в RESTful API. Конечные точки API и операции определяются структурными ограничениями и разрешениями в базе данных».

База данных PostgreSQL доступна для следующих операционных систем:

Источник