대용량 트랜잭션 및 데이터웨어 하우징을위한 PostgreSQL

PostgreSQL에 익숙하지 않기 때문에 이전에는 대규모 배포를 한 적이 없습니다. 그러나 엔터프라이즈 솔루션에 대한 경험이 풍부하며 PostgreSQL을 사용하여 배운 내용 중 일부를 적용하고 싶습니다.

많은 수의 데이터와 트래픽을 처리 할 수있는 크기의 사이트가 있습니다. 인프라는 EC2 인스턴스 및 EBS 볼륨을 사용하여 AWS (Amazon)를 사용하여 구축됩니다.

설계에는 분석 및보고를 처리하기위한 주 트랜잭션 데이터베이스와 데이터웨어 하우스의 두 데이터베이스가 있어야합니다.

주요 거래 데이터베이스

라이브 웹 사이트에 사용되며, 사이트는 여러 노드에 구축되어 동시 사용자를 확장합니다. 주로이 경우 데이터베이스가 읽기 작업 속도가 매우 빠를 것을 요구하며 연간 30 % 성장으로 100GB가 넘는 데이터를 기대합니다. 이 시점에서 우리는 두 개의 EC2 서버를 사용할 계획입니다 ( 필요에 따라 나중에 더 추가 ).

내 질문에 위의 요구 사항에 권장되는 설정은 무엇입니까? 또한 테이블 및 볼륨 파티셔닝을 관리하는 방법이 있습니까? AWS 설정 사용에 대한 권장 사항이 있습니까?

데이터웨어 하우스 데이터베이스

주로 주요 트랜잭션 데이터베이스의 모든 데이터를 시간 차원에서 캡처하는 데 사용됩니다. 따라서 주 데이터베이스에서 삭제 된 레코드도 DWH에서 캡처됩니다. 따라서 데이터가 매우 커지고 성장이 더 커질 것입니다. 필요한 경우 몇 EC2 인스턴스 이상을 사용합니다.

이 경우 권장되는 설정은 무엇입니까? ETL (Constant Writing)로 인해 빠른 쓰기 작업이 필요합니다. PostgreSQL에서 OLAP 큐브를 구축 할 수 있습니까? 그렇다면 누구든지 시도해 보셨습니까?

데이터베이스에 연결

웹 서버는 기본 데이터베이스에 연결하여 쿼리하고 작성합니다. 현재 django를 사용하여 연결을 위해 기본 라이브러리를 사용하는 응용 프로그램을 개발 중입니다. 동일한 기본 방법을 사용하는 것이 좋습니다? 아니면 pgpool을 구성해야합니까?

데이터웨어 하우스 (ETL)

ETL 프로세스를 빌드하여 기본 및로드에서 데이터웨어 하우스로 읽는 권장 방법은 무엇입니까? 어떤 도구? 따라야 할 방법론? PostgreSQL은 ETL 프로세스 구축에 유용한 기능 / 도구를 제공합니까?

인프라 / 데이터베이스 서비스

EBS를 사용하여 AWS에서 실행되는 대용량 사이트에 대한 개요는이 내용을 읽어보십시오. 그들은 임시 스토리지로 옮겨졌지만 데이터를 (재) 저장할 수 있도록 중복성을 만들어야했습니다.

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

데이터웨어 하우스 / ETL

나는 과거에 펜타 호를 사용했습니다. postgres와 직접적으로는 아니지만 OLAP (Mondrian)와 ETL (Kettle) 모두에게 좋은 솔루션이라는 것을 알았습니다.

http://www.pentaho.com/

편집 : "커뮤니티 에디션"은 여기에서 찾을 수 있습니다

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

연결

이 사람들은 정말 pgbouncer를 좋아하는 것 같습니다. /programming/1125504/django-persistent-database-connection

그래도 경험이 없습니다. 분명히 Disqus가 사용합니다.

귀하의 설정은 제가 대학을 위해 개발 한 것과 유사합니다. 데이터베이스는 크지 않았지만 크기는 약 300GB 였고 가장 큰 테이블에는 약 5 억 개의 레코드가 포함되었습니다. 그리고 여전히 성장하고 있습니다.

이를 위해 웹 사이트에서 데이터를 처리하는 데 사용되는 전용 서버와 통계 계산 및 분석에 사용되는 두 대의 서버 (실제로 가상화되지 않은 실제 아이언)가 사용되었습니다. 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

연결 풀을 사용하는 또 다른 이점은 트래픽을 쉽게 리디렉션 할 수있는 단일 지점이 있다는 것입니다 (물론 위험 할 수도 있음).

OLAP 서버에 데이터를로드하기 위해 기성품 ETL을 사용하지 않았습니다. 일부 데이터가 독특한 형식의 거대한 텍스트 파일로 전달되었으므로 Python으로 자체 스크립트를 작성했습니다.

데이터베이스의 구조는 신중하게 고려해야합니다. 스키마를 사용하면 개체를 쉽게 수집하고 처리 할 수 ​​있습니다. 스키마를 사용하는 것으로 시작하는 것은 번거로울 수 있지만 개체 수가 증가함에 따라 스스로 감사 할 것입니다. 객체에 스키마를 명시 적으로 접두사로 붙여야한다는 것을 알면 정확히 어떤 객체를 조작하는지 알 수 있습니다. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

대담한 사람들에게는 PostgreSQL XC가 흥미로운 대안이거나 대형 의상입니다. http://postgres-xc.sourceforge.net/