Mysql и postgresql. часть 1. сравнительный анализ

Содержание

Соответствие требованиям ACID

ACID (Atomicity, Consistency, Isolation, Durability) — это комплекс свойств транзакций БД. Соответствие ACID гарантирует, что никакие данные не будут потеряны или устранены в системе в случае сбоя, если даже в ходе одной транзакции произошли множественные изменения.


PostgreSQL совместима с ACID и обеспечивает выполнение всех требований. MySQL работает только с ACID при использовании движков InnoDB и NDB Cluster Storage.

Соответствие SQL — это стандарт, в котором база данных должна выполнять все структурированные рекомендации и стандарты языка запросов

Это очень важно, когда компании хотят работать с гетерогенными базами данных для приложения

Наличие соответствия SQL позволяет очень легко перемещать нужные значения из одной базы данных, совместимой с SQL, в другую, например, Oracle на PostgreSQL или SQL Server. В этом случае нужно учитывать перед принятием решения, какую базу данных выбрать, MySQL vs PostgreSQL l.

PostgreSQL поддерживает большинство основных функций SQL. Из почти 180 функций, необходимых для соответствия Core, PostgreSQL выполняет не менее 160. В настоящее время ни одна из существующих версий системы управления БД не претендует на их полное соответствие.

MySQL частично совместима с некоторыми версиями, например, не поддерживает ограничения CHECK.

Comparison Summary

Below is a summarized comparison chart of PostgreSQL vs MySQL:

Feature PostgreSQL MySQL
Open Source Completely Open source Open source, but owned by Oracle and offers commercial versions
ACID Compliance Complete ACID Compliance Some versions are compliant
SQL Compliance Almost fully compliant Some versions are compliant
Concurrency Support MVCC implementation supports multiple requests without read locks Support in some versions
Security Secure from ground up with SSL support SSL support in some versions
NoSQL/JSON Support Multiple supported features JSON data support only
Access Methods Supports all standards Supports all standards
Replication Multiple replication technologies available:
  • Single master to one standby
  • Single master to multiple standbys
  • Hot Standby/Streaming Replication
  • Bi-Directional replication
  • Logical log streaming replication
Standard master-standby replication:
  • Single master to one standby
  • Single master to multiple standbys
  • Single master to one standby to one or more standbys
  • Circular replication (A to B to C and back to A)
  • Master to master
Materialized Views Supported Not supported
Temporary Tables Supported Supported
GeoSpatial Data Supported Supported
Programming Languages Supported Not supported
Extensible Type System Supported Not supported

datagrip

IDE для баз. Несмотря на то, что продукт относительно свежий, он уже используется повсеместно. В основном за счет того, что сразу встроен в мегапопулярные продукты от компании JetBrains: IntelliJ IDEA, PyCharm, PhpStorm и т.д.

Собственно, эта его встроенность одновременно является и главной киллер-фичей продукта: вы редактируете, например, php-код, в котором есть строка с sql-запросом, и внезапно понимаете, что IDE вам подсказывает (прямо в вашем коде) синтаксис SQL, названия таблиц и их полей, подчеркивает красненьким, если что-то написано не так, форматирует SQL и многое-многое другое. Конечно, в этом же IDE можно делать и то, что умеют другие GUI для баз: просматривать списки таблиц и других сущностей, отдельно делать запросы, экспорт таблиц в разные форматы и многое другое.

