Intelligence Hacker

뭐 지금도 대세라면 대세고 아니라면 아닐수도 있겠지만 ^^

몇가지 이슈가 있다.

하나는 PG가 갈수록 심각하게 빠른 속도로 발전하는데다가 Enterprise DB가 나오면서 가장 크게 내세우는 장점이 Oracle Compatibility 라는 점이다. 뭐 쿼리 자체(어차피 특별히 뭔 짓을 하지 않는 표준 SQL이라면 뭐..)나 관리용 테이블, odbc/jdbc 컨트롤 등이 호환되는건 힘들겠지만 전반적인 User Level Table이라면 거의 그대로 포팅 가능한 수준이 된 것이 아닌가 하는 것이고..(이전에는 6~24Hour Migration 이라면 지금은 1Hour Migration 체제라고 이해하면 될 듯)

일단 상용 환경에서의 PG가 가지는 최고의 단점은 Commercial이 아니라는 것. 그 간격은 일단 EnterpriseDB나 PostgreSQL Plus 등이 어느 정도는 매꿔줘야 할 것 같고, 영업/유통은 레드햇이 같이 끼고 들어간다면 그리 힘들지만도 않을 듯 하다.

일단 엔지니어 커버는 아직 Oracle이나 MySQL 대비 국내 인력이 월등히 부족한 건 사실이지만 그렇다고 무슨 대단히 복잡한 짓을 하지 않는 이상 DBA 레벨이라면 기존 DB 하는 양반들도 다 할 수 있을것이라고 보고, 거기에서 뭔가 좀 더 심오한 부분으로 간다 하더라도 뭐 다른 DB라고 DBA가 튜닝한다는게 무슨 큰 의미가 있는 튜닝을 하는 시스템 전체를 바라보는, 혹은 DB만이라도 제대로 볼 줄 아는 실력이 있는 DBA가 많지 않으니까 어느 분야나 마찬가지라고 보는거고..결국 기술지원체계가 문제가 되는거겠지..

헌데 문제는 이런게 아니라, 얼마전에 Postgre측에서 CUDA 플랫폼 기반으로의 포팅을 시작했다는것이다. CPU 기반과 GPU 기반의 차이..일반인들은 잘 체감하기 어려울지도 모르지만 일반 우리가 쓰는 조금 비싼 그래픽카드만 해도 퍼포먼스가 한참 달라지고 여기에 Tesla MultiCore GPU 기반으로 간다면 I/O만 감당해 준다면 퍼포먼스가 정말 기하급수적으로 올라간다고 보면 된다. 뭐 개인적으로 기대하는 것은 Cell/BE 기반이지만 가격도 그렇고 아키텍쳐 플랫폼도 그렇고, 개발을 할래도 개발 플랫폼 제공이 되어야하는데 그게 힘들테니 감당할 것이 너무 커져서인가 하여간 DB계열에서는 그다지 관심을 받지 못하고 있는 듯 하다. (아니 그냥 PPC CPU 쓰는 하드웨어에 DK만 올리고 개발하면 되지 않느냐..라고 생각할 수준은 아닌것 같아서..)

뭐 MySQL도 CUDA로 가면 되지 않느냐고 하지만, 아니 근데 이미 MultiCore 기반이나 고성능 CPU에서 MySQL 대비 PG의 퍼포먼스가 확연히 차이나는 수준으로 PG가 앞서고 있는 마당에 고성능 CPU에서의 MySQL의 성장가능성을 논할 필요가 있을까 싶기도 하고, 아직 MySQL 계에서는 아직 논의의 수준을 벗어나지 못하고 있는것도 있고..그쪽에서도 크게 관심은 없는것 같더라고..(그리고 이미 MySQL은 오라클의 것이잖아? 오픈소스라고는 하지만 이미 로드맵이 서로 달라지는거지. 커머셜 레벨 기준으로 생각하고 갈텐데 실험적인걸 자꾸 도입하는걸 코어쪽에서 반기기는 힘들거고..누가 아예 백포팅해서 가지쳐 나가지 않는 이상..)

하여간 이래저래 갈수록 MySQL은 진화가 정체되는 느낌이고 PG는 갈수록 기하급수적으로 성장하는 느낌. 오라클은 뭐 어차피 상용레벨로 가야하니까..오라클은 Processing은 그냥 일반 CPU벤더쪽에 일임하고 별다른 움직임을 취하지 않는 상태로 MemoryDB질이랑 I/O 성능 개선하고 SSD홍보나 하고 관리툴이나 계속 복잡다양하게 만들어서 사용자 낚시질을 하고 있고..(그래도 11g는 참 좋은 제품인것은 틀림없어..)

