MapReduce on ORM

하도 공부를 안하다보니 저런 프레임웍 하나 이해하는 데에도 두번의 공부가 필요했다. MapReduce를 이해하려고 역색인을 만드는 과정을 그려봤더니 정확히 부합한다. -_- 아, 이거구나. 여기서 더 정확하거나 빠르게 계산할 수는 없겠어. -하는 마음이 드는 거 있지. 단어 세기만 봐서는 왜 이게 필요한지 안 와닿는단 말이야. 여하튼, MapReduce는 좋은 방법론이 확실하다. 그런데 이게 64MB의 데이터 블럭 단위로 이루어져 있으니 또 애매하다. 문장이 잘리는 경우는 어떻게 해요?라고 물어봐도, 문장 하나 하나가 레코드라서 다음 블럭으로 넘어간다는 걸 몰랐을 때나 물어볼법한 질문이란 말이다 -_-;.


필요성:
여하튼 MapReduce의 약점으로 많이들 지적되는 것이, MapReduce는 매우 낮은 레벨의 자료열만 다룬다는 것이다. 첫째로, 우리가 일반적으로 사용하는 오라클, MySQL처럼 RDBMS와 같이 풍부한 관계를 제공하지 않는다. 둘째로 JDBC 인터페이스는 분산 처리에 그다지 적합하지 않다. 마지막으로 RDBMS를 사용하면 공통적으로 겪는 문제인 객체화가 쉽지 않다. ORM을 써야지 쓰기가 쉽다.


구현의 어려움:
첫째로, MapReduce용 Database는 아주 구현하기가 어렵다. 스키마, B+ Tree로 이뤄진 색인열, 레코드셋을 저장하는 자료 구조가 필요하다. 스키마와 색인은 철저하게 락으로 트랜잭션에서 보호되어야 하고 레코드셋은 부분적으로 보호될 수 있어야 한다. 그러면서도 분산 파일 시스템을 최대한 활용할 수 있어야 한다. 그리고 각 레코드는 그 자료를 실제로 소유하고 있는 컴퓨터가 직접 접근할 때 최대의 효율을 낼 수 있어야 한다. 이런 자료 동기화와 배분 문제를 그리 쉽게 해결할 수는 없을 것 같다.

특히, index, join은 거의 불가능하다. 관련된 프로젝트인 HBase 마저도 그런 기능들은 포기하고 다른 기능들로 채워넣었다. index와 join이 정말 필요한지, 다른 방법으로 우회할 수 있을지는 살펴볼만한 문제다.

둘째로, JDBC의 한계는 어쩔 수 없다. 어느 자료가 어느 컴퓨터에 있을 때에, 그 컴퓨터에게 그 자료를 갖고 처리하도록 명령을 내리는 것이 MapReduce을 비롯한 연산 모델들의 핵심이다. JDBC는 어디에 결과가 있는지 알리는 인터페이스를 제공하지 않는다. 원래 그런 요구가 없었으니까. 비표준 데이터베이스 연결 방법을 쓸 수 밖에 없다고 본다.

셋째로, 현존 ORM들은 적용 불가능하다. 둘째 부분에서 문제를 해결했다손 치더라도 현존 ORM들은 마찬가지로 분산 처리를 지원하지 않는다. 따라서 뜯어 고치던가 아니면 새로운 인터페이스를 정의해야 한다. 더욱이 ORM의 캐쉬 등은 자료 동기화 문제를 일으킬 여지가 더욱 크다. 이 정도 되면 새로운 ORM을 작성하는 편이 나을 정도다.


소결론:
대략적으로 살펴봤는데, 현존 솔루션으로 이런 요구사항을 만족시킬 수 있을지 모든 면에서 의문스럽다. 이 모든 난관을 극복하면 자료 처리가 훨씬 더 쉬워질까? 나는 그렇다고 생각한다. 그러기에 조금 더 살펴볼만한 가치가 있지 않을까.