Из особенностей я бы отметил следующие вещи:

  • можно выделить несколько insert’ов и нажать «Edit as table» (см. картинку). После чего отредактировать это в удобном табличном виде вместо sql-синтаксиса, причем там же можно добавлять строки, колонки, экспортировать в csv и т.д.
  • Можно сравнивать результаты двух запросов. Это полезно, когда пытаешься упростить сложный запрос, и при этом ничего не сломать.
  • встроенность в код проработана не до конца. К примеру, при переименовывании в каком-либо интерфейсе колонки таблицы, IDE не находит нужные строки с SQL в коде (при этом автокомплит в этих строках работал), и наоборот, находит какую-то чушь.
  • Визуальной разработки не очень много. Т.е. вы можете сделать таблицу, но view уже не можете. Если таблица содержит какие-то id с foreign key (допустим, ссылка на некий словарь), хотелось бы при в вводе данных в таблицу выбирать значения из словаря, а не вбивать айдишки.
  • Если посмотреть таблицу в какой-нибудь из схем, то Datagrip посылает запрос set search_path = имясхемы, что приводит к плохим последствиям, если используется pgbouncer (а он используется почти всегда в случае с php или когда много серверов), так что для dev-разработки лучше использовать разные подключения: для работы кода — через pgbouncer, для ide — напрямую к базе.

Datagrip активно развивается, в частности, исправлены некоторые раздражающие баги с подсветкой синтаксиса.

В целом хороший современный инструмент, рекомендую.

Features of MySQL

  • MySQL is a community-driven DBMS system
  • Compatible with various platforms using all major languages and middleware
  • It offers support for Multi-version concurrency control
  • Compliant with the ANSI SQL standard
  • Allows Log-based and trigger-based replication SSL
  • Object-oriented and ANSI-SQL2008 compatible
  • Multi-layered design with Independent modules
  • Fully multi-threaded, using Kernel Threads
  • Server available in embedded DB or client server model
  • Offers Built-in tools for query analysis and space analysis
  • It can handle any amount of data, up to as much as 50 million rows or more
  • MySQL runs on many varieties of UNIX, as well as on other non-UNIX systems like Windows and OS/2

How Is Coding Different?

Here are three areas of difference between coding with MySQL vs. PostgreSQL that you should be aware of:

  1. Case sensitivity
  2. Default character sets and strings
  3. IF and IFNULL vs. CASE statements

Case Sensitivity

MySQL is not case sensitive. When writing queries, you don’t need to capitalize strings as they appear in the database. PostgreSQL is case sensitive. You need to capitalize strings exactly as they appear in the database or the query will fail.

Default Character Sets and Strings

With certain versions of MySQL, it is necessary to convert character sets and strings to UTF-8. With PostgreSQL, it is not necessary to convert character sets and strings to UTF-8. Moreover, UTF-8 syntax isn’t allowed in PostgreSQL.

IF and IFNULL vs. CASE Statements

In MySQL, it’s perfectly fine to use IF and IFNULL statements. In PostgreSQL, IF and IFNULL statements don’t work. You need to use a CASE statement instead.

Этюд по реализация бизнес-логики на уровне хранимых функций PostgreSQL

Побудительным мотивом к написанию этюда послужила статья «В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров. Так же показалось интересной статья опубликованная 4 года назад — Реализация бизнес-логики в MySQL. Показалось интересным то, что одна и та же мысль-«реализовать бизнес-логику в БД«. пришла в голову не только мне одному. Также на будущее хотелось сохранить, для себя в первую очередь, интересные наработки возникшие по ходу реализации. Особенно учитывая то, что относительно недавно было принято стратегическое решение о смене архитектуры и переносе бизнес-логики на уровень backend. Так, что все, что было наработано, скоро никому не понадобится и никому будет не интересно. Описанные методы не являются каким то открытием и исключительным know how, все по классике и было реализовано неоднократно (я например подобный подход применил 20 лет назад на Oracle).Просто решил собрал все в одном месте. Вдруг кому пригодится. Как показала практика — довольно часто одна и та же идея приходит независимо разным людям. Да и для себя оставить на память, полезно.

Выбор структуры таблиц и обоснование

Мы создадим две таблицы: first_table(rand_num int, some_data varchar(40)) и second_table(rand_num int, rand_group int, some_data varchar(40)). Атрибут some_data нам нужен просто для того, чтобы увеличить объем записи на диск, так что в него можно записывать любой текст. Атрибуты rand_num обеих таблиц будут содержать в себе случайные значения, так же как и атрибут rand_group второй таблицы. Тесты будут проводиться следующим образом:

