Комментарии 76
Перейти на posstgresql достаточно быстро, но он заставляет писать правильный код.
Например запрос «select * from group by col1 order by col2 asc» скушается mysql, но postgres не сможет такое отработать. И если в проекте есть такие вещи они потребуют много рефакторинга.
Например запрос «select * from group by col1 order by col2 asc» скушается mysql, но postgres не сможет такое отработать. И если в проекте есть такие вещи они потребуют много рефакторинга.
Я не уверен, но мне кажется, что в strict mode MySQL такое тоже не должен проглатывать. Anyway, для нового проекта это несущественно, потому что выявится во время написания кода
А что с этой конструкцией не так?
Все поля, которые выбираются, должны присутствовать в group by секции.
Для запроса «select f1, f2 from t group by f1» будет так: Postgre ругнётся, а MySQL сгруппирует по f1, и для f2 вернёт первое значение. Поскольку порядок возвращаемых строк неопределён и зависит от стратегии выборки, то может получиться что значение f2 будет разным при разных вызовах, что не очень-то и хорошо.
Для запроса «select f1, f2 from t group by f1» будет так: Postgre ругнётся, а MySQL сгруппирует по f1, и для f2 вернёт первое значение. Поскольку порядок возвращаемых строк неопределён и зависит от стратегии выборки, то может получиться что значение f2 будет разным при разных вызовах, что не очень-то и хорошо.
НЛО прилетело и опубликовало эту надпись здесь
Ну как-то уж слишком категорично.
Я когда-то хорошо знал turbo pascal, мне надо было на нем остановиться навсегда?
Я когда-то хорошо знал turbo pascal, мне надо было на нем остановиться навсегда?
НЛО прилетело и опубликовало эту надпись здесь
Дело в том, что мускуль и пг делают — для старта проекта — абсолютно то же самое. Разница крайне незначительна. Но специалиста найти на мускуль проще.
В случае с паскалем, все будет не так. То, на чем сейчас приходится писать, от паскаля отличается как небо от земли. И паскаль неконкурентен по сравнению с актуальными языками, и специалистов по нему мало, то есть — явный аутсайдер = хорошо, что не стали останавливаться.
Я использовал PG в паре проектов, потом вернулся к мускулю, потому что команда на новый прожект уж совсем его не захотела. То есть, можно и то, и то. Но вот смысла — не вижу. Оборачиваясь назад, те проекты, которые были сделаны на PG, абсолютно так же отработали бы и на мускуле. Только головняка в процессе было бы меньше.
В случае с паскалем, все будет не так. То, на чем сейчас приходится писать, от паскаля отличается как небо от земли. И паскаль неконкурентен по сравнению с актуальными языками, и специалистов по нему мало, то есть — явный аутсайдер = хорошо, что не стали останавливаться.
Я использовал PG в паре проектов, потом вернулся к мускулю, потому что команда на новый прожект уж совсем его не захотела. То есть, можно и то, и то. Но вот смысла — не вижу. Оборачиваясь назад, те проекты, которые были сделаны на PG, абсолютно так же отработали бы и на мускуле. Только головняка в процессе было бы меньше.
Наверное я не оригинален с этой идеей, но всё же — почему бы авторам Postgres не прикрутить «препроцессор» запросов, эдакий «Mysql mode», который все эти BIGINT AUTOINCREMENT будет переводить в знакомый ему bigserial и отдавать на выполнение. Чтобы с мускула на постгрю можно было переключиться простой сменой URN-подключения в конфиге?
Ведь если разница не такая масштабная, как вы утверждаете, то реализовать это будет просто. Но при этом, я думаю, было бы логично, если бы всю эту мелкую дурную работу за человека делала бы машина, а человек уже мог бы, перейдя на Postgres и оценив все его преимущества, уже писал бы новые запросы в postgres-стиле.
Подобный инструмент точно бы помог популяризации постгри в интернетах.
Ведь если разница не такая масштабная, как вы утверждаете, то реализовать это будет просто. Но при этом, я думаю, было бы логично, если бы всю эту мелкую дурную работу за человека делала бы машина, а человек уже мог бы, перейдя на Postgres и оценив все его преимущества, уже писал бы новые запросы в postgres-стиле.
Подобный инструмент точно бы помог популяризации постгри в интернетах.
Ну а как быть с кавычками и т.д.? Есть куча написанного кода, например расширений postgres и т.д., которые не поймут мускульный синтаксис кавычек например. Т.е. они все не будут работать. А смысл тогда? Или перерабатывать вообще всё на свете? Это слишком масштабная переработка. Думаю, посгресовое сообщество не заинтересовано в этом.
Такое уже давно есть. ORM называется.
Да, strict mode «по умолчанию» в mysql — это реальный способ побить конкурентов.
Действительно, БД развивается немыслимыми темпами.
Что и говорить.
Действительно, БД развивается немыслимыми темпами.
Что и говорить.
Просто без strict mode там был просто нечеловеческий адъ. Сейчас хотя бы стало похоже на базу. Собственно, тут важнее сам симптом, что mysql наконец-то начал потихоньку двигаться в нужном направлении. Оракл делает хорошее дело.
Можно ли назвать изменение одной строки в дефолт конфиге развитием?
Им потребовались годы, чтобы сделать это.
Им потребовались годы, чтобы сделать это.
Когда Oracle купил mysql, то по сути почти сразу же и сделал. А вот до этого — да, годами допиливали какое-то непойми что.
Ага. Только вот админам, привыкшим что 5.5 от 5.4 (условно говоря) не сильно отличается — этот strict mode кровушки попил. Когда ты не можешь понять почему не работает то, что годами ранее всегда работало. И как это победить. И вместо быстрой-легкой установки чего-то приходится въезжать в дебри того «как правильно делать вот это».
Слоник радует нас обилием всякого разного, с чем разбираться по факту должен БД-администратор, которого лично у нас нет. А значит надо или нанимать или учить.
Если учить, то про MySQL куча понятных книжек, в том числе и на русском. Плюс инструменты. Плюс даже настройки по-умолчанию в половине случаев прокатывают. Ну и не забываем про то что 5.0 и 5.5 это две большие разницы.
Вот и получается что массовой миграции не предвидеться. Такие дела.
Если учить, то про MySQL куча понятных книжек, в том числе и на русском. Плюс инструменты. Плюс даже настройки по-умолчанию в половине случаев прокатывают. Ну и не забываем про то что 5.0 и 5.5 это две большие разницы.
Вот и получается что массовой миграции не предвидеться. Такие дела.
Пару месяцев назад перенесли не самый маленький сайт с mysql на postgres. За счёт того, что сайт был на symfony/doctrine переезд был практически безболезненный, и занял около трёх дней, которые ушли в основном на переписывание запросов с группировкой.
Из плюсов такого перехода:
— Выросла скорость не некоторых сложных запросах в разы, в среднем запросы отрабатывают на 20-30 процентов быстрее
— За счёт более строгой валидации данных выловили несколько ошибок, когда данные не умещались в колонку
— Написание миграций стало нормальной работой за счёт транзакционности alter table
Из минусов:
— Иногда возникают неприятные баги из-за строгой валидации (например после перехода бывали падения на неверных utf-8 последовательнотей в user-agent, который пишется в базу)
— В целом качество поддержки софтом чуть ниже, чем для mysql (некритичные проблемы с doctrine / doctrine-migrations)
Из плюсов такого перехода:
— Выросла скорость не некоторых сложных запросах в разы, в среднем запросы отрабатывают на 20-30 процентов быстрее
— За счёт более строгой валидации данных выловили несколько ошибок, когда данные не умещались в колонку
— Написание миграций стало нормальной работой за счёт транзакционности alter table
Из минусов:
— Иногда возникают неприятные баги из-за строгой валидации (например после перехода бывали падения на неверных utf-8 последовательнотей в user-agent, который пишется в базу)
— В целом качество поддержки софтом чуть ниже, чем для mysql (некритичные проблемы с doctrine / doctrine-migrations)
Ананлогично, в новом довольно большом проекте решили использовать postgres, до этого был опыт только с mysql. Используя doctrine 2.5, на данный момент разницы почти никакой не заметили. С doctrine/migrations проблем пока ещё не было.
Пока проект в глубокой альфе, субд не тюнили, просто установили с стандартными настройками и используем. На очень простых выборках — mysql на 20-30% быстрее, более сложные — лидирует postges.
Пока проект в глубокой альфе, субд не тюнили, просто установили с стандартными настройками и используем. На очень простых выборках — mysql на 20-30% быстрее, более сложные — лидирует postges.
Основная проблема с миграциями — при добавлении к таблице новой колонки NOT NULL приходится переписывать сгенерированный запрос на два запроса вида ALTER xxx DEFAULT 0, ALTER xxx SET NOT NULL. Также в down постоянно попадает строчка создания схемы. В остальном всё работает хорошо.
Дефолтные настройки пг совсем убогие. Он видимо рассчитан на то, чтобы запускаться даже на утюге. Прогоните хотя бы автоматическими штуками как pgtune. Это конечно тоже совсем не айс, но хоть что-то, лучше чем полный… дефолт
Проблема постгреса не в её «сложности», а в не удобности. На стандартных SQL запросах разницы нет никакой, однако на чуть более сложных запросах сразу же начинают себя проявлять «особенности» постгреса.
Например, пресловутая ON CONFLICT появилась в только в версии 9.5 (sic!), до этого гуру постгреса искренне верили, что если можно решить задачу хранимочкой на пол страницы, то и так сойдёт. Однако, даже в итоге утверждённый вариант, в попытке сделать универсальное решение на все случаи жизни, получился более многословным и неудобным из-за необходимости явно указывать обязательным параметром имя поля, по сравнению с тем же мускулом, который уже много лет умеет это делать автоматически.
Или например функция lastval() по прихоти разработчиков, вместо того чтобы тихо вернуть null, если в таблице нет автоинкрементного ключа, зачем-то откатывает всю транзакцию, делая невозможным её использование в простых ORM, а в других случаях эта функция по сути и не нужна.
И такие грабли заботливо разложены в постгресе на каждом шагу. Поэтому нет ничего удивительного в том, что разработчики из небольших проектов, которым никто не переплачивает за страдания и боль, в угоду мифической производительности и масштабируемости, которая может понадобится, а может и не понадобится, не горят желанием её использовать.
Например, пресловутая ON CONFLICT появилась в только в версии 9.5 (sic!), до этого гуру постгреса искренне верили, что если можно решить задачу хранимочкой на пол страницы, то и так сойдёт. Однако, даже в итоге утверждённый вариант, в попытке сделать универсальное решение на все случаи жизни, получился более многословным и неудобным из-за необходимости явно указывать обязательным параметром имя поля, по сравнению с тем же мускулом, который уже много лет умеет это делать автоматически.
Или например функция lastval() по прихоти разработчиков, вместо того чтобы тихо вернуть null, если в таблице нет автоинкрементного ключа, зачем-то откатывает всю транзакцию, делая невозможным её использование в простых ORM, а в других случаях эта функция по сути и не нужна.
И такие грабли заботливо разложены в постгресе на каждом шагу. Поэтому нет ничего удивительного в том, что разработчики из небольших проектов, которым никто не переплачивает за страдания и боль, в угоду мифической производительности и масштабируемости, которая может понадобится, а может и не понадобится, не горят желанием её использовать.
Да ладно на пол-страницы, двумя запросами подряд всё решается на самом деле.
Не, ну меня тоже бесило отсутствие insert ignore
Конечно это не просто два запроса подряд, но и не хранимочка на страницу, это даже не хранимочка а подобие лямбды. По мне так вполне достойная замена ON CONFLICT пока она еще не появилась:
DO $pgfunc$
BEGIN
BEGIN
INSERT INTO ...;
EXCEPTION WHEN unique_violation THEN
UPDATE ...;
END;
END
$pgfunc$
DO $pgfunc$
BEGIN
BEGIN
INSERT INTO ...;
EXCEPTION WHEN unique_violation THEN
UPDATE ...;
END;
END
$pgfunc$
Да не то чтобы бесило, даже не напрягало, но дискомфорт в седалищной области вызывало, да.
> которая может понадобится, а может и не понадобится
В том-то и дело, что пока не попробуешь — не поймешь.
Я вот например без CTE и без нормальной работы сложных запросов уже просто как без рук.
К примеру, мы изредка начисляем компенсации пользователям в зависимости от всяких там средних трат за неделю и фазы луны. Раньше, на mysql частенько приходилось делать промежуточные временные таблицы. В пг — просто пишешь километровый запрос на CTE
В том-то и дело, что пока не попробуешь — не поймешь.
Я вот например без CTE и без нормальной работы сложных запросов уже просто как без рук.
К примеру, мы изредка начисляем компенсации пользователям в зависимости от всяких там средних трат за неделю и фазы луны. Раньше, на mysql частенько приходилось делать промежуточные временные таблицы. В пг — просто пишешь километровый запрос на CTE
Или например функция lastval() по прихоти разработчиков, вместо того чтобы тихо вернуть null, если в таблице нет автоинкрементного ключа
Действительно, к чему лишний шум? Об ошибках надо молчать.
Действительно, к чему лишний шум? Об ошибках надо молчать.
В том то и проблема, что со стороны админа базы ОЧЕНЬ сильно различаются. Например лично я раза три пытался начать развертывать очередное предложение на Postgres вместо Mysql. И все три раза сдавался. Потому что слишком замороченно и сложно. Куча разных несистематизировнных утилит. Большое количество конфигурационных файлов где что-то нужно прописывать.
В то же время мускулом можно начать пользоваться уже сразу после yum install mysql-server; service mysqld start.
И разница тем более заметна, чем менее искушен программист в системном администрировании. Некоторые то и так просят создать им базу, или ребутнуть мускуль.
А так да… в очередной раз подумал — может попробовать въехать в Постгрес опять? А потом — да ну его нафиг…
В то же время мускулом можно начать пользоваться уже сразу после yum install mysql-server; service mysqld start.
И разница тем более заметна, чем менее искушен программист в системном администрировании. Некоторые то и так просят создать им базу, или ребутнуть мускуль.
А так да… в очередной раз подумал — может попробовать въехать в Постгрес опять? А потом — да ну его нафиг…
в плане администрирования сложнее. Но, честно говоря, не пойму про какие файлы настроек вы говорите. Знаю postgresql.conf, pg_hba.conf. Настройки этих двух файлов хватит чтобы начать работать. Кстати по поводу последнего, он дает очень гибкую возможность настройки прав доступа. В мускуле очень этого не хватало. возможность ограничить подсеть по CIDR это просто сказка. Не говоря о других вичах этого файла.
Я уже не помню, честно говоря, об какие грабли спотнулся в крайний раз. Было это дело более года назад.
Очень не хватает краткой шпаргалочки вида: вы привыкли это делать в мускуле вот так — а вот в постргесе вот такие команды.
На первых порах, чтобы просто запустить этого монстра — хватит.
Очень не хватает краткой шпаргалочки вида: вы привыкли это делать в мускуле вот так — а вот в постргесе вот такие команды.
На первых порах, чтобы просто запустить этого монстра — хватит.
к сожалению вы выбрали дистрибутив, который требует участия администратора в инициализации кластера: https://wiki.postgresql.org/wiki/YUM_Installation
на debian-like после инсталяции будет запущен работоспособный инстанс (хотя и не утверждаю что это правильнее)
Ну и это разве нормально? Я понимаю что это в целом не проблема СУБД как таковой. Что кто-то с мейнтейнеров схалявил, а мог бы написать нормальный конфигуратор для пакета. Но тем не менее, простому программеру или админу от этого не легче. Сервер уже есть, дистрибутив уже выбран. А вот… увы…
Ну и это разве нормально?
кластер например можно инициализировать (а потом это нельзя уже изменить) как с cheksums так и без, конечно у человека должен быть выбор
А переинициализировать нельзя? Ну в таком случае всё ясно.
Но опять таки… сравнивая мускуль и постгрес — один просто поставил и уже используешь. Не задумываясь ни о каких понятиях типа кластера, как его там инициализировать и так далее. А в другой сначала придется въехать, потом использовать.
Не то чтобы сложно… просто когда это не твоя основная задача на текущий момент — очень не хочется отвлекаться.
Но опять таки… сравнивая мускуль и постгрес — один просто поставил и уже используешь. Не задумываясь ни о каких понятиях типа кластера, как его там инициализировать и так далее. А в другой сначала придется въехать, потом использовать.
Не то чтобы сложно… просто когда это не твоя основная задача на текущий момент — очень не хочется отвлекаться.
Насчёт последнего — можно ли создать пользователя, который сможет подключиться к базе без её перезагрузки?
В доках же:
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.
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.
То есть нельзя просто средствами SQL создать пользователя и дать ему доступ.
HBA — это host-based authentication. До есть контроль доступа на уровне файлов (а в UNIX все — файлы).
Если в нем будет разрешено всем все, то да — можно средствами только SQL создать пользователя, доступ у него уже будет.
HBA тут просто как еще один уровень безопасности. В частности с помощью этого механизма пользователь, под которым запущен постгрес на локальной машине с этой же локальной машины может подключаться без ввода пароля через файловый сокет по-умолчанию (во всяком случае, на Debian)
Если в нем будет разрешено всем все, то да — можно средствами только SQL создать пользователя, доступ у него уже будет.
HBA тут просто как еще один уровень безопасности. В частности с помощью этого механизма пользователь, под которым запущен постгрес на локальной машине с этой же локальной машины может подключаться без ввода пароля через файловый сокет по-умолчанию (во всяком случае, на Debian)
В MySQL это регулируется на уровне базы. Пользователю может быть разрешено логиниться с любой машины удаленно, с определенного хоста (IP или reverse DNS) или локально через сокет, как с паролем, так и без. И всё это только через SQL. В PostgreSQL система безопасности более строгая и гибкая, но всеми её возможностями можно пользоваться только имея доступ к файловой системе и процессам, как правило это рут-доступ.
В 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 тоже что-то для этого есть.
Для себя решил, что 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 тоже что-то для этого есть.
service reload <name>
А меж тем разработчику зачастую уметь создать базу, дать к ней доступ пользователю с паролем, и запустить SQL-консоль с коннектом к этой базе нужно уметь так же часто как и собственно SQL-запросы. Аналогично починить базу, удалить, сделать дамп. Залить из дампа.
Плюс пресловутый тюнинг под производительность. Мускуль на ненагруженных проектах даже из коробки работает неплохо. А как тюнить постгрес — это надо еще въехать.
В итоге в очередной раз разворачивая какое-нибудь приложение из двух движков по привычке выбираешь Мускуль. За простоту и понятность.
Плюс пресловутый тюнинг под производительность. Мускуль на ненагруженных проектах даже из коробки работает неплохо. А как тюнить постгрес — это надо еще въехать.
В итоге в очередной раз разворачивая какое-нибудь приложение из двух движков по привычке выбираешь Мускуль. За простоту и понятность.
> Если меня читают 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 сильно зависят от того, как и на каком оборудовании будет использоваться СУБД.
Могу попробовать написать. Но что кроме
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 сильно зависят от того, как и на каком оборудовании будет использоваться СУБД.
ну вот человек выше пишет
Т.е. по идее надо какие-то простые вещи, которые у вас может быть и вопросов то не вызывали никогда, но у разработчика будет ступор. По верхам хотя бы.
— как установить
— как прописать в hba что нужно
— как запускать / останвливать
— как создать новую базу
— основные моменты в тюнинге, размер shared_buffers и проч
— как создать роль, чтобы с нее можно было залогиниться
— создать дамп / восстановить из дампа
— фиг знает, что там еще, настроить бекапы? репликацию?
А меж тем разработчику зачастую уметь создать базу, дать к ней доступ пользователю с паролем, и запустить SQL-консоль с коннектом к этой базе нужно уметь так же часто как и собственно SQL-запросы. Аналогично починить базу, удалить, сделать дамп. Залить из дампа.
Плюс пресловутый тюнинг под производительность. Мускуль на ненагруженных проектах даже из коробки работает неплохо. А как тюнить постгрес — это надо еще въехать.
Т.е. по идее надо какие-то простые вещи, которые у вас может быть и вопросов то не вызывали никогда, но у разработчика будет ступор. По верхам хотя бы.
— как установить
— как прописать в hba что нужно
— как запускать / останвливать
— как создать новую базу
— основные моменты в тюнинге, размер shared_buffers и проч
— как создать роль, чтобы с нее можно было залогиниться
— создать дамп / восстановить из дампа
— фиг знает, что там еще, настроить бекапы? репликацию?
1) Установка (включая создание базы, юзеров, итп) описывается в любом туториале и делается в 3 строчки
2) Всё после apt-get install можно сделать из графического интерфейса pgAdmin, в котором чтобы непонять где находится запуск SQL-консоли и снятие бэкапа — нужно от души постараться. Если вдруг корпоративный стандарт — это Навикат, то там всё едва ли не еще проще
3) А вы думаете, что люди, которые не могут загнать в гугл поисковый запрос «postgresql tuning guide», хорошо разбираются в тюнинге MySQL?
Вот я вижу фразу, «Мускуль на ненагруженных проектах даже из коробки работает неплохо.»
На основании чего был сделан вывод, что Слоник «на ненагруженных проектах» работает плохо, и его надо тюнить?
Зачем вообще тюнить ненагруженный проект? Т.е. понятно, что стартовые настройки не идеальные, но как это можно понять без нагруженного проекта или нагрузочных тестов?
Поднимите руку, кто считает стартовые настройки MySQL идеальными :))
2) Всё после apt-get install можно сделать из графического интерфейса pgAdmin, в котором чтобы непонять где находится запуск SQL-консоли и снятие бэкапа — нужно от души постараться. Если вдруг корпоративный стандарт — это Навикат, то там всё едва ли не еще проще
3) А вы думаете, что люди, которые не могут загнать в гугл поисковый запрос «postgresql tuning guide», хорошо разбираются в тюнинге MySQL?
Вот я вижу фразу, «Мускуль на ненагруженных проектах даже из коробки работает неплохо.»
На основании чего был сделан вывод, что Слоник «на ненагруженных проектах» работает плохо, и его надо тюнить?
Зачем вообще тюнить ненагруженный проект? Т.е. понятно, что стартовые настройки не идеальные, но как это можно понять без нагруженного проекта или нагрузочных тестов?
Поднимите руку, кто считает стартовые настройки MySQL идеальными :))
1) Если не сложно — приведите эти три строчки здесь. Будет мне подспорье. Или ссылки на понятные мануалы, в которых авторы не растекаются мыслью по древу, но и не «рисуют сову». Мне такие пока не попадались.
Вот в мускуле реально три строчки:
# mysql -uroot -p
# CREATE DATABASE 'db_name';
# GRANT ALL PRIVILEGES ON db_name.* TO db_username IDENTIFIED BY 'db_password';
Ни одного файла редактировать не надо. И лишь одна консольная утилита.
2) ОК. Но зачем эти сложности? Если на сервере не предусмотрен даже веб-сервер, например? Это отвлекаться, настраивать. Понимаю что сейчас это проще простого. Но все же… не всегда всё заводится из коробки, как того хочется. В итоге хотел развернуть к примеру Nagios, а обнаружил себя в три часа ночи, собирающим из исходников особенную версию php :) Ну это я так… к примеру.
3) Сколько я проектов повидал, в которых конфиг мускула практически пустой. И оно как-то работало. Пока к ним не пришла популярность :) В том то и дело. Что, чтобы тюнить мускуль зачастую хватает квалификации даже менеджера веб-магазина. Скопировать конфиг из мануала и вставить в файл. В постгресе такое возможно? Будет позитивный эффект? Везде написано: никогда не используйте его в дефолтной конфигурации. Всегда делайте тюнинг под ваш проект. Только нафиг простому программисту в этом разбираться?
Может быть в мире «большой и грамотной» разработки и есть какие-то ДБА. А в том мире где к примеру живу я (и еще многие) есть только веб-программист, и хорошо если еще полуграмотный линукс-админ, который и мускул то не может настроить. А то зачастую есть только директор и программист.
ЗЫ я не считаю настройи мускуля идеальными. и не считаю мускуль идеальным. Но все же продукт в целом выглядит более простым и логичным, чем постгрес. И осваивается легче и быстрее.
Вот в мускуле реально три строчки:
# mysql -uroot -p
# CREATE DATABASE 'db_name';
# GRANT ALL PRIVILEGES ON db_name.* TO db_username IDENTIFIED BY 'db_password';
Ни одного файла редактировать не надо. И лишь одна консольная утилита.
2) ОК. Но зачем эти сложности? Если на сервере не предусмотрен даже веб-сервер, например? Это отвлекаться, настраивать. Понимаю что сейчас это проще простого. Но все же… не всегда всё заводится из коробки, как того хочется. В итоге хотел развернуть к примеру Nagios, а обнаружил себя в три часа ночи, собирающим из исходников особенную версию php :) Ну это я так… к примеру.
3) Сколько я проектов повидал, в которых конфиг мускула практически пустой. И оно как-то работало. Пока к ним не пришла популярность :) В том то и дело. Что, чтобы тюнить мускуль зачастую хватает квалификации даже менеджера веб-магазина. Скопировать конфиг из мануала и вставить в файл. В постгресе такое возможно? Будет позитивный эффект? Везде написано: никогда не используйте его в дефолтной конфигурации. Всегда делайте тюнинг под ваш проект. Только нафиг простому программисту в этом разбираться?
Может быть в мире «большой и грамотной» разработки и есть какие-то ДБА. А в том мире где к примеру живу я (и еще многие) есть только веб-программист, и хорошо если еще полуграмотный линукс-админ, который и мускул то не может настроить. А то зачастую есть только директор и программист.
ЗЫ я не считаю настройи мускуля идеальными. и не считаю мускуль идеальным. Но все же продукт в целом выглядит более простым и логичным, чем постгрес. И осваивается легче и быстрее.
по первому пункту примерно так (могу ошибиться в деталях, так как не админ ни разу):
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 — всем юзерам.
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 — всем юзерам.
А почему под юзером postgres? Это типа местного root'а?
Как потом зайти в базу blabla от имени юзера db_user? Я имею в виду подключитсья через консоль?
Как потом зайти в базу blabla от имени юзера db_user? Я имею в виду подключитсья через консоль?
PostgreSQL может авторизовать пользователя не только по паролю, но и по факту того что процесс запущен от пользователя, который совпадает с пользователем базы: http://postgrespro.ru/doc/auth-methods.html#AUTH-IDENT.
SuperUser'ов (аналог root в mysql) в PostgreSQL может быть несколько, по умолчанию это postgres.
Под другим пользователем — psql -U otheruser, советую почитать: http://postgrespro.ru/doc/client-authentication.html
Всё после apt-get install можно сделать из графического интерфейса pgAdmin
Угу, вот только подключиться из pgAdmin к базе может быть не просто.
Интересно чем не просто, не сложнее чем из мускул воркбенч к мускулю.
pg_hba.conf редактировать, например.
ssh -L 5432:localhost:5432 database — спасет отца русской демократии, не?
Это графический интерфейс? )
Расскажите пожалуйста, что делает эта команда?
она позволяет больше не подключаться к удаленному серверу с базой данных. Вместо этого становится возможно подключаться к своему любимому компьютеру на порт 5432. А ssh за кулисами уже само перенаправит трафик на удаленный сервер. Это частично устраняет необходимость разбираться в настройках прав безопасности.
Несколько месяцев идёт вялотекущий процесс миграции с Мускуля (5.1 :) на Постгри. Из плюсов — в целом заметно шустрее, Doctrine справилась в целом хорошо (только миграции вечно глючат, тщательно надо проверять и в большинстве случаев править руками, есть мысли вообще отказаться от автоматической генерации уж больно опасные вещи может нагенирировать). Минусы — практически в обязательном порядке приходится перерабатывать логику (логику, а не синтаксис) сложных запросов с группировками, подзапросами, и, конечно, переменными. Причём встречаются ситуации, когда запрос, который Мускуль обрабатывает за пару минут, от Постгреса можно за пару часов не дождаться, даже построив функциональные и/или частичные индексы из-за которых казалось мускуль тормозит — механического подхода для трансляции недостаточно, совершенно другие подходы нужно применять. Сильное место оптимизатора Постгри — джойны по результатам подзапросов, на которых мускуль зависал (приходилось делать временные таблицы и индексировать их). Слабое, насколько я могу судить, конструкции типа (очень упрощенно) SELECT t1.id, (SELECT SUM(amount) FROM t2 WHERE t2.t1_id = t1.id ) FROM t1 — очень похоже, что в цикле внутренний запрос Постгри вызывает для каждой строки исходной таблицы, а Мускуль джойнит. Если в каждой таблице порядка миллиона записей…
Отдельная головная боль — администрирование. Особенно если пришла в голову гениальная идея повесить базы разных приложений на один сервер, а потом отреплицировать только одну из них. Да и просто пользователей добавлять. Понятно, что многое приходит с опытом, но если нюансы мускуля впитывал можно сказать десятилетия с ростом сложности задач, и уже интуитивно обходишь узкие места, то тут приходится в сжатые сроки набивать все шишки, разрываясь на части, поскольку всё взаимосвязано.
Отдельная головная боль — администрирование. Особенно если пришла в голову гениальная идея повесить базы разных приложений на один сервер, а потом отреплицировать только одну из них. Да и просто пользователей добавлять. Понятно, что многое приходит с опытом, но если нюансы мускуля впитывал можно сказать десятилетия с ростом сложности задач, и уже интуитивно обходишь узкие места, то тут приходится в сжатые сроки набивать все шишки, разрываясь на части, поскольку всё взаимосвязано.
Можете привести пример опасных вещей в миграции? Нами пока была замечена только некорректная генерация добавления колонок NOT NULL, но в остальном вроде всё в порядке. С чем еще можем столкнуться?
Неразбериха со схемами. Сама Doctrine нормально работает, но миграции бедную public как только не мурыжат. С дефолтными функциональными значениями проблемы были, с кастомными описаниями столбцов, с существующими индексами. Вообще сравнение схем для Postgre очень странно работает, особенно, если используется несколько схем и одна из них public. Она то явно указывается, то считается схемой по умолчанию и сравнение схем одну и ту же таблицу считает разными. А простого способа пофиксить нет — баг годы уже висит, несколько патчей было, но ломают что-то другое, и 100% работающего воркараунда нет. Да и без public бывает, что описываем столбец в маппинге, генерируется миграция ADD COLUMN <что-то>, а потом в каждой следующей миграции генерируется CHANGE column <это же что-то>, хотя маппинг не менялся, то есть Doctrine не понимает, что этот столбец в базе создала она и он не менялся, считает что вид у него неправильный и приводит к нему.
Согласен с автором статьи. Всю жизнь работал с mysql. Устроился на другую работу, и мне сказали, что тут только postgresql. Ок, погуглил как сделать auto_increment, 10 минут поразмышлял почему не работают `. Все, разработка идет с той же скоростью. Очень жаль, что я раньше не сделал этого.
В MySQL прекрасная phpMyAdmin, а в PostgreSQL phpPgAdmin — УГ. Предлагается использовать pgAdmin, но это разные вещи.
Может, phpPgAdmin улучшилась в последнее время, но с год назад пользоваться им былоневозможно сложно.
Может, phpPgAdmin улучшилась в последнее время, но с год назад пользоваться им было
php*admin — дыра в безопасности. Не вижу преимуществ перед десктопным ПО.
Используйте https://www.adminer.org/ (один файл, легковестный, во многом удобнее)
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой
Работал с PostgreSQL — очень много чего понравилось, особено ресурсивные запросы (для типа хлебных крошек использовал). Но было и много боли. В частности большую боль мне доставляла перенос баз.
В MySql через тот же phpmyadmin можно быстро экспортнуть и импортнуть базу, в два клика. В postres (было давно могу чего то напутать), там какие то штуки с пользователями и ролями серьезные, потом через командную строку через pg экпортируешь и импортируешь.
Расскажите, кто работает с postres, как быстро и просто переносить БД и синхронизировать, в два клика. Какие пути есть.
В MySql через тот же phpmyadmin можно быстро экспортнуть и импортнуть базу, в два клика. В postres (было давно могу чего то напутать), там какие то штуки с пользователями и ролями серьезные, потом через командную строку через pg экпортируешь и импортируешь.
Расскажите, кто работает с postres, как быстро и просто переносить БД и синхронизировать, в два клика. Какие пути есть.
https://habrahabr.ru/post/222311/
С кликами — это вероятно к DBeaver, хотя я не уверен.
Лично мне проще вызвать pg_dump, т.к. сам я консолью пользуюсь гораздо чаще, чем мышкой.
Лично мне проще вызвать pg_dump, т.к. сам я консолью пользуюсь гораздо чаще, чем мышкой.
На постгри плотно сижу уже несколько лет, еще с 9.2. То, что появляется в новых версиях — просто не оставляет другим SQL-базам шансов, например JSON(B) / индексы по нему. Для очередного немаленького каталога, где у множества категорий товаров множество параметров (типа веса, размеров, цвета, диагонали, типа матрицы итп) можно просто использовать для хранения всего этого зоопарка JSONB в поле — вместо кучи костылей и велосипедов.
Для поиска по параметрам создаются индексы типа таких:
и всё, параметры (например цвет, ширину) можно смело использовать прямо в запросе:
Хоть и будет справедливо сказать, что я не пробовалOracle устриц, но подобного я больше нигде не видел.
Для поиска по параметрам создаются индексы типа таких:
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; -- и широкий чтобы был!
Хоть и будет справедливо сказать, что я не пробовал
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
PostgreSQL — не Rocket Science. Почем сейчас яйца?