Крылья, ноги и хвосты:

Сильные стороны MySQL и когда PostgreSQL завоюет мир

Алексей Копытов

Вступление

intro.jpg

Зачем?!?!

  • обострение дискуссий за последнее время
  • много драмы, неквалифицированных мнений
  • необъективность лидеров PostgreSQL сообщества
  • «MySQL – проприетарщина!»
  • «В MySQL нет транзакций!» («прикручены как-то сбоку»)
  • «Нет причин использовать MySQL!»

propaganda.jpg

Зачем?!?!

  • Серия статей «Памятка евангелиста PostgreSQL» на Хабре
  • «Даёшь сравнение!!!» – самый частый запрос
  • действительно, зачем использовать MySQL?

innodb_users.png

Холивор?!?!

Нет!

  • нет универсального ответа на вопрос «какая СУБД лучше?»
  • PostgreSQL – замечательная СУБД! Нет, серьёзно.
  • но этот доклад не об этом ;)

О чём доклад?

  • о сильных сторонах MySQL
  • как MySQL стал лидирующей СУБД для веб-проектов?
  • почему крупнейшие веб-проекты используют MySQL сейчас?

Ретроспектива: LAMP

– Почему MySQL популярен сейчас?

– Потому что был популярен раньше!

– А почему был популярен раньше?

– Потому что «хостеры» и MyISAM!

Репликация

«Рабочая лошадка» LAMP проектов:

  • горизонтальное масштабирование на чтение
  • высокая доступность (HA)
  • гео-распределённые реплики

earlyweb20.png

Репликация (2)

  MySQL PostgreSQL PostgreSQL (сторонние решения)
2001 логическая statement-based (3.23)    
2004     логическая trigger-based (Slony-I)
2006     логическая statement-based (pgPool-II)
2007     логическая trigger-based (Bucardo, Londiste)
2008 логическая row-based (5.1)    
2010   физическая (9.0)  

Репликация (3)

Репликация в MySQL:

  • появилась раньше любых альтернатив в PostgreSQL
  • встроенная
  • лёгкая в настройке и использовании
  • поддержка DDL, BLOBов, системных таблиц
  • быстрая
  • более производительная альтернатива в PostgreSQL только через 9 лет!
  • но не более функциональная (об этом позже)

Полнотекстовый поиск

  MySQL PostgreSQL
2000 встроенный, для MyISAM (3.23.23)  
2001   contrib: Tsearch
2003   contrib: Tsearch2
2008   встроенный (8.3)
2013 встроенный, для InnoDB (5.6)  

За кадром: сравнение функционала, внешние решения (OpenFTS, Sphinx, Lucene, и т.д.)

UPSERT

  MySQL PostgreSQL
2000 REPLACE INTO, INSERT IGNORE (3.23)  
2004 INSERT … ON DUPLICATE KEY UPDATE (4.1)  
2016   INSERT … ON CONFLICT DO UPDATE/NOTHING (9.5)

Контрольные суммы

Использование контрольных сумм для проверки целостности данных:

  MySQL PostgreSQL
2001 страницы данных  
2002 журнал REDO в InnoDB журнал WAL
2013   страницы данных¹

¹ – отключены по умолчанию

Логические резервные копии

  MySQL PostgreSQL
2009 параллельный импорт/экспорт (myloader/mydumper) параллельный импорт, pg_restore -j (8.4)
2013   параллельный экспорт pg_dump -j (9.3)
     

Index-only scans

  • данные читаются из индексных значений, а не из таблицы:
select count(*) from t; 
select idx from t where idx > key;
select idx from t where idx in (1, 10, 100);
  MySQL PostgreSQL
⩽2000 да  
2012   да, с ограничениями (9.2)

Heap-only tuples

  • UPDATE не трогает индексы при обновлении только неиндексированных колонок:
UPDATE metrics SET value = value + 1 WHERE name = 'requests';
  MySQL PostgreSQL