근데 어차피 내년 후반 넘어가면 인텔이나 AMD나 CPU에 embeded GPU 방식으로 나올텐데 오라클 입장에서도 GPU processing에 대한 부분은 준비를 하지 않으면 한순간에 따라잡힐수도 있는 문제임에도 별다른 대응이 없는것은 다소 의아할 따름. 로드맵이 너무 확고해서 새로 가지쳐 뻗어나가기엔 버거운 것일까? 아니면 어차피 일반 사용자 레벨이나 기업 입장에서 GPU based DB 가 그렇게 혹하는 조건이 아닐 수도 있다고 생각하고 있거나, 혹은 Sun 인수하고 나서 좋은 유닉스 기반 CPU 생겼다고 히히덕거리고 있는건가?

아직도 현금 흐름 괜찮으면 차라리 Nvidia나 AMD(with ATI)나 인수하지 싶다. 그럼 오라클 입장에서는 정말 천군만마를 얻은 것 같을텐데..그게 좀 어려우려나? Sun 사는것보다 이 쪽이 더 이득이었을수도 있겠지 않겠어? 시너지 효과도 크고..MySQL때문에 이러지도 저러지도 못하고 겉으로 내색하진 않지만 좀 끙끙대고 있는 모습을 보자면 썬 사서 서버 시장까지 장악하는것보다 AMD나 Nvidia를 사서 CPU/GPU 라인업을 갖추고 GPU Based DB로 새로운 퍼포먼스의 세계로 들어가는게 장기적인 플랜에 더 맞지 않았을까?

하여간 DBA라면 PostgreSQL은 조금씩이라도 공부해 두는게 좋겠다. 어차피 지금도 오라클하고 경합할 거 MSSQL은 어차피 논외로 치더라도 IBM DB2 제외하면 PG밖에 없잖아?

p.s

근데 요즘 IBM이 AMD랑 굉장히 친하게 지내는데..여차하면 DB2가 오라클보다 GPU 기반 DB가 먼저 나올지도 몰라;; IBM에서 나온다면 only CUDA보다는 OpenCL일 확률이 높지만..^^

실제 적용 이후 이 글을 쓸때까지 몇달 남짓의 시간차가 있기는 합니다만, 그래도 쓸 필요는 있을 듯 해서 남깁니다.

DB서버의 경우 I/O 퍼포먼스가 거의 대부분의 이슈를 차지합니다. 덕분에 실제로는 필요하지도 않지만 어쩔 수 없이 대용량의 스토리지를 구성할 수 밖에 없는 경우도 존재하지요. 물론 저용량/고속 퍼포먼스가 이슈라면 비슷한 가격에 SSD가 대안이 될 수도 있습니다..만 SSD의 퍼포먼스 향상에 대해서 진정 신뢰할 수 있는것일까요? 그건 잘 모르겠어요. 그렇지요? :-) SSD 자체의 실데이터 안정성에 대해서도, 적어도 DB서비스를 하기 위한 SSD를 얼마나 신뢰할 수 있을것인가 역시 고려할 문제지요. SSD Raid 스토리지를 2개 이상 구성하고 멀티 전원에 UPS도 열심히 박고 등등등의 온갖짓을 하지 않는 이상 SSD의 전기적 특성에 대한 무한한 신뢰를 보내기가 아직은 쉽지 않은것이 현실입니다. 그냥 편하게 디스크 Raid 5로 잔뜩 박아버리는게 답이란 말이죠.

DB 서버를 구성하고 웹서비스를 구축하다보면 별 개떡같은 경우를 다 보게 됩니다. 물론 운좋게 좋은 개발자를 만나서 질 높은 쿼리로 구성된 웹페이지를 서비스한다면 참 행복한 일이겠습니다만, 살다보면 외주도 주고 뭣도 하고 등등등 하다보면 프로그램의 Query Cost는 갈수록 뻗어 올라가고 어떤 미친놈은 전체 DB를 수차례 조인을 걸고 인덱스는 없거나 개판이고 등등등의 문제를 발생시키곤 하지요. 어떤 미친놈은 각 웹페이지별로 접근하는 사용자를 카운트하겠다고 동접 수천이 예상되는 각각의 페이지들에 들어가는 쿼리에서 row lock을 걸어버리는 짓을 하기도 하고 뭐..(가장 최근의 외주 개발자의 삽질이슈. 아놤 그것 좀 빼버려 ㅄ아~ -_-;)

