여기저기 기웃거리기

PostgreSQL에서 Oracle RAC와 같이 모든 노드에서 읽고 쓰기를 할 수 있는 클러스터를 구축하고자한다면 Postgres-XC를 검토하게 될 것이다. 물론 다른것도 존재하겠지만 이 녀석이 가장 좋아보인다.

관련 자료 검색 중에 PGXC-Tools라는걸 발견했다. Koichi suzuki라는 분이 만든 오픈소스 툴로 Postgres-XC를 운영하는데 유용한 스크립트/프로그램 모음이라고 한다.

웹사이트 : http://github.com/koichi-szk/PGXC-Tools

아래 사진은 github에서 툴에 대해서 설명한 부분을 캡쳐한 것이다.




iPhone 에서 작성된 글입니다.

PostgreSQL 9.3에서 선보일 새기능에 대한 소식이다.

아래 주소는 관련 내용을 볼 수 있는 Michael Paquier의 블로그 글이다.
http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-materialized-views/

흔히 오라클에서 M-View라고 부르는( 티베로도 동일한 이름이다. ) Materialized view가 드디어 PostgreSQL 9.3 버전에 추가 된다.

좀더 융통성있는 데이타 서비스( 개발자들에게 )가 가능해질듯하다. 쓸만할듯...

CREATE MATERIALIZED VIEW
ALTER MATERIALIZED VIEW
DROP MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
위의 명령어들을 이용하여 관리할 수 있다.

9.3 버전이 빨리 공개되길 바란다.

신기능들을 좀 더 자세히 공부해 봐야겠다.

iPhone 에서 작성된 글입니다.

오픈소스 데이타베이스 PostgreSQL을 기반으로 분산 처리가 가능한 cluster db를 만드는 Postgres-XC project 홈페이지에 갔다가 위키가 이전된걸 발견했다.
소스포지의 위키에서 아래의 링크로 바꼈다는 안내되어있다. 소스포지의 위키 서비스가 종료되어서 이전했다고 한다.

http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki


iPhone 에서 작성된 글입니다.

드디어 PostgreSQL 9.2.2가 나왔습니다.
큰 문제들은 이제 다 정리된듯 합니다.

http://www.postgresql.org/about/news/1430/

iPhone 에서 작성된 글입니다.

지난번에 Postgres-XC 1.0.0에 대해서 글을 올렸는데 아직 문제가 좀 있다고 했었죠 이번에 1.0.1 버전을 테스트한 결과를 정리해서 올립니다. 짧게 얘기하면 "좋아졌다"입니다. ^^/


• 1.0.1 버전 개요
Postgres-XC 1.0.1은 PostgreSQL 9.1.5를 기반으로 만들어졌습니다.


• 지난버전 테스트 결과와 다른 점
1. 관리 툴
pgAdmin III 1.16.0 버전을 사용하면 오류메시지없이 접속됩니다. 한가지 아쉬운점이라면 dbms 버전 정보에는 PostgreSQL 9.1.5로 표시된다는 점입니다.

2. 트랜잭션 문제 해결
함수 내부에서 "select for update"로 데이터를 가져와서 다이나믹쿼리로 update문을 실행하면 일부 세션에서 데이터를 잘못가져오는 문제가 해결되었습니다.
1번 세션에서 begin 명령으로 트랜잭션을 시작한 후, 해당 함수를 실행한 뒤에 2번 세션에서 함수를 실행했을때 1번 세션의 트랜잭션이 종료된 후 update된 값을 "select fir update"로 가져와서 update해줍니다. 정상적으로 작동한다는 얘기입니다.
제 설명이 좀 복잡한가요? 회사에서 아이폰으로 작성하는거라 좀 시간도 부족하고 글 쓰기도 좀 힘드네요. 다음에 코드와 함께 집에서 다듬어서 적성하겠습니다.



iPhone 에서 작성된 글입니다.

이번에 ETL 작업을 하면서 겪은 당황스런 일을 적어두려합니다. 이번 작업은 아래에 설명할 두가지이며, 작업 환경은 다음과 같습니다.
세대의 장비는 모두 같은 건물 안에 있습니다. 멀리 넷트웍을 타고 전송되는 상황은 아닙니다.
ETL tool : GeoKettle
DBMS : PostgreSQL 9.x, Kairos 5.x


1. PC(1 cpu)에 설치된 PostgreSQL DB에서 데이타를 추출하여 서버(4 cpu)상의 PostgreSQL DB에 전송하는 작업.

2. 서버(4 cpu)상의 PostgreSQL DB에서 데이타를 추출하여 다른 서버(4 cpu)상의 Kairos DB에 데이타를 전송하는 작업.

1번 작업은 데이타 원본이 윈도우가 설치된 PC상에 있어서인지 오래 걸렸습니다. 더군다나 테이블끼리 1대 1로 전송하는게 아니라 원본에서 조인을 해서 추출을 하는 작업이었습니다. 오래걸리더군요. 이건 각오한 문제였구요.

그런데... 2번 작업에서 큰 문제가 생겼습나다. Kairos는 메모리 DB인데 데이타 로딩이 아주 느리더군요. 이건 뭐...
서버에서 서버로 보내는 것이고, 테이블도 거의 1대 1로 전송하는 상황이었고, 메모리도 각각 50GB 정도 설치되어 있었습니다. 더군다나 아직 서비스에 쓰이는 장비도 아닌데 초당 270건 정도밖에 안되더군요. ㅠㅠ

