История изменений
Исправление slamd64, (текущая версия) :
С моей точки зрения DevOps'а, мускуль предпочтительнее.
Оно и проще, и идиоты-разработчики больше опыта с ним имеют (а потому более вменяемы).
В постгресе что мне ну просто дичайше не нравится - необходимость прописывать разрешения на сетевые подключения к базе во внешнем текстовом конфиге - и, соответственно, рестартовать постгрес - а ведь к одному серверу далеко не один проект подключен и на время рестарта всё это недоступно.
В то время, как в мускле достаточно соответствующий GRANT написать и, максимум, добавить flush privileges. Без рестарта мускля.
Что касается размера бинарников, то подозреваю, что попросту в мускуль много чего статикой линкуют. Учитывая общую политику виртуализации «один сервис - одна виртуальная машина» и политику innodb направленную на максимальное использование доступной оперативной памяти - это разумно. Дольше загружается, но зато после этого дисковые операции только на работу с БД.
Исходная версия slamd64, :
С моей точки зрения DevOps'а, мускуль предпочтительнее.
Оно и проще, и идиоты-разработчики больше опыта с ним имеют (а потому более вменяемы).
В постгресе что мне ну просто дичайше не нравится - необходимость прописывать разрешения на сетевые подключения к базе во внешнем текстовом конфиге - и, соответственно, рестартовать постгрес.
В то время, как в мускле достаточно соответствующий GRANT написать и, максимум, добавить flush privileges. Без рестарта мускля.
Что касается размера бинарников, то подозреваю, что попросту в мускуль много чего статикой линкуют. Учитывая общую политику виртуализации «один сервис - одна виртуальная машина» и политику innodb направленную на максимальное использование доступной оперативной памяти - это разумно. Дольше загружается, но зато после этого дисковые операции только на работу с БД.