1) сначала мы будем просто добавлять строки (до 400000 строк) в первую таблицу и замерять время добавления.

 1 firstTableRowCount = len(firstTableRandNums)	#firstTableRandNums - случайные числа для заполнения атрибута rand_num первой таблицы
 2     rowsCountPerQuery = firstTableRowCount  10		#rowsCountPerQuery - количество добавляемых в таблицу строк за один запрос
 3     insertQuery = "insert into first_table values"	#начинаем формировать запрос на добавление
 4     totalInsertTime = 					#totalInsertTime - суммарное время выполнения запросов на добавление строк
 5     for i in range(firstTableRowCount):
 6         insertQuery += ("(%d, 'first_table some_data')" % firstTableRandNumsi])
 7         if (i + 1) % rowsCountPerQuery
 8             insertQuery += ", "
 9         else
10             insertQuery += ";"
11             t = time.time()
12             cursor.execute(insertQuery)			#выполняем запрос на добавление строк
13             totalInsertTime += time.time() - t  
14             print("%d%s" % ((i + 1), totalInsertTime))
15             insertQuery = "insert into first_table values"	#начинаем формировать следующий запрос

Когда же мы будем заполнять вторую таблицу (до 400000 строк), то каждый раз после добавления фиксированного числа строк (40000) мы будем проводить следующие измерения: 1) скорость внутреннего объединения первой и второй таблицы по атрибуту rand_num

1 cursor.execute("select * from first_table" 
2                 " inner join second_table on first_table.rand_num = second_table.rand_num;")
3             selectedList = list(cursor)		#это нужно, чтобы извлечь данные из курсора, иначе результат измерения скорости будет некорректным

2) скорость выборки всех данных из второй таблицы, сортируя их по атрибуту rand_num

1 cursor.execute("select * from second_table order by rand_num;")
2             selectedList = list(cursor)

3) скорость подсчета числа строк второй таблицы, принадлежащих одной группе (rand_group)

1 cursor.execute("select count(*) from second_table group by rand_group;")
2             selectedList = list(cursor)

4) скорость выборки тех строк из первой таблицы, атрибут rand_num которых совпадает с атрибутом rand_num какой-либо строки второй таблицы

1 cursor.execute("select * from first_table where rand_num in (select rand_num from second_table);")
2             selectedList = list(cursor)

5) Скорость обновления атрибута some_data в строках первой таблицы. Но обновлять мы будем не все строки, а только те, которые удовлетворяют условию, описанному в п.4.

1 cursor.execute("update first_table set some_data = 'second_table has %d rows' where rand_num in (select rand_num from second_table);" % (i + 1))

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

Блокировки в PostgreSQL: 1. Блокировки отношений

Два предыдущих цикла статей были посвящены изоляции и многоверсионности и журналированию. В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе может встретиться и другой: замóк. Цикл будет состоять из четырех частей:

  1. Блокировки отношений (эта статья);
  2. Блокировки строк;
  3. Блокировки других объектов и предикатные блокировки;
  4. Блокировки в оперативной памяти.

Материал всех статей основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Общая информация о блокировках


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

2. Архитектура MySQL и PostgreSQL

PostgreSQL – унифицированный сервер баз данных, имеющий единый движок – storage engine. Постгрес использует клиент-серверную модель.

Для каждого клиента на сервере создается новый процесс (не поток !). Для работы с такими клиентскими процессами сервер использует семафоры.