⩽2000 да (MyISAM, InnoDB)  
2008   да, с ограничениями (8.3)

Коммерческая поддержка

earlyweb20.png

  MySQL PostgreSQL
1998 MySQL AB  
2001?   2ndQuadrant¹
2004   EnterpriseDB
  • MySQL – первая open source СУБД с коммерческой поддержкой
  • Монти и первые разработчики в качестве инженеров поддержки
  • исключительное качество поддержки по отзывам клиентов

¹ нет упоминаний в сети до 2008г.

  • есть много исторических причин популярности MySQL
  • "хостеры" и MyISAM скорее следствие, чем причина
  • PostgreSQL часто опаздывал с реализацией важных функций
  • иногда на 10+ лет

mysqlnow.jpg

MySQL сегодня

Что с чем сравнивать?

  • текущие стабильные релизы MySQL и PostgreSQL
  • форки? Да!
  • сторонние решения? Да!
  • только open source, только хардкор!

Движки хранения:

  • концепция похожа на VFS в ядре Linux
  • абстрагируют физическое представление данных/индексов от ядра выполнения запросов
  • могут хранить данные:
    • на диске (MyISAM, InnoDB, CSV, Archive, …)
    • в памяти (Memory)
    • на другом MySQL/MariaDB сервере (Federated{X})
    • на других не-MySQL/MariaDB серверах (Cassandra, Connect)
    • в распределённом кластере (NDB, ScaleDB)
    • в специализированном виде (MyRocks, TokuDB, ColumnStore)
    • или вообще не хранить пользовательских данных (PERFORMANCE_SCHEMA, Pinba)

Движки хранения: InnoDB

  • "рабочая лошадка" современного интернета
  • возможно самая обкатанная и оптимизированная реализация B+Tree

innodb_users.png

InnoDB: кластеризованные индексы

storage_format.png

InnoDB: особенности кластеризованного индекса

Плюсы:

  • запросы по первичному ключу очень быстрые
  • скан первичного ключа обычно приводит к последовательному чтению с диска
  • первичный ключ является покрывающим индексом для любых запросов
  • вторичные индексы являются покрывающими для своих + PK колонок

Минусы:

  • PK нельзя запретить (напр. для импорта)
  • непокрывающие вторичные индексы требуют дополнительную операцию поиска
  • если первичный ключ "толстый", вторичные индексы занимают много места

InnoDB: особенности кластеризованного индекса (2)

Кластеризованные индексы в PostgreSQL:

  • отсутствуют
  • CLUSTER делает одноразовую реорганизацию
  • старый и популярный пункт в PostgreSQL TODO

Плюсы:

  • массовый импорт данных можно оптимизировать
  • нет дополнительных расходов от "толстых" первичных ключей
  • нет дополнительной операции поиска по вторичным ключам

Минусы:

  • многие операции с PK и вторичным индексом медленее

InnoDB: компактность данных

Стандартная таблица sysbench, 1M записей:

  • MySQL
CREATE TABLE sbtest1 (
  id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  k INTEGER UNSIGNED DEFAULT '0' NOT NULL,
  c CHAR(120) DEFAULT '' NOT NULL,
  pad CHAR(60) DEFAULT '' NOT NULL
);
CREATE INDEX k_1 ON sbtest1(k);
  • PostgreSQL
CREATE TABLE sbtest1 (
  id SERIAL NOT NULL PRIMARY KEY,
  k INTEGER DEFAULT '0' NOT NULL,
  c CHAR(120) DEFAULT '' NOT NULL,
  pad CHAR(60) DEFAULT '' NOT NULL
);
CREATE INDEX k_1 ON sbtest1(k);

InnoDB: компактность данных (2)

  data index total
InnoDB 214.70 19.55 234.25
PostgreSQL 211.23 50.10 261.33

innodb_datasize.png

InnoDB: компрессия