하여간 덕분에 지금 있는 J 모사에 들어오자마자 DB서버 튜닝부터 삽질을 시작한 것을 필두로 별 되도않는 쿼리들을 보고 기가 막혀서 돌아가실 것 같은 기분이 막막 들기도 하고..OTL

하여간 신세한탄은 접고, linux ext3에서의 mount option에서의 noatime 사용시와 비사용시(default : atime)의 차이에 대한 이슈.

보편적인 사용에서는 크게 신경을 안쓸지도 모릅니다만, 되도않는 쿼리로 인한 무자비한 Multi Table Join 환경이라면 분명히 도움이 됩니다. 실제로 DB서비스가 운용이 거의 불가능한 수준에서 15krpm 20EA Raid 5 스토리지 구성으로 바꿨음에도 실제 서비스에서 사용자 부하 지속 발생시 iowait이 4~50% 이상 올라가는 문제가 발생하더군요. 쿼리 튜닝이 최종 답안이고 반드시 해야하기는 합니다만 이러저러한 이유로 그것이 힘든 경우라면(비지니스 로직상의 문제일수도 있고, 단순하게 쿼리를 뜯어고친다는 개념에서 벗어나 외주 개발로 인하여 쿼리의 비지니스 로직상에서의 역할이 파악되지 않는것의 문제일수도 있고, DB 구조 자체의 문제일수도 있고..그렇죠? 전 세가지가 다 꼬여있는 상황이었습니다만;;) 다른 방안을 생각할 수 밖에 없는 상황에 봉착. 결국 특단의 조치로써 noatime을 사용하기에 이릅니다.

용도는 아시다시피 access time 기록을 하지 않는 것. process에서 접근하면서 적어도 쓸데없이 써대는 것은 막자는것이죠. access time만 기록하지 않아도 read type의 프로세싱이라면 I/O 이슈에 대해서는 충분한 효과가 있을테니까요.

결과요? 4~50% 이상의 iowait을 기록하던 시스템이 sar 기록상의 10분 평균 평균 15% 남짓, peek minute 기준으로 봐도 20% 근방에서 머무는 시스템이 되었지요. select join 타입의 퍼포먼스에 대해서는 분명한 효과가 있다고 보면 됩니다.

트랜잭션 중첩과 경합의 문제만 없다면 오라클에서의 COMMIT_WRITE 역시 바꿔볼까 생각중입니다만, 서비스 오픈 준비중인 사이트의 각 리스트 페이지별로 박혀있는 바보같은 update/row lock 거는 쿼리 하나때문에 일단 잠시 보류중입니다. redo/undo log 컨트롤만 좀 더 가능하다면 트랜잭션 부하까지도 충분히 줄어들기 때문에 지금 계획중인 DB서버 교체계획도 좀 더 뒤로 미룰 수 있지 않을까 예상하고 있습니다. 물론 예상은 예상이고 산다는 것은 예상처럼 흘러가지 않기에 인생이 다이나믹한 것이지요.

외주 개발을 못하게 막아버려야 그나마 스트레스가 줄어들지 이거 -_-;;

얼마전 동양생명이 상장을 했는데요.

삼성생명도 상장을 추진(이라고 하기엔 다소 떠밀리는듯한 인상이지만..)한다고 하네요.

네.

생보사가 증시에 뜹니다. 증시의 새로운 샛별이 되겠군요.

생보사야말로 무슨 은행이니 증권사니 이런 애들과는 비교도 되지 않는, 진정한 자본시장의 최고의 풍운아랄까요?

개인적으로 기대가 참 큽니다.

물론 차트는 보면서 해야겠지요 ^^

- 개인적으로 가치라는 측면에서 삼성생명보다는 동양생명이 더 끌리는 편이기는 합니다만 ^^ 그래도 주식이 가치대로 움직이지 않는다는 것을 감안하면 삼성생명이 대장이 되는건 기본이겠지요? 일단 생보사 중 가장 큰 회사기도 하고..일단 망하진 않을테니까요. :-) 솔직히 삼성전자가 망할지언정 삼성생명은 망하지 않을 것이라는 것은 당연지사가 아닐까 싶습니다. 혹시나 만일의 사태로 삼성그룹이 모두 무너져도 마지막까지 남을 것 역시 삼성생명이구요.