Клиентский запрос проходит следующие стадии.

  1. Коннект.
  2. Парсинг: проверяется корректность запроса и создается дерево запроса (query tree). В основу парсера положены базовые юниксовые утилиты yacc и lex.
  3. Rewrite: берется дерево запросов и проверяется наличие в нем правил (rules), которые лежат в системных каталогах. Всякий раз пользовательский запрос переписывается на запрос, получающий доступ к таблицам базы данных.
  4. Оптимизатор: на каждый запрос создается план запроса – query plan, который передается исполнителю – executor. Смысл плана в том, что в нем перебираются все возможные варианты получения результата (использовать ли индексы, джойны и т.д.), и выбирается самый быстрый вариант.
  5. Выполнение запроса: исполнитель рекурсивно проходит по дереву и получает результат, используя при этом сортировку, джойны и т.д., и возвращает строки. Постгрес – обьектно-реляционная база данных, каждая таблица в ней представляет класс, между таблицами реализовано наследование. Реализованы стандарты SQL92 и SQL99.

Транзакционная модель построена на основе так называемого multi-version concurrency control (MVCC), что дает максимальную производительность. Ссылочная целостность обеспечена наличием первичных и вторичных ключей.

MySQL имеет два слоя – внешний слой sql и внутренний набор движков, из которых наиболее часто используется движок InnoDb, как наиболее полно поддерживающий ACID.

Реализован стандарт SQL92.

С модульной точки зрения код MySQL можно разделить на следующие модули.

  1. Инициализация сервера.
  2. Менеджер коннектов.
  3. Менеджер потоков.
  4. Обработчик команд.
  5. Аутентификация.
  6. Парсер.
  7. Кеш.
  8. Оптимизатор.
  9. Табличный менеджер.
  10. Движки (MyISAM, InnoDB, MEMORY, Berkeley DB).
  11. Логирование.
  12. Репликация.
  13. Сетевое API.
  14. API ядра.

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

Когда клиент подсоединяется к базе, управление передается менеджеру потоков, который создает поток (не процесс!) для клиента, и проверяется его аутентификация.

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

Наиболее важный код находится в файле sql/mysqld.cc. В нем находятся базовые функции, которые не меняются со времен версии 3.22:

В хидере sql/sql_class.h определяются базовые классы: Query_arena, Statement, Security_context, Open_tables_state classes, THD. Обьект класса THD представляет собой дескриптор потока и является аргументом большого количества функций.

Приложения для увеличения скорости

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

PostgreSQL широко используется в огромных системах, где скорость имеет определяющее значение, а данные должны быть корректны. Она поддерживает различные варианты оптимизации производительности, например, Oracle, SQL Server и прилично работает в OLTP/OLAP, когда необходима скорость и детальный анализ данных. Она также хорошо работает с приложениями Business Intelligence, но лучше подходит для приложений Data Warehousing и анализа данных, требующих быстрой скорости чтения/записи Performance PostgreSQL vs MySQL.

MySQL является широко используемой в веб-проектах, которым нужна база данных для простых транзакций. MySQL, когда перегружена тяжелыми нагрузками или при попытке выполнить сложные запросы, хорошо работает в OLAP/OLTP-системах, требующих скорости чтения. В целом, MySQL является достаточно надежной, хорошо работает с высокими сценариями параллелизма и с приложениями Business Intelligence.

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

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

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

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


Вот что один IT-специалист на G2 Crowd говорит о пользовательской поддержке MySQL:

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

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

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

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

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

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

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

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

  • для настройки и использования СУБД требуется больше технических знаний;
  • экспертов по PostgreSQL меньше, чем экспертов по MySQL.

Покрывающие индексы для GiST