MySQL:

  • потабличная компрессия (2008, 5.1+):
    • zlib
    • сжатые + несжатые страницы в buffer pool, только сжатые на диске
    • интенсивное используется интернет-гигантами (Facebook и пр.)
  • постраничная компрессия (transparent page compression) (2015, 5.7):
    • zlib или LZ4
    • несжатые страницы в памяти, сжатые на диске
    • использует "разряжённые" файлы

InnoDB: компрессия (2)

PostgreSQL (TOAST):

  • использует собственный вариант LZ
  • только для длинных (>2 KB) записей
  • только для полей переменной длины
  • каждое поле в записи сжимается отдельно
  • каждое сжатое значение расжимается при каждом чтении
  • каждое сжатое значение пережимается при каждом обновлении

InnoDB: компрессия (3)

Та же таблица (sbtest1, 1M записей)

  data index total
InnoDB 214.70 19.55 234.25
PostgreSQL 211.23 50.10 261.33
InnoDB, zlib 115.38 10.27 125.65

innodb_datasize_compress.png

InnoDB: IO amplification

  • Проблема:
    • при обновлении даже одного байта, нужно записать всю страницу (8/16K)
    • для чтения только одной записи нужно прочитать всю страницу
  • InnoDB:
    • при создании базы: innodb_page_size = 16K (4K, 8K, 16K, 32K, 64K)
    • фиксирован: OS_FILE_LOG_BLOCK_SIZE=512
  • PostgreSQL:
    • при компиляции сервера: BLCKSZ = 8K
    • при компиляции сервера: XLOG_BLCKSZ = 8K (1K, 2K, 4K, 8K, 16K, 32K, 64K)

InnoDB: шифрование

InnoDB:

  • disk-level или column-level шифрование
  • data at rest шифрование в MariaDB 10.1.3 (2015), патч от Google
  • tablespace шифрование в MySQL 5.7.11 (2016), тот же патч?
  • table-level шифрование, ротация ключей

PostgreSQL:

InnoDB: purge

InnoDB:

  • «просто работает»
  • 5 конфигурационных настроек

PostgreSQL: 

select count(*) from pg_settings where name like '%vacuum%';
 count
-------
    23
(1 row)

InnoDB: поддержка O_DIRECT

  • запись данных в обход кэша ядра
  • более рациональное использование памяти
  • нет накладных расходов на двойное кэширование/буферизацию
  • более тонкий контроль над записью на диск
  • появилась в 2003 году (только для файлов данных), используется по умолчанию
  • в 2011 – ALL_O_DIRECT (в Percona Server, MariaDB/XtraDB)

InnoDB: поддержка O_DIRECT (2)

O_DIRECT в PostgreSQL:

  • только для WAL
    • с XLOG_BLCKSZ=8 write amplification взлетает до небес
    • плохо для репликации
  • неэффективное использование памяти (shared_buffers = ~25% RAM)
  • двойная буферизация
  • излишняя работа для контрольных сумм (в будущем: шифрования, компрессии, и т.д.)

InnoDB: поддержка O_DIRECT (3)

MySQL:

  • огромная работа в Percona и Oracle по сглаживанию TPS/latency при интенсивной записи:
    • fuzzy checkpointing, adaptive flushing, parallel flushing, parallel doublewrite

PostgreSQL:

pg_latency_spikes.png

InnoDB: поддержка NUMA

Jeremy Cole, 2010:

Twitter/Percona/MariaDB, 2012:

  • чередование страниц buffer pool + равномерное распределение между нодами
  • numa_interleave
  • innodb_buffer_pool_populate
  • flush_caches

Oracle, 2015:

  • innodb_numa_interleave = numa_interleave + innodb_buffer_pool_populate

PostgreSQL, 2016:

  • BIOS-level interleaving, numactl (плохо!)

InnoDB: поддержка atomic writes

