PostgreSQL для транзакций большого объема и для хранилищ данных

Я новичок в PostgreSQL, я никогда не делал большого развертывания, используя его раньше. Но у меня есть хороший опыт в корпоративных решениях, и я хочу попробовать применить кое-что из того, что я узнал, с помощью PostgreSQL.

У меня есть сайт, который рассчитан на большое количество данных и трафика. Инфраструктура будет построена с использованием Amazon (AWS) с использованием экземпляров EC2 и томов EBS.

Проект должен иметь две базы данных, основную транзакционную базу данных и хранилище данных для обработки анализа и отчетности.

Основная транзакционная база данных

будет использоваться для живого веб-сайта, сайт построен на нескольких узлах для увеличения числа одновременных пользователей. В основном мы требуем, чтобы база данных в этом случае была чрезвычайно быстрой при операциях чтения, мы ожидаем, что> 100 ГБ данных при годовом росте 30%. На данный момент мы планируем использовать два сервера EC2 ( и добавим больше по мере необходимости ).

мой вопрос, какова рекомендуемая установка для вышеуказанных требований? Плюс, есть ли способ управлять разделением таблицы и тома? есть ли рекомендации по использованию настройки AWS?

База данных хранилища данных

Будет использоваться в основном для сбора всех данных из основной транзакционной базы данных во временном измерении. таким образом, даже удаленные записи из основной базы данных будут записываться в DWH. Поэтому данные будут очень большими, а рост будет еще больше. Мы также будем использовать пару экземпляров EC2 или более, если это необходимо.

Какая настройка рекомендуется в этом случае? это потребует быстрой операции записи из-за постоянной записи (ETL). Можем ли мы построить кубы OLAP в PostgreSQL? если да, кто-нибудь там пробовал?

Подключение к базе данных

Веб-серверы будут подключаться к основной базе данных для запроса и записи. В настоящее время мы разрабатываем приложение, использующее django, которое использует нативную библиотеку для подключения. Рекомендуется ли использовать тот же основной метод? или мы должны настроить pgpool?

Хранилище данных (ETL)

Каков рекомендуемый способ построения процессов ETL для чтения из основного и загрузки в хранилище данных? Какие-нибудь инструменты? методология следовать? PostgreSQL предлагает какие-либо полезные функции / инструменты для построения ETL-процессов?

Услуги инфраструктуры / базы данных

Вероятно, вам следует прочитать это для обзора сайта с большим объемом, который работает на AWS с EBS. Они переместились в хранилище Ephemeral, но им пришлось создать некоторую избыточность, чтобы иметь возможность (повторно) хранить данные.

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Хранилище данных / ETL

Я использовал Pentaho в прошлом. Не напрямую с postgres, но я нашел, что это хорошее решение для OLAP (Mondrian) и ETL (Kettle)

http://www.pentaho.com/

редактировать: "Community Editions" можно найти здесь

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

соединение

Эти люди, кажется, действительно любят pgbouncer. /programming/1125504/django-persistent-database-connection

У меня нет опыта с этим, хотя. Судя по всему, Disqus использует его.

Ваша установка похожа на ту, которую я разработал для университета. База данных была не огромной, но довольно большой, размером около 300 ГБ, а самая большая таблица содержала около 500 миллионов записей. И все еще растет.

Для этой цели были использованы два действительно мощных сервера (реальное железо, а не виртуализация), один из которых предназначен для обработки данных с веб-сайта, а другой - для статистических расчетов и анализа. Данные были воспроизведены в обоих направлениях с использованием Slony. Данные OLTP непрерывно реплицировались на сервер OLAP, а некоторые схемы и отдельные таблицы реплицировались с OLAP-сервера на OLTP. Таким образом, тяжелые вычисления могут быть выполнены на сервере анализа без влияния на OLTP-сервер. В настоящее время для репликации данных существует несколько альтернатив Slony: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html.

Слони был хорош и быстр для нашей заботы, но может быть суровым учителем.

Поскольку OLAP-сервер будет стабильно расти, вам следует рассмотреть возможность использования какого-либо разделения на разделы, если это применимо.

Если есть возможность, используйте пул соединений. Я использовал только PgPool, и он работал безупречно. PgBouncer - это еще один вариант. Помимо уменьшения задержки инициализации, это также уменьшает запуск сеанса и управление сеансом. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Еще одним преимуществом использования пула соединений является то, что вы получили единственную точку, в которой вы можете легко перенаправить свой трафик (это, конечно, также может быть риском).

Я не использовал готовый ETL для загрузки данных на сервер OLAP. Я написал свой собственный скрипт на Python, так как некоторые данные доставлялись в огромных текстовых файлах с особым форматом.

Структура базы данных должна быть тщательно продумана. Использование схем хорошо для сбора и облегчения обработки объектов. На первый взгляд может показаться обременительным использование схем, но по мере роста количества объектов вы будете благодарны. Зная, что вы должны явно добавлять объекты к их схеме, вы точно знаете, над какими объектами вы работаете. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Для смелых PostgreSQL XC будет интересной альтернативой или просто негабаритным костюмом http://postgres-xc.sourceforge.net/