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

Раніше я використовував Пентахо. Не безпосередньо з postgres, але я вважаю, що це хороше рішення як для OLAP (Mondrian), так і для ETL (чайник)

http://www.pentaho.com/

редагувати: "Видання спільноти" можна знайти тут

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

Slony був гарний та швидкий для нашого клопоту, але це може бути суворим викладачем.

Оскільки OLAP-сервер буде постійно зростати, вам слід подумати про те, щоб використовувати якийсь розподіл, якщо це застосовно.

Якщо є можливість, використовуйте об'єднання з'єднань. Я використовував лише PgPool, і він працював бездоганно. PgBouncer - інший варіант. Окрім зменшення затримки init, це також зменшує запуск та керування сеансом. 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/