Атомарная запись данных на устройства хранения FusionIO:

  • позволяет отключить doublewrite (аналог full page write в PostgreSQL)
  • до +35% производительности на запись
  • поддержка в MariaDB/Percona с 2013г.
  • поддержка в MySQL с 5.7 (2015)
  • нет поддержки в PostgreSQL (требует O_DIRECT)

InnoDB: buffer pool dump

MySQL:

  • сбросить/восстановить состояние InnoDB buffer pool
  • поддержка в Percona/MariaDB c 2009г.
  • поддержка в MySQL с 5.6 (2013)

PostgreSQL:

  • pg_prewarm (contrib) – загрузить заданную таблицу
  • pg_hibernator (github) – близко, но ограниченно

InnoDB: change buffer

  • оптимизация интенсивной записи
  • применяется при обновлении страниц вторичных индексов
  • если обновляемая страница не в памяти, буферизуем обновление в change buffer
  • при первом страницы с диска, проверяем, нет ли "отложенных" обновленийв change buffer
  • нет аналогов в PostgreSQL

InnoDB: adaptive hash index

  • оптимизация интенсивного поиска по индексам
  • при частом поиске по определённым ключам, добавляем пару (ключ, указатель на данные) в хэш
  • не нужно обходить дерево и искать на странице при каждом поиске
  • ~+10% производительности на некоторых key/value нагрузках
  • нет аналогов в PostgreSQL

InnoDB: transportable tablespaces

На сервере A:

  • FLUSH TABLES t FOR EXPORT
  • копируем .ibd файл на другой сервер
  • таблица остаётся доступной на чтение!
  • UNLOCK TABLES

На сервере B:

  • ALTER TABLE t DISCARD TABLESPACE
  • ALTER TABLE t IMPORT TABLESPACE
  • с 5.7 работает и для отдельных секий в секционированных таблица

Нет аналогов в PostgreSQL.

InnoDB: масштабируемость (RO)

InnoDB: масштабируемость (RW)

Производительность: потоки и процессы

  • MySQL использует потоки, а PostgreSQL процессы
  • fork()/clone() – достаточно быстрая операция в Linux
  • но не такая быстрая, как pthread_create()
  • даже если не учитывать thread cache в MySQL

sysbench, connect test, Linux, Xeon E5-2683v4:

  connect/disconnect time, ms
MySQL 5.7.13 с thread cache 0.20
MySQL 5.7.13 без thread cache 0.40
PostgreSQL 9.5.3 3.73

Медленнее в ~18 раз.

Движки: MyRocks, TokuDB

MyRocks и TokuDB:

  • оптимизированные на запись и SSD устройства движки
  • MyRocks – LSM-деревья, Facebook
  • TokuDB – «фрактальные» индексы, Percona
  • более компактное представление данных на диске
  • продвинутые возможности компрессии
  • низкий write amplification по сравнению с InnoDB
  • оптимизированы для Flash устройств
  • множественные кластеризованные индексы (TokuDB)
  • ничего похожего по характеристикам в PostgreSQL

Движки хранения: NDB

NDB:

  • in-memory хранилище с опциональными чекпойнтингом на диск и хранении неиндексированных данных на диске
  • 99.999% high availability без единой точки отказа
  • масштабируемость на чтение/запись – автоматический шардинг
  • active-active/multi-master репликация
  • несколько NoSQL API (Java, HTTP, Memcached, Node.js)

Движки хранения: NDB (2)

MySQL + NDB:

  • разбор / оптимизация / выполнение SQL
  • несколько SQL API (libmysqlclient, JDBC, ODBC, …)
  • асинхронная репликация

Типичные области применения:

  • телекоммуникации (управление данными абонента)
  • платёжные, финансовые системы
  • PayPal: гео-распределённый кластер на 100 TB для обнаружения мошенничества (fraud detection)
  • Zynga: онлайн игры (сессии)

ndb_users.png

