일단 이 이야기는 적어도 한국의 기준에서, 가장 많은 서버가 가장 많은 서빙을 하고 있는 한 장르에 국한된다.
웹사이트 운영에 있어 필수불가결 사항인 게시판이라는 분야다.
현재를 분석하자면,
최적화된 소스위에 단순하며 엉성한 데이터베이스 구조체를 가진 BBS를 운영중에 있다.
이 BBS는 MySQL 이라는 DBMS를 통해 구동중에 있으며,
현재는 높은 I/O로 인해 부하의 한계에 다다랐다.
그로인해 새로운 구조체를 만들어내게 되었고 새로운 시스템을 고안해야만했다.
한국이라는 한정적인 언어권을 염두해두어야 한다는 문제가 여기에 크게 기인하고 있다.
Full Text Search 의 Function 을 사용할 수 없다는 문제다. (혹자는 사용한다고도 하지만 그 정확도로 볼때 도저히 서비스할 수 있는 수준이 아니다.)
편법적인 방식으로 을/를 는이나 감탄사나 몇가지 조사들을 띄어내는 형식으로 인덱싱을 하는 경우를 포함한 이야기다.
따라 완벽한 서칭은 *스트링* 베이스의 와일드 서치이지만, 이러한 서치는 현실적으로 더이상 제공하기 힘들다는 문제점이 생겼다.
별도의 서치시스템을 분리해내기로 결정을 했지만 여기엔 다른 문제가 있었다.
관리적인 문제와 이상적 게시판 시스템을 위한 구조에는 1개의 테이블에 모든 자료를 저장하는것이 좋다.
이것은 일련화된 record number를 부여함으로 인해 발생하는 관리의 편의성이기도 하다.
이를테면, 게시물을 이동해야 하는 경우, 서로 다른 테이블에 빡빡한 record 사이에 30개의 게시물이 이동했다고 치자, 알고리즘은 크게 2가지로 나뉜다.
1. 이전대상 테이블의 이전시기를 기준 이후의 모든 게시물의 record number를 증가시킨다. (활동량이 많지 않은 게시판의 경우 maximum counting / 약 5천만개 이상의 테이블을 업데이트 해야하는 일이 발생한다)
2. 단순하게 게시물의 소팅오더를 작성일자로 한다.
-> 그러나 스레드 아티클 , 이른바 답글이라는 기능이 여기에 붙게되면 소팅의 기준이 모호해지게된다
물론 몇개 되지 않는 게시물에서는 별다른 문제가 없어보일지 모른다.
생각해야할것은 "밀리세컨드 단위의 필드가" 유니크 프라이머리 키가 될 수 있는가?와 1억건이 넘는 레코드를 매번 리미트 쿼리로 끊어올것인가?
잘 이해가 안될지몰라 부연설명하자면 레코드 기준점이 모호한 상태에서 들쑥날쑥한 인덱스 데이터를 페이징쿼리를 할때에는 더 많은 디스크 I/o가 발생한다.
단순히 생각하라 당신이 가져와야할 인덱스 파일의 크기는 200메가를 초월하고 있다. offset seeking을 한다 하여도 최소 40메가의 디스크 데이터를 액세스 해야한다는 문제에 직면하게된다.
또 이 경우 btree 인덱스 구조가 나타내는 치명적인 문제점이 드러난다. 대량자료의 경우 40% 이상의 옵티마이즈된 렌지를 넘어서게 되면 결과가 뒤섞이는 경우가 존재한다.
여기에 해결책은 rownum/rowcount라 불리는 기능이기도 하다. 이것은 오라클과 postgresql이 지원하고 있는 기능중 하나다.
현재의 시스템은 단순하게.. 새게시물의 최상단에 올라오는정도로밖에는 지원하고 있지 않다.
결국 이러저러한 문제점으로 인해 현재는 MySQL의 Innodb를 기반으로 제작이 거진 완성되어가고 있다.
하지만 방대한 인덱스를 전체적으로 시킹한다는것은 또한 넌센스급의 과제가 되어가고 있다.
현재 성능은 매우 뛰어나다고 할수있을정도로 빡빡한 렌지옵티미제이션과 다른 테이블을 통한 분차별 오류자료 수집/보정 및 캐싱을 구현하고 있다.
소스코드가 매우 복잡해지고 있다는 소리다. 하지만 이것은 빙산의 일각이다.
다른 기업들과 마찬가지로 단순한 게시판 서비스만이 아닌, 진보되고 확장된 연동기능을 상당히 필요로 하게되며 이러한 자료들은 외래키로써 다른 자료와 유기적으로 연동되어야할 필요성이 있다.
그 선택의 끝은 innodb 라는점이었다.
퍼포먼스의 면에서는 PostgreSQL이 압도적으로 좋아보이는 점이 있으며( 아직 자세히 파보진 않아서 모른다.
단순한 고민에 대한 이야기라는것을 다시 기억하자)
사용하고 싶은 데이터베이스로 머리속에 자꾸 맴돌아 오늘 시간이 나서 이것저것 알아보기 시작했다.
pgsql사이트와 DSN에 올라온 게시물을 검토하던중 몇가지 눈에 띄는 이슈를 발견하게된다.
1.SQL쿼리들이 일단 빡빡하다. 나쁘지 않다. 하지만 어느정도의 편의는 필요로 하지 않을까 하는 정도의 아쉬움이 보이긴했다. 일례로 datetime 등의 자료저장이나 null문자 처리등의 형식으로 봐선 C로 만든 데이터베이스 수준이라고 해야할정도다.
물론 불편한만큼 성능은 올라가기 마련이다.
제일 불편한것은 C로 날코딩을 하는것이다. 감히 pgsql은 이 수정하기 힘든 로레벨 언어로 코딩된 db의 압도적인 퍼포먼스에 대항할수 없을것이다.
2.pgsql의 장점이라고 불리오는 커넥션풀러가 아직 불안정해보인다. 몇몇 크리티컬한 버그와 이슈들만 일단 보았다. 과연 이것을 사용해도 될것인가 하는 의문만 쌓여가게되었다.
고쳐진것만 보아서는 안정성이 있지만 그러한 이슈들이 있었다는것은 발견되지 못한 다른 더 많은 이슈가 따라올수있다는 문제가 존재한다.
(언제나 극한의 상황에서는 상상하지 못하는 문제가 벌어진다)
3.Configuration Issue Solved!
more..
-> 최신의 pgsql은 스택오버플로나 kill order 오류등이 모두 해결되었다. (WAL등의 로그형식대안) 따라 이전에 대한 문제사유는 없으며 확실하지는 않지만 모든 유형의 innodb, myisam structures 는 호환되는것으로 보인다.
지금 이런 고민중의 하나는 pgsql은 매혹적인 구조와 성능, 안정되어 보이는듯한 클러스터링,
파츠파츠가 의외로 잘짜여져있는것처럼 보이기 때문일지도 모른다.
장시간의 테스트와 서비스등으로 안정성을 찾아나가야 하는 문제다.
(0) 
(0)Posted by LeCieL