Что дает лучшую производительность для работы PostgreSQL на EC2? EBS в RAID? PGData на / мнт?
Есть ли у вас какие-либо предпочтения или опыт? Главный «плюс» запуска PostgreSQL на EBS - переключение с одного экземпляра на другой. Может ли это быть причиной более медленной работы, чем использование раздела / mnt?
PS: Я использую PostgreSQL 8.4 с данными / размером около 50 ГБ, экземпляр Amazon EC2 xlarge (64).
Здесь есть некоторая связанная информация. Главный вывод - это пост от Брайана Мерфи:
Уже 1,5 года работает с очень загруженной базой данных OLTP postgres объемом 170+ ГБ на Amazon. Я не могу сказать, что я "счастлив", но я заставил это работать и все еще предпочитаю бегать по центру города в коло в 3 часа ночи, когда что-то идет не так.
Есть две основные вещи, которых следует опасаться:
1) Физический ввод-вывод не очень хорош, поэтому первая система использовала RAID0.
Давайте проясним, что физический ввод-вывод временами ужасен. :)
Если у вас база данных большего размера, тома EBS станут настоящим узким местом. Для нашей первичной базы данных требуется 8 томов EBS на RAID-диске, и мы используем slony для разгрузки запросов на две подчиненные машины, и она по-прежнему не успевает.
Невозможно запустить эту базу данных на одном томе EBS.
Я также рекомендую использовать RAID10, а не RAID0. Тома EBS выходят из строя. Чаще отдельные тома будут испытывать очень продолжительные периоды низкой производительности. Чем больше драйвов у вас будет в рейде, тем лучше вы все сгладите. Однако были случаи, когда нам приходилось заменять плохо работающий том на новый и перестраивать RAID, чтобы восстановить скорость. Вы не можете этого сделать с массивом RAID0.
2) Надежность EBS ужасна по стандартам баз данных; Я уже немного прокомментировал это на http://archives.postgresql.org/pgsql-general/2009-06/msg00762.php Конечным результатом является то, что вы должны быть осторожны с тем, как вы выполняете резервное копирование своих данных, с непрерывным потоковым резервным копированием с помощью доставки WAL является рекомендуемым подходом. Я бы не стал развертывать в этой среде в ситуации, когда потеря минуты или двух транзакций в случае сбоя EC2 / EBS была бы неприемлемой, потому что это то, что может произойти здесь с большей вероятностью, чем на большинстве оборудования для баз данных.
Согласовано. У нас есть три запасных части, поставляемые WAL. Один передает наши файлы WAL на один том EBS, который мы используем для резервного копирования моментальных снимков наихудшего сценария. Два других являются точными копиями нашей первичной базы данных (одна в центре обработки данных на западном побережье, а другая в центре обработки данных на восточном побережье), которая у нас есть для аварийного переключения.
Если нам когда-либо придется выполнить восстановление по наихудшему сценарию из одного из наших снимков EBS, мы отключимся на шесть часов, потому что нам придется передавать данные из нашего снимка EBS обратно в массив рейдов EBS. 170 ГБ при 20 МБ / сек (если вам повезет) занимает ДОЛГОЕ время. Для того, чтобы один из этих снимков стал «пригодным для использования» после создания из него диска, требуется от 30 до 60 минут, а затем нам все равно приходится вызывать базу данных и мучительно долго ждать потоковой передачи горячих данных обратно в память.
За последние 1,5 года нам дважды приходилось переключаться на один из запасных. Не смешно. Оба раза произошли из-за сбоя экземпляра.
На EC2 можно запустить более крупную базу данных, но для этого потребуется много работы, тщательное планирование и толстая кожа.
Брайан
