Продолжаем перевод статей о Postgres. Первую часть можно прочитать по ссылке. Комментарии по переводу приветствуются.
————————————————————
На прошлой неделе я опубликовал пост с перечнем множества причин в пользу использования Postgres. Я преследовал две цели:
— опровергнуть те исторические сложившиеся аргументы против Postgres, которые уже не имеют под собой оснований;
— осветить некоторые характерные особенности, редко обнаруживаемые в базах данных.
После публикации моего поста стало совершенно очевидно, что я упустил некоторые свойства, которые я считал само собой разумеющимися, на что неоднократно указывалось в комментариях и в hacker news. Вероятно причиной этому является то, что Postgres чрезвычайно хорош. Большое спасибо всем за то, что указали на это. Для того чтобы подтвердить свои слова, ниже привожу второй перечень причин в пользу использования Postgres:
Одновременное создание индекса
В более традиционных базах данных в процессе создания индекса таблица блокируется. А это означает, что на протяжении некоторого времени таблица становится практически бесполезна. В начале процесса это еще не является проблемой, но с увеличением количества данных для повышения производительности вы вынуждены добавлять индексы позже, что означает потерю времени на добавление индекса. Неудивительно, что Postgres позволяет добавлять индекс без блокировки таблицы. Просто введите «CREATE INDEX CONCURRENTLY» вместо «CREATE INDEX», и это позволит вам создать индекс без блокировки.
Разумеется, в отношении многих свойств существуют оговорки. В случае одновременного создания индекса, процесс займет на 2-3 минуты дольше, а также эта функция не может быть использована в пределах транзакции.
Транзакционный DDL
Если когда-либо у вас случались сбои в середине запуска миграции из-за ограничения или по какой-либо другой причине, то вы знаете, сколько сил нужно приложить для того, чтобы восстановить все. Как правило, подразумевается, что миграции в схему запускаются целостно, и в случае сбоя необходимо начинать все сначала. Некоторые другие базы данных вроде последней версии Oracle и SQL server поддерживают данную функцию. И, конечно же, Postgres поддерживает функцию включения DDL в транзакцию. Это значит, что в случае возникновения ошибки, вы можете просто вернуться, тем самым отменив предыдущее DDL-предложение, и при этом оставив миграцию и данные в безопасности, а ваше приложение в согласованном состоянии.
Обработчик внешних данных
Ранее я уже говорил об использовании в вашей базе данных других языков, таких как Ruby или Python, но что если вы хотите установить соединение с другими базами данных прямо из своей базы данных? В Postgres обработчик внешних данных позволяет вам извлекать внешние системы данных и использовать их с сохранением той структуры, с которой они хранились в исходной базе данных. Ниже приведена выборка лишь некоторых существующих обработчиков внешних данных:
На самом деле вы можете использовать даже Multicorn для того, чтобы писать другие обработчики внешних данных на Python. Пример того, как это можно сделать в данном случае с Database.com/Force.com вы найдете здесь.
Условные ограничения и частичные индексы
Аналогично тому, как вы воздействуете только на часть данных, вы можете создать индекс только для некоторой части данных. Или вы можете ввести ограничение только в тех случаях, когда верным является некоторое условие. Возьмем, к примеру, адресный справочник. В адресном справочнике имеется только один активный адрес, но за некоторое время у вас появилось несколько адресов. Вряд ли вам необходимо, чтобы индексировались какие-либо старые адреса, скорее вы захотите, чтобы индексировались текущие адреса. Очень просто сделать это при помощи функции частичных индексов:
CREATE INDEX idx_address_current ON address (user_id) WHERE current
Postgres в облаке
Некоторые отдельные сервисы выбрали для пользования Postgres, и его качество было доказано такими сервисами как Instagarm и Disqus. Возможно, даже более важным является то, что благодаря большому количеству облаков, для которых Postgres является сервисом, это во многом упрощает его использование:
Heroku Postgres
VMware vFabric
Enterprise DB
Cloud Postgres
Скажу более: я работал на Heroku, и также являюсь большим поклонником их сервиса базы данных.
Команды LISTEN / NOTIFY
Если вы хотите использовать свою базу данных как очередь, то это будет возможно не во всех случаях, как уже обсуждалось в одном из недавних обзоров. Однако большинство из сказанного можно опровергнуть, благодаря командам Listen/Notify. Postgres позволяет вам прослушать (LISTEN) уведомление и, конечно, известит (NOTIFY) о том, когда оно произошло. Отличным примером этого является Queue Classic Райана Смита (Ryan Smith’).
Быстрое добавление / удаление колонки
Вы хотите добавить или удалить колонку. При наличии миллионов записей в некоторых базах данных это займет секунды или даже минуты, и я слышал пару страшных историй о том, как процесс добавления колонки занимал часы. Но при работе в Postgres это становится секундным делом. Единственное, когда это может занять у вас чуть больше времени, это при вводе стандартных данных в новую колонку.
Наследование таблицы
Хотите, чтобы в вашей базе данных была функция наследования, точно так же как в модели прикладного кода? Для Postgres это не проблема. Вы с легкостью можете наследовать одну таблицу в другую, оставив в базе данных более упорядоченную ее модель, но при этом сохранив необходимую гибкость этой модели. Документация Postgres по DDL наследованию наилучшим образом объясняет, как можно использовать эту функцию, приводя очень простые и понятные примеры.
Синхронная репликация через транзакцию
В стандартном режиме Postgres потоковая репликация является асинхронной. Она отлично работает, когда вы хотите повысить производительность, а также контролировать сохранность данных. Но существуют и случаи, когда вам необходима синхронная репликация. Более того асинхронная репликация может работать достаточно хорошо в тех случаях, когда вы хотите использовать синхронную репликацию для работы с данными с той же базе данных. Например, если регистрация и покупки пользователя для вас более важны, чем рейтинг продукции и комментарии, то Postgres предоставит вам возможность управлять ими таким образом. В Postgres вы можете проводить в одной транзакции синхронную репликацию, что дает строгую гарантию данным о пользователе и его транзакции платежа, и меньшую гарантию всему остальному. Это значит, что вы сможете направить чуть больше производительности на то, что действительно важно для вас в противопоставление принципу «все или ничего», имеющего место быть при работе в других базах данных.
Заключение
Надеюсь, что вы убедились в том, что Postgres является отличным инструментом, а в случае, если нет, обратитесь к моему предыдущему посту.
Добавить комментарий