Движки хранения:

  • один алгоритм хранения данных не может подходить всем
  • важная причина популярности MySQL в нагруженных проектах
  • основной источник инноваций в MySQL
  • PostgreSQL тоже к этому придёт
  • к 2020 году уж точно!

Оптимизатор запросов

Оптимизатор: Loose Index Scan

  • появилась в MySQL 5.0 (2005)
  • оптимизирует определённые типы DISTINCT и GROUP BY запросов
CREATE TABLE t1m10cp(a int, b int);
CREATE INDEX t1m10cp_ab on t1m10cp(a,b);
SELECT MIN(b) FROM t1m10cp GROUP BY a;

loose_index_scan.png

Оптимизатор: Loose Index Scan

mysql> explain select min(b) from t1m10cp group by a\G
*************************** 1. row ***************************
	   id: 1
  select_type: SIMPLE
	table: t1m10cp
   partitions: NULL
	 type: range
possible_keys: t1m10cp_ab
	  key: t1m10cp_ab
      key_len: 10
	  ref: NULL
	 rows: 11
     filtered: 100.00
         Extra: Using index for group-by 

mysql> select min(b) from t1m10cp group by a;
+--------+
| min(b) |
+--------+
. . .
+--------+
11 rows in set (0.00 sec)

Оптимизатор: Loose Index Scan

PostgreSQL:

  • не поддерживает Loose Index Scan
  • можно эмулировать с помощью рекурсивных (и громоздких) CTE
  • ручная адаптация запросов под разные варианты
  • полезная статья на тему
sbtest=# explain select min(b) from t1m10cp group by a;
			      QUERY PLAN
-----------------------------------------------------------------------
 HashAggregate  (cost=21370.00..21370.11 rows=11 width=8)
   Group Key: a
   ->   Seq Scan on t1m10cp  (cost=0.00..16370.00 rows=1000000 width=8)

sbtest=# select min(b) from t1m10cp group by a;
 min
-----
. . . 
(11 rows)

 Time: 282.493 ms

Оптимизатор: подзапросы

  • исторически (до 5.6) слабая сторона MySQL
  • огромная работа по оптимизации подзапросов в MySQL 5.6, MariaDB 5.3
  • дальнейшие улучшения в MySQL 5.7, MariaDB 10.0/1
  • отдельные стратегии оптимизации работают лучше, чем в PostgreSQL

Пример коррелированного подзапроса: 

create table t10 (a int, b int);
insert into t10 select a, 1 from ten;
select count(*) from t1m10cp where pk in (select b from t10 where t10.a=t1m10cp.a);

Оптимизатор: подзапросы (2)

MySQL: 

mysql> select count(*) from t1m10cp where pk in (select b from t10 where t10.a=t1m10cp.a);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

Оптимизатор: подзапросы (3)

MySQL: DuplicateWeedout стратегия 

*************************** 1. row ***************************
	   id: 1
  select_type: SIMPLE
        table: t10 
   partitions: NULL
	 type: ALL
	  key: NULL
	 rows: 10
     filtered: 100.00
        Extra: Using where; Start temporary 
*************************** 2. row ***************************
	   id: 1
  select_type: SIMPLE
        table: t1m10cp 
   partitions: NULL
	 type: eq_ref
	  key: PRIMARY
      key_len: 4
	  ref: sbtest.t10.b
	 rows: 1
     filtered: 10.00
        Extra: Using where; End temporary

Оптимизатор: подзапросы (4)

PostgreSQL: «наивное» вычисление подзапроса 