«Покрывающий индекс» не просто еще одна фича, которая может пригодиться. Это вещь сугубо практичная. Без них Index Only Scan может не дать выигрыша. Хотя и покрывающий индекс в разных ситуациях эффективен по-разному. Речь здесь будет не совсем о покрывающих индексах: строго говоря, в Postgres появились так называемые инклюзивные индексы. Но, по-порядку: покрывающий индекс — это индекс, который содержит все значения столбцов, необходимые запросу; при этом обращение к самой таблице уже не требуется. Почти. О «почти» и других нюансах можно прочитать в статье Егора Рогова, входящей в его индексный сериал из 10 (!) частей. А инклюзивный индекс создается специально для поиска по типичным запросам: к поисковому индексу добавляются значения полей, по которым искать нельзя, они нужны только для того, чтобы не обращаться лишний раз к таблице. Такие индексы формируются с ключевым словом INCLUDE. Анастасия Лубенникова (Postgres Professional) доработала метод btree так, чтобы в индекс можно было включать дополнительные столбцы. Этот патч вошел в версию PostgreSQL 11. Но патчи для методов доступа GiST/SP-GiST не успели созреть до выхода этой версии. К 12-й GiST дозрел.

MySQL и SQL сервер – сравнение

Что такое MySQL?

Разработанная в середине 90х (позже приобретённая Oracle), MySQL была одной из первый баз данных с открытым исходным кодом и остаётся таковой и до сегодня. Это значит, что существует несколько альтернатив MySQL. Но различия между этими вариантами не слишком явные; синтаксис и основная функциональность остаётся одинаковой.

А что является отличительной чертой MySQL, так это её популярность среди стартап-сообществ. Открытый код и бесплатность даёт возможность разработчикам легко начать с MySQL и изменять свой код, когда понадобится. MySQL обычно используется вместе с PHP(англ.) и Веб-сервером Apache, в дистрибутивах Linux, что и привело к известной аббревиатуре LAMP (Linux, Apache, MySQL, PHP).

Что такое SQL сервер?

SQL сервер также известен, как Microsoft SQL Сервер, появился значительно раньше, чем MySQL. Microsoft разработал SQL сервер в 80х, с обещанием разработать надёжную и расширяемую реляционную СУБД. Они остаются ядром качества SQL сервера по прошествии всех этих лет, и предоставляют незаменимое решение для крупномасштабного корпоративного программного обеспечения.

SQL сервер больше подходит для разработчиков, использующих .NET в качестве языка разработки, как конкурирующей связке PHP для MySQL. Это весьма логично, так как обе платформы принадлежать Microsoft.

EMS Studio

EMS Studio, похоже, работает только под Windows. Это его главный недостаток, потому что, как известно PostgreSQL очень редко используют под виндой.

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

Фичи, которые называют как удобные: auto-complete с алиасами, экспорт результата выполнения запроса в SQL формате (insert), удобный GUI для экпорта базы, возможность выполнять только выделенную часть SQL.

Умеет дебаг pl/pgsql. В общем, много чего умеет, но какой-то выдающейся особенности, что отличало бы от других, я не могу назвать.

Основные характеристики баз данных

MySQL — свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems.


PostgreSQL (произносится «Пост-Грэс-Кью-Эл») — свободная объектно-реляционная система управления базами данных (ORDBMS) (по-русски ОРСУБД или просто СУБД) основанная на POSTGRES, версии 4.2, которая была разработана в Научном Компьютерном Департаменте Беркли Калифорнийского Университета.