그래서 눈물을 머금고 text로 추출해서 로딩하는 방식을 썼습니다.

한가지 더 문제가 있었는데, GeoKettle로 Kairos에 데이타를 이전할때 not null 제약이 걸린 컬럼에 null 값이 들어가면 오류가 발생하지 않고 행이 걸린것처럼 멈춰 있더군요. jdbc 드라이버 문제인지 GeoKettle의 문제인지 모르겠습니다. 암튼 이 문제땜에 에러가 안 뜨니 좀 기다려보자는 생각에 시간을 많이 소비했었죠.




사용한 툴과 디비를 보시면 아시겠지만 gis 관련 데이타를 다루는 작업이었습니다. 문제는 Kairos는 GeoKettle이 지원하지 않는 제품이라 이 툴로는 일반적인 문자, 숫자 등의 데이타가 아닌 공간 데이타는 Kairos로 이전을 할 수가 없었습니다. 오픈소스인 Pentaho Kettle 기반의 제품이니까 공부를 좀 해서 Kairos의 공간 데이타를 인식할 수 있게 만들어 보고 싶다는 생각을 해봅니다. 실제로 진행을 할 수 있을지는 모르겠습니다만...

그럼 평온한 밤 보내시길~~~

iPhone 에서 작성된 글입니다.

Postgres-XC로 시스템을 구축하려고 공부 중입니다. 아직 보기 좋게 정리는 못 했고 우선 간단히 장단점을 적어보려합니다.
회사에서 외부 사이트를 거의 막아놔서 아이폰에서 작성하는거라 글로만 설명하는 점 이해해주시길 바라며...

1. 장점
1.1. Open source라 구축 가능한 인력과 시간, 그리고 장비만 있으면 소프트웨어 라이선스 비용은 들지 않는다.

1.2. 읽기 및 쓰기 부하 분산이 가능하다.

1.3. Oracle RAC처럼 어플리케이션에서는 읽고 쓰는것을 구분하여 디비 접속을 하지 않아도 된다. 전체 노드가 읽기 및 쓰기가 가능하다.

2. 단점
2.1. 1.0 버전이 출시된지 몇달되지 않아서 구축 사례와 한글로 된 자료 등이 거의 없다.

2.2. PostgreSQL 9.1.x 버전에서만 사용 가능하다. 고로 이전 버전을 쓰고 있다면 업그레이드를 해야한다.

2.3. Trigger를 지원하지 않는다.
현재로는 지원하기 어렵다고한다.

2.4. 관리 툴의 부재
기존의 pgAdmin으로는 접속시 오류가 발생하여 관리가 불가능하다.

2.5. 트랜잭션의 문제
펑션 내부에서 dynamic query를 이용하여 update를 하도록 만들어서 여러세션에서 사용했을때, 트랜잭션을 걸어서 사용하면 일부 update문이 실행되지 않는 문제 발생.
설정의 문제인지 버그인지 확인 중입니다.

그런데 위의 문제로인해서 일단 업무에 Postgres-XC을 도입하는것은 보류한 상태입니다.


iPhone 에서 작성된 글입니다.

Postgres-XC에 대해서 검색하다가 찾은 글이다. PostgreSQL의 streaming replication과 pgpool-II를 같이 쓰면 어플리케이션에서 접속 정보 변경없이 읽기, 쓰기를 구분하고 부하분산도 가능하다고 한다.
아... 이것도 꽤 쓸만한 구성인것 같은데...

원문 링크 : http://avicom.tistory.com/m/post/view/id/94

아래는 원문의 일부이다. 전체 글은 위의 링크를 클릭하면 볼 수 있다.


별도의 replication 관리 DB가 필요없고 복제 대상 테이블에 trigger를 설치할 필요가 없다.
아카이브 로그 파일을 읽을 필요가 없다
warm standby의 단점이었던 recovery중인 slave db에 대한 엑세스 제한이 없다.
multi-slave 설정이 가능하다.
streaming replication과 pgpool-II를 조합하면 소스에서 타겟DB를 변경하지 않고도 read/write db를 구분하여 select 쿼리를 slave db로 분산시킬 수 있다.

iPhone 에서 작성된 글입니다.

PostgreSQL을 사용하다보니 같은 DB내에서 혹은 다른 DB에 존재하는 테이블의 view를 만들어놓고 사용하는 경우가 종종 있다. (PostgreSQL의 디비링크가 아주 불편하기 때문이기도하고, DA분이 너무 정규화를 잘 해놓았기 때문이기도 하다.)

PostgreSQL에서 처음에 뷰를 만들었을때...... 신기하게도 select만 가능한지 몰랐었다. update문을 실행해보고서야 곤란한 문제가 생겼다는것을 알게되었고, 곧바로 구글 검색과 메뉴얼 검색을 통해서 rule이라는걸 찾게되었다.

rule이란 걸 이용하면 뷰에서 DML문이 실행되면 해당 rule에 맞는 부분만 실행이 되더군요.

예를들어서 update 구문에 대한 rule을 만들면서 "update emp set ename where empno = new.empno"라고 쿼리문을 설정해주면 이 뷰에서는 ename 컬럼만 수정이 가능해집니다.

재밌는 기능이죠. 좀더 자세한 기능과 예제는 다음에 정리해서 올리겠습니다.

iPhone 에서 작성된 글입니다.