sbtest=# explain analyze select count(*) from t1m10cp where pk in (select b from t10 where t10.a=t1m10cp.a);
						      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=583870.00..583870.01 rows=1 width=0) (actual time=1716.412..1716.412 rows=1 loops=1)
   ->  Seq Scan on t1m10cp  (cost=0.00..582620.00 rows=500000 width=0) 
			    (actual time=1716.411..1716.411 rows=0 loops=1)
	 Filter: (SubPlan 1)
	 Rows Removed by Filter: 1000000
	 SubPlan 1
	   ->  Seq Scan on t10  (cost=0.00..1.12 rows=1 width=4) 
				       (actual time=0.001..0.001 rows=1 loops=1000000)
		 Filter: (a = t1m10cp.a)
		 Rows Removed by Filter: 9
 Planning time: 0.064 ms
 Execution time: 1716.439 ms 
(10 rows)

Оптимизатор: хинты

  • нет идеальных оптимизаторов
  • хинты есть в Oracle, MySQL, SQL Server
  • один из самых популярных запросов от сообщества PostgreSQL

MySQL

  • index hints
    • USE INDEX FOR [FOR {JOIN|ORDER BY|GROUP BY}]
    • IGNORE INDEX [FOR {JOIN|ORDER BY|GROUP BY}]
    • FORCE INDEX [FOR {JOIN|ORDER BY|GROUP BY}]
  • optimizer hints:
    • MAX_EXECUTION_TIME, BKA, MRR, NO_ICP, NO_RANGE_OPTIMIZATION, SEMIJOIN, SUBQUERY

Оптимизатор: трассировка

SET optimizer_trace="enabled=on";
SELECT ...; # your query here
SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
...
	 {
	    "transformation": {
	      "select#": 2,
	      "from": "IN (SELECT)",
	      "to": "semijoin",
	      "chosen": true,
	      "evaluating_constant_semijoin_conditions": [
	      ]
	    }
	  },
  • трассировка процесса принятия решений планировщиком:
    • порядок таблиц в JOIN
    • трансформация запросов, подзапросов
    • применимые методы доступа и т.д.
  • появилась в MySQL 5.6
  • отсутствует в PostgreSQL

Секционирование (partitioning)

  MySQL PostgreSQL комментарий
?   наследование таблиц встроенное, trigger-based, RANGE, LIST, недекларативное, ручное управление, проблемы с большим кол-вом секций
2008 декларативное, 5.1   встроенное, RANGE, LIST, COLUMNS, KEY, HASH
2012   pg_partman внешнее, наследование, но с автоматизация ручной работы, только time и serial ranges
2016   pg_pathman внешнее, (beta?), недекларативное
???   декларативное встроенное, 9.7?

Репликация

Логическая репликация в MySQL:

  • длинный эволюционный путь от statement-based до row-based, от одно-поточной до параллельной
  • менее производительная, чем физическая в PostgreSQL на определённых нагрузках.
  • на каких и насколько? никто не знает…

booking_mts.png

Репликация (2)

Сильные стороны логической репликации:

  • независимость от физической структуры данных
  • позволяет иметь разные схемы на мастере и слейве (при условии обратной совместимости)
  • нет ограничений на чтение со слейвов
  • сложные топологии: каскадная, multi-source, multi-master, и т. д.
  • временные таблицы
  • частичная репликация
  • компактность

Репликация (3)

Логическая репликация в Booking.com:

  • 2 миллиарда запросов в день
  • ~3500 серверов, 85% в репликации
  • 130 мастеров: ~25 реплицируют на >50 слейвов, 8 реплицируют на >100 слейвов
  • очень сложные топологии + binlog серверы
  • активно используют и развивают параллельную репликацию в MySQL/MariaDB

Репликация (4)

PostgreSQL:

  • хорошая, надёжная, простая в настройке физическая репликация
  • до тех пор, пока возможностей физической репликации хватает
  • logical decoding + PGLogical – наиболее перспективный кандидат
  • но стороннее решение, в beta стадии и с серьёзными ограничениями:
    • нет репликации DDL
    • сложности с репликацией sequences
    • не поддерживает сложные топологии
    • ручной schema-based параллелизм
    • координаты? клонирование? перепозиционирование?

