InnoDB 써도 괜찮나요..

굳이 사족을 달자면...

innodb는 돈을 지불하지 않는 선에서는 너무나 훌륭한

솔루션입니다.

그런데, 제가 DB개발업계에 있다보니 내부를 분석해 보았는데..

인덱스 처리에 잠재적인 문제가 있습니다.

대규모 상용 DBMS에서는 인덱스 처리스에 Node Level Latching 기법을

이용해서 update와 select가 하나의 인덱스 내부에서

parallel하게 동작합니다.

그러나, innodb의 경우 Tree Latch라고 해서 modify연산과

read 연산이 동시에 수행될 수 없는게 문제더군요.

일반적인 상황에서는 크게 느껴지지 않지만,

만일 select되는 대상 데이터 집합이 커서 버퍼 매니저에서

fix & unfix가 대량으로 발생할 경우에는

최악의 경우 100배 이상 느려질 수 있습니다.

그래서, 보통 이런 innodb의 경우에 buffer hit ratio를 거의 100%에 가깝게

튜닝하셔야 나중에 당황하지 않으실 겁니다.

아..그리고, 다른 문제점을 또하나 든다면,

기본적으로 지원되는 Isolation level에 Repeatable read인데

구현방식이 약간 다름으로 인해 select와 update가 동시에 발생할 경우에

때때로 consistent error가 발생할 수 있습니다.

물론 오라클은 이런 문제가 없습니다.

그래서 innodb의 클라이언트 개발할 때는 의도하지 않는

rollback에 대해 처리를 하고, 재시도하도록 하는 루틴이

추가되어야 하지 않을까 하는 생각을 합니다.

흑...마지막으로

innodb는 MVCC기법(오라클과 유사)인데,

busy한 select와 update 트랜잭션이 발생할 경우

구조적으로 성능이 과도하게 낮아질 위험성이 있습니다.

이것은 학문적으로 이야기하면 old view에 대한 처리 때문인데

innodb의 경우 읽을 대상 tuple이 old view인지 아닌지

판별하기 위해 매 커서 open시에 모든 트랜잭션의 모든 커서에 대해

방문을 해서 view 정보를 가져오기 때문에 성능이 급격하게

떨어질 위험성이 있습니다. 물론 몇백개의 트랜잭션이 동시에

수행될 때를 가정하는 것입니다.

-------------------------------------------

innodb의 단점만을 이야기 한 것 같은데,

이런 문제점을 알고 쓰는 것과 모르고 쓰는 것은 차이가 있기 때문에

혹시 도움이 될까 해서 올렸습니다.

개인적인 관점에서는

innodb의 스토리지 매니저 부분을 한 개인이 전담해서 개발했기 때문에

필연적으로 쉬운 방법을 택한게 아닌가 하는 생각입니다.

어떤 두뇌집단이 다시 쓴다면 더 좋은 제품이 될 것 같고,

현존하는 오픈 소프트웨어 DBMS 중에서는 가장 실용적인 것

같습니다.

건승하십시요.

김성진 드림