Сравнение MySQL и PostgreSQL
Параметры MySQL PostgreSQL
Краткое описание Широко используемая свободная реляционная система управления базами данных Широко используемая свободная реляционная система управления базами данных
Основная модель хранения данных Реляционная база данных Реляционная база данных
Дополнительная модель хранения данных База данных типа Key/Value, документно-ориентированная база данных База данных типа Key/Value, документно-ориентированная база данных
Вебсайт
Документация
Разработчик Oracle PostgreSQL Global Development Group
Дата релиза 1995 1996
Текущая версия 8.0.12, Июль 2018 10.5, Август 2018
Лицензия Открытое программное обеспечение Открытое программное обеспечение
Облачное Нет Нет
Язык реализации С++, C C
Поддерживаемые операционные системы сервера FreeBSD, Linux, Solaris, OS X, Windows FreeBSD, Linux, Solaris, OS X, Windows, NetBSD, OpenBSD, HP-UX, Unix
Схема данных Да Да
Типизация Да Да
Поддержка XML Да Да
Поддержка вторичных индексов Да Да
SQL Да Да
API и другие методы доступа Проприентарное нативное API, ADO.NET, JDBC, ODBC Нативная С библиотека, потоковое API для больших объектов, ADO.NET, JDBC, ODBC
Поддерживаемые языки программирования Ada, C, C#, С++, D, Delphi, Eiffel, Erlang, Haskell, Java, JavaScript (Node.js), Objective-C, OCaml, Perl, PHP, Python, Ruby, Scheme, Tcl .Net, C, С++, Delphi, Java, Perl, PHP, Python, Tcl
Язык написания скриптов на стороне сервера Да Функции определенные пользователем
Триггеры Да Да
Методы разбиения Горизонтальное разбиение, шардинг с MySQL Cluster или MySQL Fabric декларативное разбиение (по диапазону или списку) начиная с PostgerSQL 10.0
Методы репликаций Master-Master, Master-Slave Master-Slave
MapReduce Нет Нет
Концепции согласования Немедленное согласование Немедленное согласованиее
Параллелизм Да Да
Возможность хранения только в памяти Да Нет
Контроль доступа пользователей Концепт пользователей с детальной авторизацией Детальные права доступа в соответствии с SQL стандартом

psql

На первом месте psql, и это неудивительно. Надежный как автомат калашникова, бесплатный, стоит из коробки, что еще надо для счастья? Для редактирования запросов используется редактор, указанный в переменной окружения EDITOR, обычно ставят vim, nano или что-то в этом духе. Ну и вообще, psql — это unix-way, т.е. можно его запускать со своим редактором, своим пейджером для отображения результатов, ему можно на вход подавать sql-запрос через пайп, и вывод направлять куда надо.

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

Ну, и работа в консоли и в виме — это не всех устраивает почему-то 🙂

На самом деле, иногда хочется иметь где-нибудь слева полный список таблиц/вьюх и иметь возможность щелкнуть мышкой по нужной, чтобы посмотреть, что там вообще. Т.е. хоть какой-то GUI. Работа в psql хоть и эффективна, но напоминает работу в темной комнате с маленьким фонариком, освещающим лишь только один объект за раз.

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

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

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

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

  • Windows
  • MacOS
  • Linux (Ubuntu, Debian, Generic, SUSE Linux Enterprise Server, Red Hat Enterprises, Oracle, Fedora)
  • Oracle Solaris
  • FreeBSD
  • Исходный код

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

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

Как сказано на сайте PostgreSQL:

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

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

  • MacOS
  • Solaris
  • Windows
  • BSD (FreeBSD, OpenBSD)
  • Linux (семейство Red Hat Linux, включая варианты CentOS/Fedora/Scientific/Oracle, Debian GNU/Linux и производные, Ubuntu Linux и производные, SuSE и OpenSuSE, другие дистрибутивы Linux)

How Do They Index?

Indexes improve database performance by speeding up SQL queries when dealing with large tables of data. Without indexing a database, queries would be slow and overly taxing for the DBMS. Both MySQL and PostgreSQL offer different indexing options.

MySQL Indexing Types

MySQL index types include:

  • Indexes stored on B-trees, such as INDEX, FULLTEXT, PRIMARY KEY and UNIQUE.
  • Indexes stored on R-trees, such as indexes found on spatial data types.
  • Hash indexes and inverted lists when using FULLTEXT indexes.

PostgreSQL Index Types

PostgreSQL index types include:

  • Hash indexes and B-tree indexes.
  • Partial indexes that only organize information from part of the table.
  • Expression indexes that create an index resulting from expression functions as opposed to column values.

Трюки с SQL от DBA. Небанальные советы для разработчиков БД

  • Перевод
  • Tutorial

Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:

  • АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
  • АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

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


С этим читают