Репликация (4)

Полусинхронная (semi-synchronous) репликация:

  • разработана в Google в 2007г.
  • включена в основное дерево MySQL
  • активно используется и развивается в Facebook
  • коммит на мастере гарантирует получение данных хотя бы одним из слейвов
  • позволяет ослабить durability на мастере и слейвах
  • нет аналога в PostgreSQL (synchronous_standby_names близко по смыслу, но не то)

Galera Cluster

  • внешняя библиотека от Codership
  • включена в MariaDB, Percona XtraDB Cluster
  • параллельная (виртуально) синхронная multi-master репликация
  • масштабирование чтений (всегда локальны)
  • масштабирование записи (условно)
  • нет централизованного управления / единой точки отказа
  • автоматическое включение/исключения узлов
  • автоматическое создание/пересоздание узлов (node provisioning)
  • нет аналогов в PostgreSQL

Резервные копии

Сравнение возможностей утилит физического резервного копирования:

  Percona XtraBackup pg_basebackup barman
полные ✔ ✔ ✔
кросс-платформенные ✔    
инкрементальные ✔   ✔¹
частичные ✔   ✔
параллельные ✔    
сжатые ✔    
"компактные" ✔    
зашифрованные ✔    
облачные ✔    

¹ – очень ограниченно и медленно (rsync)

PERFORMANCE_SCHEMA

  • мета-движок для сбора статистики работы сервера
  • не только ожидание, частично перекрывается с pg_stat_*
  • появилась в 5.5 (2010)
  • много оптимизаций, улучшений в 5.6 и 5.7
  • статистика по ожиданиям на блокировках, IO
  • sys schema в 5.7 (user/dba-friendly обёртка)
  • нет аналогов в PostgreSQL (9.5)

Event Scheduler

Планировщик заданий.

MySQL:

  • встроенный, начиная с 5.1

PostgreSQL:

  • встроенный отсутствует
  • cron (-репликация, -бэкапы)
  • внешние: pgAgent, jpgAgent

Аутентификация

  • MySQL:
    • данные аутентификации + авторизации в системных таблицах (mysql.*)

    • разрешить аутентификацию всем локальным пользователям: 

      CREATE USER ''@localhost;
    • включаются в репликацию, резервные копии
  • PostgreSQL:

    • данные аутентификации в pg_hba.conf, авторизации в системных таблицах 

      local   all             all                                     trust
host    all             all             127.0.0.1/32            trust
host    all             all             ::1/128                 trust
    • требуется ручной перенос при репликации и резервных копиях
    • проблемы в облачных и контейнерных средах

key/value API

Сэкономить время на:

  • разбор SQL
  • открытие, блокировку таблиц
  • построение плана выполнения

MySQL:

  • HandlerSocket (сторонее)
  • memcached (встроенное)

PostgreSQL:

  • нет аналогов

За кадром:

  • работа MVCC для OLTP нагрузок
  • эффективность транзакционного журналирования
  • MySQL Embedded: сервер в виде встраиваемой библиотеки
  • встроенный thread pool
  • поддержка кодировок
  • поддержка Windows в современных версиях MySQL/MariaDB
  • динамические переменные
  • X протокол и MySQL Shell в 5.7.12+
  • компрессия соединений

Когда PostgreSQL завоюет мир?

when.jpg

Когда PostgreSQL завоюет мир?

db-engines.png

Когда PostgreSQL завоюет мир?

  • многие важные для крупных веб-проектов возможности MySQL отсутствуют в PostgreSQL до сих пор
  • реализация их может растянуться на годы (если не десятилетия)
  • MySQL скорее всего останется "самой популярной open source СУБД для веб"
  • а PostgreSQL – "самой продвинутой open source СУБД"
  • выбор СУБД – сложный вопрос
  • бегите от людей, которые предлагают простые ответы! :)

Конец

Вопросы, комментарии, истории?

questions.png