Постоянно натыкаюсь на высказывания из серии «PostgreSQL слишком сложная база для моего небольшого проекта, поэтому буду продолжать работать с MySQL».
В этой статье я хотел бы показать, что человеку, знающему MySQL, не составит абсолютно никакого труда начать разрабатывать под PostgreSQL
Начну очень из далека
Классический экономический закон спроса и предложения предполагает, что при снижении цены на товар автоматически увеличивается спрос. Однако на практике это не совсем так, потому что люди не обладают полной информацией.
Допустим, вы захотели сделать на завтрак яичницу. И вам нужны яйца.
Чтобы получить ОПТИМАЛЬНЫЙ результат, вам нужно объездить ВСЕ магазины, сравнить цены, качество, послушать отзывы покупателей и наконец выбрать приемлимый для вас товар по минимальной цене. Естественно, никто так не делает, потому что есть большая вероятность умереть от голода, пока всё это осуществляешь.
Или, например, вы сделали наикрутейший стартап, некий сайт, который должен перевернуть мир. Но если о нем никто не знает, то это всё равно что его вообще нет. Нужна реклама, маркетинг и т.д.
Другими словами, важны не только качество и цена продукта, но также и издержки на принятие решения, на какие-то организационные моменты. И всё это очень и очень существенно. В этой статье я хотел бы немного снизить издержки по переходу на СУБД postgresql. Т.е. подсказать “цены на яйца”.
На прошлом pgday Олег Бунин выступил с речью, в которой было сказано много правильных вещей о том, что PostgreSQL, несмотря на всю свою крутость, незаслуженно мало используется в проектах. Приводились разные причины, с большинством из которых я полностью согласен.
Но! При этом Олег привел пример из своей практики, когда он скрепя сердце посоветовал своему клиенту использовать для нового проекта MySQL, потому что нельзя вот так взять и всю команду (которая уже умеет мускуль) с нуля переучить писать на PostgreSQL. Мало книг, курсов, и т.д. И в итоге бизнес от этого пострадает.
Я считаю, что это не совсем соответствует действительности.
Возьмем типичный проект на MySQL. Что там используется? В 99% случаев это простейшие запросы, потому что в этой базе пока что нет ни рекурсивных CTE, ни оконных функций (хотя планируют в будущих версиях), ни кастомных типов данных, ни продвинутой работы с массивами, ни индексов по выражениям, и т.д и т.п.
Давайте проведем сравнение синтаксиса простых запросов на разных базах.
MySQL:
SELECT name FROM users WHERE id = 5;
UPDATE users SET name = 'Иван' WHERE id = 5;
INSERT INTO users (name) VALUES ('Петя');
Postgres:
-- внезапно
SELECT name FROM users WHERE id = 5;
UPDATE users SET name = 'Иван' WHERE id = 5;
INSERT INTO users (name) VALUES ('Петя');
Этого функционала уже достаточно, чтобы написать очень много чего.
Ну ладно, ладно, есть некоторые нюансы.
В MySQL сложные идентификаторы можно экранировать с помощью `, а в посгресе для этого используется " (поэтому в строковых константах надо использовать одинарные кавычки)
В MySQL используется INSERT IGNORE...,
в posgres INSERT … ON CONFLICT…
В посгресе нет функции INET_NTOA, но есть куча способов как сделать тоже самое другими путями.
В MySQL термин называется DATABASE, в postgres тоже самое называется SCHEMA.
В MySQL вам надо писать BIGINT AUTO_INCREMENT, в посгресе bigserial
Есть и другие отличия, такие же в общем-то “масштабные”.
Но скажите, разве так немыслимо сложно разобраться в кавычках и других мелких нюансах?
Мне кажется, что человеку, имеющему, так сказать, головной мозг на плечах, не нужны книги и курсы, чтобы постичь всю невероятную глубину этих отличий. Достаточно мануала или даже тупо StackOverflow.
И это отлично подтверждает практика: множество проектов так и переехали на postgres: сначала всё писали как привыкли 1:1 как на mysql, и только потом, по мере изучения разных фич, стали внедрять новый для себя функционал.
Еще один аргумент часто слышу: “О, ну это какой-то космолет, который я не осилю. Все эти CTE и Partial индексы, лень всё это изучать. Моему проекту достаточно возможностей MySQL ”.
Да блин, для простого проекта не будет вообще никакой разницы между базами. Поэтому с точки зрения разработчика никаких доп издержек не будет от postgres. А если он вырастет (ваш проект), то вам потом могут понадобиться продвинутые особенности базы:
— упрощать сложнейшие запросы с помощью CTE
— делать сразу много всего одним запросом с помощью оконных функций.
— Возможность сделать несколько CREATE TABLE, ALTER TABLE и т.д. в рамках транзакции (и откатить на середине, если что-то пошло не так)
— CREATE INDEX CONCURRENTLY (создавать индекс на больших таблицах, не насилуя базу)
— Materialized View
— Индекс по выражению (вместо генерации и поддержки отдельной колонки для этого дела)
— Partial Index (для ускорения некоторых запросов или, например, для обеспечения уникальности по условию)
— и еще куча разных индексов (gist, gin, brin и т.д).
— работа с массивами, например использование функций unnest и array
— Репликация hot standby
— Наследование таблиц
— кастомные типы данных и правила по конвертации (create type, create cast). Куча расширений сделано на этот счет, например тип ip4r позволяет легко и быстро работать с диапазонами ip адресов (поиск ip в диапазонах можно индексировать gist-индексом)
— кастомные операторы (CREATE OPERATOR). Сам еще не пробовал, но смотрю в эту сторону
— хранимые процедуры на разных языках, например на javascript (plv8) или python
— время с таймзоной (timestamp with time zone)
— быстрое удаление и добавление колонок в таблицах
— индексируемый json (тип jsonb)
— проверка валидности данных через check (в нем можно, к примеру проверить наличие/отсутствие необходимых элементов в json)
— сиквенсы вместо auto_increment (можно делать зацикленные, общие для нескольких таблиц и т.д)
— Foreign Data Wrappers — можно заджойнить в одном запросе таблицу из посгреса, из mysql и csv-файл
— и еще 100500 других фич, расширений и даже форков. Я работаю с посгресом уже давно, но постоянно открываю новые возможности.
Справедливости ради нужно заметить, что mysql, кажется, начал хорошо развиваться и избавляться от легаси. Т.е то, что было в 5.5 и то, что есть сейчас — это уже существенная разница (например, strict mode по умолчанию). Говорят, в следующей версии откажутся от использования myisam в системных таблицах, добавят CTE и оконные функции — это большой шаг вперед. Но субъективно пока что это всё равно очень и очень сильно далеко позади посгреса. Который, тоже, в общем-то, не стоит на месте ( wiki.postgresql.org/wiki/Todo )
Всё, что написано выше, справедливо с точки зрения разработчика. С точки зрения админов и дба базы отличаются, тут уж ничего не скажешь. Впрочем, для простого проекта опять же достаточно гугла и stackoverflow.
Подытожим: чтобы мускульной команде начать проект на посгресе, нужен только человек, который поставит и затюнит базу под конкретный профиль нагрузки. (это, впрочем, справедливо для любой СУБД). Можно нанять для этого дела какого-нибудь дба. А вот сам код написать можно без особых проблем.
Это не просто теоретические рассуждения, я сам работал(ю) в составе проектов, которые смигрились на postgresql безо всяких книг и т.д. И в последствии новички тоже в общем-то без проблем вливаются в разработку. Потому что когда в коде, наконец, появляются продвинутые фичи из посгреса, уже есть люди, у которых можно спросить, что и как.
P.S. Если меня читают DBA, пожалуйста, напишите на хабр внятную статью для новичков «Как поставить и настроить PostgreSQL. Основы.». Имхо такая статья очень нужна.
Комментарии (70)
ibKpoxa
31.05.2016 11:34+1Вопрос денег, окупится переход или нет, если не окупится, то переходить смысла никакого нет, если же внезапно окажется что в итоге будет экономия времени дба, разрабов, или экономия на железе, то это надо считать, не исключено что будет плюс. Переход ради перехода не нужен, как бы красиво не были описаны плюсы postgres, как бы ни была модна это база. Обучать админов за деньги работодателя из-за моды не стоит. Как бы не было, не смотря на моду в некоторых узких кругах хвалить postgres ничто не мешает mysql тихо делать своё дело. В целом этот спор так же холиварен, как спор freebsd vs linux и напоминает, в первую очередь, вопро о том, какой дистрибутив линукса выбрать, ответ тут такой же — как у знакомого гуру. Если ты можешь не облажаться на mysql, а на postgres нет такой уверенности в своих скиллах, то используй mysql, если лучше знаешь postgres, то используй его.
varanio
31.05.2016 12:05+5Ну как-то уж слишком категорично.
Я когда-то хорошо знал turbo pascal, мне надо было на нем остановиться навсегда?
mgremlin
31.05.2016 20:17+1Дело в том, что мускуль и пг делают — для старта проекта — абсолютно то же самое. Разница крайне незначительна. Но специалиста найти на мускуль проще.
В случае с паскалем, все будет не так. То, на чем сейчас приходится писать, от паскаля отличается как небо от земли. И паскаль неконкурентен по сравнению с актуальными языками, и специалистов по нему мало, то есть — явный аутсайдер = хорошо, что не стали останавливаться.
Я использовал PG в паре проектов, потом вернулся к мускулю, потому что команда на новый прожект уж совсем его не захотела. То есть, можно и то, и то. Но вот смысла — не вижу. Оборачиваясь назад, те проекты, которые были сделаны на PG, абсолютно так же отработали бы и на мускуле. Только головняка в процессе было бы меньше.
JC_Piligrim
31.05.2016 12:17Наверное я не оригинален с этой идеей, но всё же — почему бы авторам Postgres не прикрутить «препроцессор» запросов, эдакий «Mysql mode», который все эти BIGINT AUTOINCREMENT будет переводить в знакомый ему bigserial и отдавать на выполнение. Чтобы с мускула на постгрю можно было переключиться простой сменой URN-подключения в конфиге?
Ведь если разница не такая масштабная, как вы утверждаете, то реализовать это будет просто. Но при этом, я думаю, было бы логично, если бы всю эту мелкую дурную работу за человека делала бы машина, а человек уже мог бы, перейдя на Postgres и оценив все его преимущества, уже писал бы новые запросы в postgres-стиле.
Подобный инструмент точно бы помог популяризации постгри в интернетах.varanio
31.05.2016 12:35Ну а как быть с кавычками и т.д.? Есть куча написанного кода, например расширений postgres и т.д., которые не поймут мускульный синтаксис кавычек например. Т.е. они все не будут работать. А смысл тогда? Или перерабатывать вообще всё на свете? Это слишком масштабная переработка. Думаю, посгресовое сообщество не заинтересовано в этом.
Yeah
31.05.2016 12:37
pasha_golub
31.05.2016 16:19Это реализации функций. А тут речь идет о реализации полноценного парсера
alaska332
31.05.2016 14:30+1Да, strict mode «по умолчанию» в mysql — это реальный способ побить конкурентов.
Действительно, БД развивается немыслимыми темпами.
Что и говорить.varanio
31.05.2016 23:31Просто без strict mode там был просто нечеловеческий адъ. Сейчас хотя бы стало похоже на базу. Собственно, тут важнее сам симптом, что mysql наконец-то начал потихоньку двигаться в нужном направлении. Оракл делает хорошее дело.
alaska332
01.06.2016 05:48+1Можно ли назвать изменение одной строки в дефолт конфиге развитием?
Им потребовались годы, чтобы сделать это.varanio
01.06.2016 09:34Когда Oracle купил mysql, то по сути почти сразу же и сделал. А вот до этого — да, годами допиливали какое-то непойми что.
point212
01.06.2016 22:04+1Ага. Только вот админам, привыкшим что 5.5 от 5.4 (условно говоря) не сильно отличается — этот strict mode кровушки попил. Когда ты не можешь понять почему не работает то, что годами ранее всегда работало. И как это победить. И вместо быстрой-легкой установки чего-то приходится въезжать в дебри того «как правильно делать вот это».
qrasik
31.05.2016 14:40+1Слоник радует нас обилием всякого разного, с чем разбираться по факту должен БД-администратор, которого лично у нас нет. А значит надо или нанимать или учить.
Если учить, то про MySQL куча понятных книжек, в том числе и на русском. Плюс инструменты. Плюс даже настройки по-умолчанию в половине случаев прокатывают. Ну и не забываем про то что 5.0 и 5.5 это две большие разницы.
Вот и получается что массовой миграции не предвидеться. Такие дела.
dizzy7
31.05.2016 14:43+4Пару месяцев назад перенесли не самый маленький сайт с mysql на postgres. За счёт того, что сайт был на symfony/doctrine переезд был практически безболезненный, и занял около трёх дней, которые ушли в основном на переписывание запросов с группировкой.
Из плюсов такого перехода:
— Выросла скорость не некоторых сложных запросах в разы, в среднем запросы отрабатывают на 20-30 процентов быстрее
— За счёт более строгой валидации данных выловили несколько ошибок, когда данные не умещались в колонку
— Написание миграций стало нормальной работой за счёт транзакционности alter table
Из минусов:
— Иногда возникают неприятные баги из-за строгой валидации (например после перехода бывали падения на неверных utf-8 последовательнотей в user-agent, который пишется в базу)
— В целом качество поддержки софтом чуть ниже, чем для mysql (некритичные проблемы с doctrine / doctrine-migrations)
by25
31.05.2016 15:57Ананлогично, в новом довольно большом проекте решили использовать postgres, до этого был опыт только с mysql. Используя doctrine 2.5, на данный момент разницы почти никакой не заметили. С doctrine/migrations проблем пока ещё не было.
Пока проект в глубокой альфе, субд не тюнили, просто установили с стандартными настройками и используем. На очень простых выборках — mysql на 20-30% быстрее, более сложные — лидирует postges.dizzy7
31.05.2016 16:09Основная проблема с миграциями — при добавлении к таблице новой колонки NOT NULL приходится переписывать сгенерированный запрос на два запроса вида ALTER xxx DEFAULT 0, ALTER xxx SET NOT NULL. Также в down постоянно попадает строчка создания схемы. В остальном всё работает хорошо.
varanio
31.05.2016 16:15Дефолтные настройки пг совсем убогие. Он видимо рассчитан на то, чтобы запускаться даже на утюге. Прогоните хотя бы автоматическими штуками как pgtune. Это конечно тоже совсем не айс, но хоть что-то, лучше чем полный… дефолт
by25
31.05.2016 17:00Конечно будем занматься оптимизацией, но когда появится время. Для дева пока хватает дефолтных настроек.
kvasvik
31.05.2016 14:43Проблема постгреса не в её «сложности», а в не удобности. На стандартных SQL запросах разницы нет никакой, однако на чуть более сложных запросах сразу же начинают себя проявлять «особенности» постгреса.
Например, пресловутая ON CONFLICT появилась в только в версии 9.5 (sic!), до этого гуру постгреса искренне верили, что если можно решить задачу хранимочкой на пол страницы, то и так сойдёт. Однако, даже в итоге утверждённый вариант, в попытке сделать универсальное решение на все случаи жизни, получился более многословным и неудобным из-за необходимости явно указывать обязательным параметром имя поля, по сравнению с тем же мускулом, который уже много лет умеет это делать автоматически.
Или например функция lastval() по прихоти разработчиков, вместо того чтобы тихо вернуть null, если в таблице нет автоинкрементного ключа, зачем-то откатывает всю транзакцию, делая невозможным её использование в простых ORM, а в других случаях эта функция по сути и не нужна.
И такие грабли заботливо разложены в постгресе на каждом шагу. Поэтому нет ничего удивительного в том, что разработчики из небольших проектов, которым никто не переплачивает за страдания и боль, в угоду мифической производительности и масштабируемости, которая может понадобится, а может и не понадобится, не горят желанием её использовать.
maxru
31.05.2016 14:59+1Да ладно на пол-страницы, двумя запросами подряд всё решается на самом деле.
Drummer_hard
31.05.2016 15:49+1Конечно это не просто два запроса подряд, но и не хранимочка на страницу, это даже не хранимочка а подобие лямбды. По мне так вполне достойная замена ON CONFLICT пока она еще не появилась:
DO $pgfunc$
BEGIN
BEGIN
INSERT INTO ...;
EXCEPTION WHEN unique_violation THEN
UPDATE ...;
END;
END
$pgfunc$
maxru
01.06.2016 18:49Да не то чтобы бесило, даже не напрягало, но дискомфорт в седалищной области вызывало, да.
varanio
31.05.2016 15:47+1> которая может понадобится, а может и не понадобится
В том-то и дело, что пока не попробуешь — не поймешь.
Я вот например без CTE и без нормальной работы сложных запросов уже просто как без рук.
К примеру, мы изредка начисляем компенсации пользователям в зависимости от всяких там средних трат за неделю и фазы луны. Раньше, на mysql частенько приходилось делать промежуточные временные таблицы. В пг — просто пишешь километровый запрос на CTE
plumqqz
31.05.2016 15:37+4Или например функция lastval() по прихоти разработчиков, вместо того чтобы тихо вернуть null, если в таблице нет автоинкрементного ключа
Действительно, к чему лишний шум? Об ошибках надо молчать.
point212
31.05.2016 16:49В том то и проблема, что со стороны админа базы ОЧЕНЬ сильно различаются. Например лично я раза три пытался начать развертывать очередное предложение на Postgres вместо Mysql. И все три раза сдавался. Потому что слишком замороченно и сложно. Куча разных несистематизировнных утилит. Большое количество конфигурационных файлов где что-то нужно прописывать.
В то же время мускулом можно начать пользоваться уже сразу после yum install mysql-server; service mysqld start.
И разница тем более заметна, чем менее искушен программист в системном администрировании. Некоторые то и так просят создать им базу, или ребутнуть мускуль.
А так да… в очередной раз подумал — может попробовать въехать в Постгрес опять? А потом — да ну его нафиг…Drummer_hard
31.05.2016 16:54+1в плане администрирования сложнее. Но, честно говоря, не пойму про какие файлы настроек вы говорите. Знаю postgresql.conf, pg_hba.conf. Настройки этих двух файлов хватит чтобы начать работать. Кстати по поводу последнего, он дает очень гибкую возможность настройки прав доступа. В мускуле очень этого не хватало. возможность ограничить подсеть по CIDR это просто сказка. Не говоря о других вичах этого файла.
point212
31.05.2016 16:58-2Я уже не помню, честно говоря, об какие грабли спотнулся в крайний раз. Было это дело более года назад.
Очень не хватает краткой шпаргалочки вида: вы привыкли это делать в мускуле вот так — а вот в постргесе вот такие команды.
На первых порах, чтобы просто запустить этого монстра — хватит.vadv
31.05.2016 23:38+1к сожалению вы выбрали дистрибутив, который требует участия администратора в инициализации кластера: https://wiki.postgresql.org/wiki/YUM_Installation
на debian-like после инсталяции будет запущен работоспособный инстанс (хотя и не утверждаю что это правильнее)point212
01.06.2016 00:38Ну и это разве нормально? Я понимаю что это в целом не проблема СУБД как таковой. Что кто-то с мейнтейнеров схалявил, а мог бы написать нормальный конфигуратор для пакета. Но тем не менее, простому программеру или админу от этого не легче. Сервер уже есть, дистрибутив уже выбран. А вот… увы…
vadv
01.06.2016 10:24Ну и это разве нормально?
кластер например можно инициализировать (а потом это нельзя уже изменить) как с cheksums так и без, конечно у человека должен быть выбор
point212
01.06.2016 21:58А переинициализировать нельзя? Ну в таком случае всё ясно.
Но опять таки… сравнивая мускуль и постгрес — один просто поставил и уже используешь. Не задумываясь ни о каких понятиях типа кластера, как его там инициализировать и так далее. А в другой сначала придется въехать, потом использовать.
Не то чтобы сложно… просто когда это не твоя основная задача на текущий момент — очень не хочется отвлекаться.
VolCh
01.06.2016 02:56Насчёт последнего — можно ли создать пользователя, который сможет подключиться к базе без её перезагрузки?
mdl
01.06.2016 10:20В доках же:
The pg_hba.conf file is read on start-up and when the main server process receives a SIGHUP signal. If you edit the file on an active system, you will need to signal the postmaster (using pg_ctl reload or kill -HUP) to make it re-read the file.VolCh
04.06.2016 11:03То есть нельзя просто средствами SQL создать пользователя и дать ему доступ.
mdl
04.06.2016 14:18+2HBA — это host-based authentication. До есть контроль доступа на уровне файлов (а в UNIX все — файлы).
Если в нем будет разрешено всем все, то да — можно средствами только SQL создать пользователя, доступ у него уже будет.
HBA тут просто как еще один уровень безопасности. В частности с помощью этого механизма пользователь, под которым запущен постгрес на локальной машине с этой же локальной машины может подключаться без ввода пароля через файловый сокет по-умолчанию (во всяком случае, на Debian)VolCh
04.06.2016 14:40+1В MySQL это регулируется на уровне базы. Пользователю может быть разрешено логиниться с любой машины удаленно, с определенного хоста (IP или reverse DNS) или локально через сокет, как с паролем, так и без. И всё это только через SQL. В PostgreSQL система безопасности более строгая и гибкая, но всеми её возможностями можно пользоваться только имея доступ к файловой системе и процессам, как правило это рут-доступ.
mdl
04.06.2016 15:23+3В MySQL не силен нисколько, поэтому не знаю, как там чего реализовано.
Для себя решил, что HBA — это результат попытки разделить ответственность за безопасность между администраторами БД и сисадминами :). Но вообще говоря, RBAC (Role-based auth system) довольно дорогая штука при DoS атаках, а HBA — очень дешевая. Фактически, HBA — это разновидность файрвола.
А вообще, в большинстве своих проектов не залезал в pg_hba.conf. Где это было необходимо (а это доступ к БД через сеть) сперва все равно лезешь в postgresql.conf добавлять интерфейсы в listen_addresses и полностью перезагружаешь кластер. После чего в pg_hba только подкидываются/убираются сети и пользователи, которым разрешен доступ и делается релоад.
Из Security Best Practices могу рекомендовать погуглить 'postgresql security best practices', первые же две ссылки — документы IBM и OpenSCG на эту тему. И там, и там очень хорошо расписано, что зачем.
Наверное, в MySQL тоже что-то для этого есть.
point212
31.05.2016 16:55А меж тем разработчику зачастую уметь создать базу, дать к ней доступ пользователю с паролем, и запустить SQL-консоль с коннектом к этой базе нужно уметь так же часто как и собственно SQL-запросы. Аналогично починить базу, удалить, сделать дамп. Залить из дампа.
Плюс пресловутый тюнинг под производительность. Мускуль на ненагруженных проектах даже из коробки работает неплохо. А как тюнить постгрес — это надо еще въехать.
В итоге в очередной раз разворачивая какое-нибудь приложение из двух движков по привычке выбираешь Мускуль. За простоту и понятность.
GoldJee
31.05.2016 18:22+2> Если меня читают DBA, пожалуйста, напишите на хабр внятную статью для новичков «Как поставить и настроить PostgreSQL. Основы.». Имхо такая статья очень нужна.
Могу попробовать написать. Но что кроме
deb apt.postgresql.org/pub/repos/apt YOUR_DISTRO_VERSION_HERE-pgdg main
wget --quiet -O — www.postgresql.org/media/keys/ACCC4CF8.asc | \
sudo apt-key add — sudo apt-get update
sudo apt-get install postgresql-9.5
вы бы хотели увидеть в такой статье? Даже конфиг по умолчанию позволит поиграть со слоником из коробки (знаю, он убог), а какой-то кастомный postgresql.conf и pg_hba.conf сильно зависят от того, как и на каком оборудовании будет использоваться СУБД.varanio
31.05.2016 18:30+2ну вот человек выше пишет
А меж тем разработчику зачастую уметь создать базу, дать к ней доступ пользователю с паролем, и запустить SQL-консоль с коннектом к этой базе нужно уметь так же часто как и собственно SQL-запросы. Аналогично починить базу, удалить, сделать дамп. Залить из дампа.
Плюс пресловутый тюнинг под производительность. Мускуль на ненагруженных проектах даже из коробки работает неплохо. А как тюнить постгрес — это надо еще въехать.
Т.е. по идее надо какие-то простые вещи, которые у вас может быть и вопросов то не вызывали никогда, но у разработчика будет ступор. По верхам хотя бы.
— как установить
— как прописать в hba что нужно
— как запускать / останвливать
— как создать новую базу
— основные моменты в тюнинге, размер shared_buffers и проч
— как создать роль, чтобы с нее можно было залогиниться
— создать дамп / восстановить из дампа
— фиг знает, что там еще, настроить бекапы? репликацию?
olegchir
31.05.2016 23:58+11) Установка (включая создание базы, юзеров, итп) описывается в любом туториале и делается в 3 строчки
2) Всё после apt-get install можно сделать из графического интерфейса pgAdmin, в котором чтобы непонять где находится запуск SQL-консоли и снятие бэкапа — нужно от души постараться. Если вдруг корпоративный стандарт — это Навикат, то там всё едва ли не еще проще
3) А вы думаете, что люди, которые не могут загнать в гугл поисковый запрос «postgresql tuning guide», хорошо разбираются в тюнинге MySQL?
Вот я вижу фразу, «Мускуль на ненагруженных проектах даже из коробки работает неплохо.»
На основании чего был сделан вывод, что Слоник «на ненагруженных проектах» работает плохо, и его надо тюнить?
Зачем вообще тюнить ненагруженный проект? Т.е. понятно, что стартовые настройки не идеальные, но как это можно понять без нагруженного проекта или нагрузочных тестов?
Поднимите руку, кто считает стартовые настройки MySQL идеальными :))point212
01.06.2016 01:051) Если не сложно — приведите эти три строчки здесь. Будет мне подспорье. Или ссылки на понятные мануалы, в которых авторы не растекаются мыслью по древу, но и не «рисуют сову». Мне такие пока не попадались.
Вот в мускуле реально три строчки:
# mysql -uroot -p
# CREATE DATABASE 'db_name';
# GRANT ALL PRIVILEGES ON db_name.* TO db_username IDENTIFIED BY 'db_password';
Ни одного файла редактировать не надо. И лишь одна консольная утилита.
2) ОК. Но зачем эти сложности? Если на сервере не предусмотрен даже веб-сервер, например? Это отвлекаться, настраивать. Понимаю что сейчас это проще простого. Но все же… не всегда всё заводится из коробки, как того хочется. В итоге хотел развернуть к примеру Nagios, а обнаружил себя в три часа ночи, собирающим из исходников особенную версию php :) Ну это я так… к примеру.
3) Сколько я проектов повидал, в которых конфиг мускула практически пустой. И оно как-то работало. Пока к ним не пришла популярность :) В том то и дело. Что, чтобы тюнить мускуль зачастую хватает квалификации даже менеджера веб-магазина. Скопировать конфиг из мануала и вставить в файл. В постгресе такое возможно? Будет позитивный эффект? Везде написано: никогда не используйте его в дефолтной конфигурации. Всегда делайте тюнинг под ваш проект. Только нафиг простому программисту в этом разбираться?
Может быть в мире «большой и грамотной» разработки и есть какие-то ДБА. А в том мире где к примеру живу я (и еще многие) есть только веб-программист, и хорошо если еще полуграмотный линукс-админ, который и мускул то не может настроить. А то зачастую есть только директор и программист.
ЗЫ я не считаю настройи мускуля идеальными. и не считаю мускуль идеальным. Но все же продукт в целом выглядит более простым и логичным, чем постгрес. И осваивается легче и быстрее.
varanio
01.06.2016 08:46+1по первому пункту примерно так (могу ошибиться в деталях, так как не админ ни разу):
sudo -u postgres psql
create role db_user with password '12345' login;
create database blabla owner db_user;
Далее, надо отредактировать pg_hba.conf, в нем например разрешить всем юзерам (или только одному юзеру) логиниться с локалхоста.
host all all 127.0.0.1/32 md5
здесь первое all — это всем базам, второе all — всем юзерам.point212
01.06.2016 21:59А почему под юзером postgres? Это типа местного root'а?
Как потом зайти в базу blabla от имени юзера db_user? Я имею в виду подключитсья через консоль?vadv
01.06.2016 22:03+2PostgreSQL может авторизовать пользователя не только по паролю, но и по факту того что процесс запущен от пользователя, который совпадает с пользователем базы: http://postgrespro.ru/doc/auth-methods.html#AUTH-IDENT.
SuperUser'ов (аналог root в mysql) в PostgreSQL может быть несколько, по умолчанию это postgres.
Под другим пользователем — psql -U otheruser, советую почитать: http://postgrespro.ru/doc/client-authentication.html
VolCh
01.06.2016 02:59Всё после apt-get install можно сделать из графического интерфейса pgAdmin
Угу, вот только подключиться из pgAdmin к базе может быть не просто.
VolCh
01.06.2016 03:54Несколько месяцев идёт вялотекущий процесс миграции с Мускуля (5.1 :) на Постгри. Из плюсов — в целом заметно шустрее, Doctrine справилась в целом хорошо (только миграции вечно глючат, тщательно надо проверять и в большинстве случаев править руками, есть мысли вообще отказаться от автоматической генерации уж больно опасные вещи может нагенирировать). Минусы — практически в обязательном порядке приходится перерабатывать логику (логику, а не синтаксис) сложных запросов с группировками, подзапросами, и, конечно, переменными. Причём встречаются ситуации, когда запрос, который Мускуль обрабатывает за пару минут, от Постгреса можно за пару часов не дождаться, даже построив функциональные и/или частичные индексы из-за которых казалось мускуль тормозит — механического подхода для трансляции недостаточно, совершенно другие подходы нужно применять. Сильное место оптимизатора Постгри — джойны по результатам подзапросов, на которых мускуль зависал (приходилось делать временные таблицы и индексировать их). Слабое, насколько я могу судить, конструкции типа (очень упрощенно) SELECT t1.id, (SELECT SUM(amount) FROM t2 WHERE t2.t1_id = t1.id ) FROM t1 — очень похоже, что в цикле внутренний запрос Постгри вызывает для каждой строки исходной таблицы, а Мускуль джойнит. Если в каждой таблице порядка миллиона записей…
Отдельная головная боль — администрирование. Особенно если пришла в голову гениальная идея повесить базы разных приложений на один сервер, а потом отреплицировать только одну из них. Да и просто пользователей добавлять. Понятно, что многое приходит с опытом, но если нюансы мускуля впитывал можно сказать десятилетия с ростом сложности задач, и уже интуитивно обходишь узкие места, то тут приходится в сжатые сроки набивать все шишки, разрываясь на части, поскольку всё взаимосвязано.dizzy7
01.06.2016 10:15Можете привести пример опасных вещей в миграции? Нами пока была замечена только некорректная генерация добавления колонок NOT NULL, но в остальном вроде всё в порядке. С чем еще можем столкнуться?
VolCh
04.06.2016 11:26Неразбериха со схемами. Сама Doctrine нормально работает, но миграции бедную public как только не мурыжат. С дефолтными функциональными значениями проблемы были, с кастомными описаниями столбцов, с существующими индексами. Вообще сравнение схем для Postgre очень странно работает, особенно, если используется несколько схем и одна из них public. Она то явно указывается, то считается схемой по умолчанию и сравнение схем одну и ту же таблицу считает разными. А простого способа пофиксить нет — баг годы уже висит, несколько патчей было, но ломают что-то другое, и 100% работающего воркараунда нет. Да и без public бывает, что описываем столбец в маппинге, генерируется миграция ADD COLUMN <что-то>, а потом в каждой следующей миграции генерируется CHANGE column <это же что-то>, хотя маппинг не менялся, то есть Doctrine не понимает, что этот столбец в базе создала она и он не менялся, считает что вид у него неправильный и приводит к нему.
ilyaplot
01.06.2016 09:41+2Согласен с автором статьи. Всю жизнь работал с mysql. Устроился на другую работу, и мне сказали, что тут только postgresql. Ок, погуглил как сделать auto_increment, 10 минут поразмышлял почему не работают `. Все, разработка идет с той же скоростью. Очень жаль, что я раньше не сделал этого.
lexxpavlov
01.06.2016 09:56-1В MySQL прекрасная phpMyAdmin, а в PostgreSQL phpPgAdmin — УГ. Предлагается использовать pgAdmin, но это разные вещи.
Может, phpPgAdmin улучшилась в последнее время, но с год назад пользоваться им былоневозможносложно.Shannon
04.06.2016 06:18Используйте https://www.adminer.org/ (один файл, легковестный, во многом удобнее)
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой
ILaeeeee
01.06.2016 11:06Работал с PostgreSQL — очень много чего понравилось, особено ресурсивные запросы (для типа хлебных крошек использовал). Но было и много боли. В частности большую боль мне доставляла перенос баз.
В MySql через тот же phpmyadmin можно быстро экспортнуть и импортнуть базу, в два клика. В postres (было давно могу чего то напутать), там какие то штуки с пользователями и ролями серьезные, потом через командную строку через pg экпортируешь и импортируешь.
Расскажите, кто работает с postres, как быстро и просто переносить БД и синхронизировать, в два клика. Какие пути есть.
Borz
01.06.2016 11:11https://habrahabr.ru/post/222311/
vadv
01.06.2016 12:05человек спрашивал про интерфейс жмяк-жмяк, а вы его в другие дебри заташили :)
смысл в том, что то, о чем просит человек — теоритическая не решаемая задача (нужно снять логический дамп с --no-owner, восстанавливать логический дамп под owner'ом базы, но есть проблемы с extensions)
Jedi_PHP
01.06.2016 11:42+1На постгри плотно сижу уже несколько лет, еще с 9.2. То, что появляется в новых версиях — просто не оставляет другим SQL-базам шансов, например JSON(B) / индексы по нему. Для очередного немаленького каталога, где у множества категорий товаров множество параметров (типа веса, размеров, цвета, диагонали, типа матрицы итп) можно просто использовать для хранения всего этого зоопарка JSONB в поле — вместо кучи костылей и велосипедов.
Для поиска по параметрам создаются индексы типа таких:
CREATE INDEX goods_width_size_index ON public.goods USING btree ((json ->> 'width'::text) COLLATE pg_catalog."default");
и всё, параметры (например цвет, ширину) можно смело использовать прямо в запросе:
SELECT id, title as name, json->'width' as width, json->'length' as length FROM goods WHERE category = '211' AND json @> '{"color": "red"}' AND -- нужен красный цвет, да (json->>'width')::int >= 1200; -- и широкий чтобы был!
Хоть и будет справедливо сказать, что я не пробовалOracleустриц, но подобного я больше нигде не видел.
nazartsev
Перейти на posstgresql достаточно быстро, но он заставляет писать правильный код.
Например запрос «select * from group by col1 order by col2 asc» скушается mysql, но postgres не сможет такое отработать. И если в проекте есть такие вещи они потребуют много рефакторинга.
varanio
Я не уверен, но мне кажется, что в strict mode MySQL такое тоже не должен проглатывать. Anyway, для нового проекта это несущественно, потому что выявится во время написания кода
un1t
А что с этой конструкцией не так?
ping
Все поля, которые выбираются, должны присутствовать в group by секции.
Для запроса «select f1, f2 from t group by f1» будет так: Postgre ругнётся, а MySQL сгруппирует по f1, и для f2 вернёт первое значение. Поскольку порядок возвращаемых строк неопределён и зависит от стратегии выборки, то может получиться что значение f2 будет разным при разных вызовах, что не очень-то и хорошо.