Базы данных / Производительность Databases / Performance
На этой неделе прочитал интереснейшую статью от инженеров Uber: Why Uber Engineering Switched from Postgres to MySQL. Ayende, чуть позже, написал неплохие комментарии по этой теме.
TL;DR Можете использовать любую СУБД, только знайте её сильные и слабые стороны. А если выбор будет неправильным — можно будет мигрировать на другую (с разным количеством боли, в зависимости от ситуации). Postgres хорош в чтении, но проигрывает в записи. MySQL хорош в записи, но (хотя в статьях об этом не говорится — это уже мой личный опыт) оптимизатора запросов у него просто нет.
Да, раз уж я говорю про личный опыт — MSSQL сделает по производительности и то и другое :) Disclaimer: я не работал активно с Postgres, с MySQL — немного.
Uber в 2013 опубликовал статью про переход с MySQL на Postgres. Основная причина перехода, насколько я понял — в Postgres больше функциональности и “плагинов” вроде PostGIS.
Исходная статья реально интересная, авторы достаточно подробно описали концептуальные проблемы, которыми их встретил Postgres.
Самым шокирующим для меня стало то, что каждое соединение с базой обрабатывается в отдельном процессе. Серьёзно? Пул потоков разве сложно было сделать?
Довольно противоречивая проблема с репликацией. С одной стороны, я согласен, что концептуально могут быть проблемы с трансляцией записей на диск на низком уровне. С другой стороны — занимаешься репликацией — будь готов к проблемам в любом случае. А вот проблемы с совместимостью даже минорных версий серверов при репликации — это печаль. Хотя вроде ситуация исправляется.
Однако самая интересная штука — это устройство индексов. В MSSQL и MySQL вторичные индексы ссылаются на первичный ключ. При обновлении, которое не затрагивает индекс, никаких дополнительных телодвижений не совершается.
В Postgres строки неизменяемые, а индексы хранят ссылки на конкретное место на диске. При чтении это даёт выигрыш. Однако, при обновлении Postgres вынужден создавать копию строки с новыми значениями и обновлять все индексы обновляемой таблицы. “Старая” строка при этом продолжает занимать место, что уже менее критично (освобождается авто-вакуумом).
Как я уже говорил — используйте любую СУБД, только знайте её сильные и слабые стороны. Зная это, вы сами решите, стоит ли использовать, например, Postgres для проекта с высокой нагрузкой на запись и множеством серверов, на которые реплицируются данные.
Базы данных / Производительность Databases / Performance