О практическом использовании PostgreSQL

В рассылке pg-general недавно состоялась интересная дискуссия на тему использования PostgreSQL в больших аналитических базах данных. Сообществу были заданы 8 вопросов и ниже приведены некоторые интересные ответы на них.

1. Каков размер вашей базы данных?

Скотт Марлоуи (Scott Marlowe): Я сталкивался с базами в несколько сотен гигабайт.

Брент Вуд (Brent Wood): Сейчас некоторые таблицы в нашей базе содержат до 70 колонок и 5 млн. записей. Всё вместе занимает около 50 ГБ. В базе используется PostGIS, мы им очень довольны.

Дэвид Уилсон (David Wilson): Используем базу с ~650 млн. записей в 10 таблицах. Общий объём — около 160 ГБ.

Марк Робертс (Mark Roberts): 2.5-3 ТБ.

2. Какую операционную систему вы используете?

Скотт Марлоуи: Обычно работаю с Linux (RHEL, CentOS или Ubuntu).

Дэвид Уилсон: База работает на Ubuntu в основном потому, что все начиналось с небольших объёмов. Система хорошо работает и сейчас, поэтому у нас никогда не возникало необходимости её менять.

3. Какой тип RAID-массивов вы используете?

Скотт Марлоуи: Для транзакционных баз данных *всегда* RAID 10. Для аналитических БД иногда RAID 5, но в основном RAID 10. Сервер для отчётов, который я делал для своей последней компании, работал на оставшихся от основного «железа» запчастях на программном RAID 10 из 4 SATA дисков по 150 ГБ. Он легко обгонял стоящий на соседней машине Oracle RAC на RAID 6 из 14 дисков, делающий отчёты по тем же данным.

Брент Вуд: Для чтения мы используем программный RAID 0 из 2 дисков WD 10 000 RPM Raptor. Для безопасности данных по чётным дням мы делаем резервную копию базы на 250 ГБ диск в этой машине и дополнительно копируем всё на ленту.

Дэвид Уилсон: В настоящий момент используем RAID 0. БД может быть восстановлена заново с нуля при необходимости, поэтому мы не боимся проблем с жёсткими дисками.

4. Сколько ядер процессоров и как много памяти установлено в вашем сервере?

Скотт Марлоуи: Сервер для отчётов в моей последней компании имел один процессор P4 с hyperthreading и 4 ГБ памяти; сейчас в моём OLTP-сервере стоит 8 процессоров AMD Opteron и 32 ГБ памяти.

Дэвид Уилсон: Наш сервер работает с 4 ГБ памяти и Quad-Core Xeon 2.5 GHz.

5. Какова производительность операций соединения (join)?

Скотт Марлоуи: Я всегда был ей очень доволен. Я бы сказал, что планировщик запросов в PostgreSQL очень умён и легко справляется со сложными запросами. Операции соединения никогда не были проблемным местом, чаще приходится думать, как правильно построить агрегатные запросы и сложные подзапросы.

Марк Робертс: «Джойны» действительно неплохо работают. Мы регулярно выполняем запросы на соединение главной таблицы фактов с таблицами метаданных и в среднем они выполняются за 10-30 сек. Мы также используем денормализованные представления для цепочек/иерархий в таблицах с метаданными.

6. Какова производительность операций загрузки данных?

Скотт Марлоуи: Сильно зависит от вашего аппаратного обеспечения. Я могу развернуть 15 ГБ транзакционную базу за 15-20 минут на одной машине с 8 ядрами и 16 дисками.

Марк Робертс: Операции загрузки/копирования работают удивительно быстро. У нас одновременно запущено более 10 конкурентных процессов загрузки данных и 2-3 процесса их агрегирования.

7. Сколько одновременных соединений установлено к PostgreSQL и какова средняя скорость передачи данных в предположении, что каждый клиент читает только 1 таблицу?

Скотт Марлоуи: К нашей production-базе одновременно установлено около 600 соединений, из которых активными являются несколько десятков. Скорость случайного чтения составляет 60-70 МБ/сек; скорость последовательного чтения при этом — 350-400 МБ/сек.

Марк Робертс: Около 50 одновременных соединений.

8. Вы используете один сервер или кластер; если кластер — какое ПО вы для этого используете?

Скотт Марлоуи: Мы используем 2 сервера (один в качестве Slony-мастера, другой в качестве slave) и приложение балансирует нагрузку на чтение между ними. Важно отметить, что PostgreSQL хорошо масштабируется при увеличении аппаратных ресурсов. Если вы купите много дисков в хороший RAID-контроллер, вы получите хорошую пропускную способность. Если вам нужна база только для
чтения (read only) или почти только для чтения (read mostly), RAID 5 или 6 для нее может быть лучше, чем RAID 10. Я использую последний в большинстве случаев, если RAID 5/6 не обгоняет его в тестах.

Марк Робертс: У нас есть мастер и его реплика. В отдалённых планах у нас стоит использование кластера, но это далеко не срочная процедура, так как на нашем примере видно, что PostgreSQL легко справляется с объемом данных в 3 ТБ на относительно недорогом (менее $30 тысяч) оборудовании. Я бы хотел добавить ещё пару комментариев. Наша база данных представляет собой типичную ETL-базу: средний/высокий темп загрузки данных при необходимости доступа к ним с минимальной задержкой. К сожалению, я не могу ответить на вопросы об аппаратном обеспечении — начальство попросило меня не делать этого. Могу лишь сказать, что мы используем обыкновенный сервер с достаточным количеством оперативной памяти и дискового пространства. Для меня наш пример является блестящим доказательством того, что базы на PostgreSQL, даже с «наивной» архитектурой, как у нас, отлично масштабируются до пределов аппаратного обеспечения, которое вы выделяете для СУБД сервера. Самая большая база PostgreSQL на одном сервере, которую я встречал, имела размер в 4 ТБ, а компания Yahoo! при этом использует модифицированный PostgreSQL на объемах данных в 2 петабайта. Моя мысль проста: один сервер PostgreSQL справится с несколькими терабайтами данных без всякой магии.

Пока без оценки

Отправить комментарий

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <strike>
  • Строки и параграфы переносятся автоматически.
  • Поисковые системы будут индексировать и переходить по ссылкам на разрешённые домены.

Подробнее о форматировании

Яндекс.Метрика