Offcanvas

빅데이터 | 애널리틱스 / 애플리케이션

글로벌 칼럼 | 오라클 RDBMS로는 안되는 10가지 작업

2012.11.19 Andrew C. Oliver   |  InfoWorld
필자는 NoSQL 쪽을 맡고 있고 빅 데이터 전문가이기도 하다. 당신도 들어봤겠지만 현재와 같이 데이터 성장세가 뚜렷한 상황에서 이 둘은 완벽한 조합이다. 물론 오래된 습관을 없애기는 쉽지 않다. 관계형 DBMS는 여전히 시장 지배자다. 하지만 당신이 골수 오라클 팬이고 구식 RAC용 PL/SQL을 즐기고 있다면 다음 작업들을 수행하는데 있어서 당신이 사랑하는 기술을 사용하기 전에 다시 한 번 아니 여러 번 생각해보라.
 
1. 검색
가장 오라클을 잘 활용한다는 기업들도 오라클 데이터베이스 확장 기능인 오라클 텍스트(Oracle Text)를 사용하지 않고 있고 활발히 개발하는 것도 아니다. 대신 대부분 수작업으로 처리해야 하는 복잡한 쿼리를 사용한다. 그 결과는 긍정적이지 못하고 기능성도 떨어진다. 오라클이 필요로하는 방식으로 데이터를 얻는 절차도 쉽지 않다. 그나마 오라클을 제외한 다른 많은 RDBMS 제품들은 진정한 의미의 검색 확장기능 조차도 없다.
 
대안은 동면 검색(Hibernate Search), 아파치 솔(Apache Solr), 혹은 오토노미(Autonomy) 등을 사용하는 것이다. 이들은 인덱스와 풀 텍스트 검색 등에 더 적합하다.
 
2. 추천
오라클 ATG 웹 커머스(ATG Commerce)의 '추천'(Recommendations) 기능은 필자가 그동안 다뤄본 커머스 제품들 중 최악이다. 이들은 추천 기능을 구현하기 위해 이용자로부터 막대한 데이터를 수집한다. 필자가 작업했을 때는 확장성 때문에 추천 능력을 거의 항상 꺼두었다.
 
예를 들어 소셜 네트워크에서 당신의 친구나 그 친구의 친구가 양말을 샀고 필자가 그 양말을 당신에게 추천하고 싶은 경우 RDBMS에서 이를 구현하는 것은 아주 골치 아프다. 이것은 자체 결합된 테이블과 다단계 쿼리에 대한 것으로 마치 네오4j(Neo4j)같은 그래프 데이터베이스 내의 코드 두줄과 흡사하다. 소셜 네트워크를 미리 평탄화(pre-flattening)하고 복잡한 데이터 조작을 통해 RDBMS를 회피할 수도 있지만 그러면 실시간 속성을 잃어버리게 된다.
 
3 고-빈도 트레이딩
데이터는 일정 정도 상호적이기 때문에 트레이딩 시스템에는 RDBMS가 적합할 것으로 생각하는 것이 일반적이다. 그러나 실제로는 그렇지 않다. 거래가 자주 일어나는 고-빈도 트레이딩(HFT) 시스템 초기에만 RDMS가 사용됐고 일부 경우에는 NoSQL 접근방식이 적용됐다. HFT에서 무엇보다 중요한 것은 지연시간을 줄이는 것이다. 물론 여러 복잡한 단계들을 거치면 RDBMS로도 낮은 지연시간을 달성할 수 있지만 애초에 목적이 다른 것이다.
 
오라클은 인-메모리 데이터베이스와 RDBMS를 결합하려 시도한 타임스텐(TimesTen)을 인수해 그 해답을 찾으려고 했지만 거위를 트럭에 매단다고 해서 비행기가 될 리는 없지 않은가. HFT에 리악(Riak) 같은 키-값 스토어나, 젬파이어(Gemfire) 같은 더 복잡한 솔루션을 사용하는 것도 이 때문이다.
 
4. 제품 카탈로그하기
이것은 흥미로운 것은 아니지만 필자가 제품 데이터 매핑을 위해 썼던 최초의 SQL 쿼리 악몽들 중 하나다. 휴대폰 업체 프로젝트였는데 '모델 XYZ'가 몇 가지 각기 다른 전화기를 의미하고 각기 다른 시장에 다른 이름으로 출시되었다는 점만 빼면 같은 휴대폰이었다. 심지어 같은 모델이 완전히 다른 부품들로 구성되어 있기도 했는데 이런 기기들의 '클래스'를 관리하는 것이 제대로 이뤄지지는 않았다. 필자가 네오4j같은 그래프 데이터베이스를 통해 난관을 극복할 수 있었다.
 
화학업체에서 프로젝트를 진행할 때도 거의 비슷한 문제에 부딪혔다. 손이 아주 많이 가는 바보같은 스트링 매핑(string mapping)을 했다. 제품 정보를 그래프 데이터베이스로 보관했더라면 매핑하기 훨씬 간단했을 것이다. 카우치베이스 2.0(CouchBase 2.0)이나 몽고DB(MongoDB)같은 문서 데이터베이스들만 썼더라도 그 당시 방식보다는 나았을 것이다.
 
5. 이용자/그룹 그리고 ACL
사실 LDAP는 원조 NoSQL 데이터베이스였다. LDAP은 이용자, 그룹, ACL들을 위해 설계됐고 문제에 꼭 들어맞기도 했다. 그러나 안타깝게도 기술이 새로워지고 회사가 끔찍하고 엉망인 짓들을 벌이면서 많은 사람들이 LDAP에 염증을 느끼게 됐다. 몇몇 회사들은 많은 개발자들이 데이터베이스 테이블을 만드는 편법을 쓰지 않을 수 없게 심각한 관료제 문제에 빠져들었다. 그만큼 중앙화된 이용자 접속 제어는 힘들어졌다. '이용자'와 '역할' 테이블들은 모든 기업 환경에서 사라져야 한다.
 
6. 로그 분석
단적인 사례를 경험하고 싶다면 서버 클러스터용 하둡(Hadoop)이나 RHQ/JBossON의 로그 분석 기능을 활성화하라. 오류를 제외한 모든 것들에 로그 레벨과 로그 캡쳐를 맞춰라. 조금만 더 복잡한 것을 설정하면 인생이 아주 피곤해질 것이다. 이런 유형의 비구조적 데이터 분석이 바로 맵리듀스(MapReduce), 하둡, 그리고 PIG같은 언어들이 존재하는 이유다. 주요 모니터링 툴들이 RDBMS 특화됐다는 점은 안타까운 점이다. 트랜잭션은 그리 필요치 않은데 지연시간을 줄이는 것이 중요하기 때문이다.
 
7. 미디어 저장소
메타데이터를 저장하는 것은 괜찮지만(비록 카우치베이스 2.0이나 콩고DB같은 문서 데이터베이스가 낫겠지만) RDBMS 속 BLOB들은 지금까지도 여전히 힘들다. 차라리 이미지와 다른 것들을 일종의 분산 스토리지나 클러스터된 파일 시스템에서 사용하는 것이 나을 것이다. 안타깝게도 많은 CMS 엔진들은 여전히 모든 것들을 RDBMS에 밀어넣고 있다.
 
8. 이메일
사실 다른 사람들은 다 알고 있었다. 필자는 이메일과 RDBMS를 통합하는 프로젝트를 경험한 후에야 다른 이들이 이미 알던 사실을 깨달았다. 이메일은 적당히 비구조화된 데이터와 메타데이터의 혼합 방식으로 저장되는 편이 명백하게 낫다. 필자는 가능한 한 RDBMS를 최대한 최적화시켰고 BLOB에도 정신나간 짓들, 아니 그 이상을 했다. 궁극적으로 이메일은 메타데이터, 검색, 컨텐츠에 관한 것이고 이들 중 무엇 하나도 관계적 대수에 적합하지 않으며 여기선 트랜잭센도 정말 필요없다. 문서 데이터베이스에선 파일시스템도 좋지만 메타데이터가 더 나을 것이다.
 
9. 생활 광고
많은 이용자들이 접근하고 대부분 짧고 간단한 컨텐츠다. 몽고DB를 문서 데이터베이스로 이용하는 크랙스리스트(Craigslist)에 문의해보라. 검색, 메타데이터, 간략한 컨텐츠가 있다면 일관성은 충분하다. 이런 유형의 문서에서 데이터베이스가 할 수 있는 최선은 아예 사용하지 않는 것이다.
 
10. 시계열/예측
이것은 10가지 예시 중에서도 가장 일반적이지만 많은 상품에서부터 퀀츠(quants)까지 그리고 태양 흑점에서부터 날씨까지 여러 형태가 있다. 관계 데이터베이스안에서 시간과 관련된 문제들은 가히 전설적이다. 물론 수 년에 걸친 해킹을 거쳐 가능해졌고 지난 10년 가량 우리는 대부분의 RDBMS 시행에 있어서 말도 안될 정도로 실격 수준은 아닌 그저 어느 정도 부족한 현시적인 영역과 기능들을 사용할 수 있었다. 그래서 만약 시간이 문제라면 맵리듀스-친화적인인 카산드라(Cassandra)같은 컬럼 계열 스토리지(column family store)가 더 나은 솔루션이 될 수 있다. 데이터스택스(Datastax)는 다른 업체들이 그렇듯 카산드라에서 시계열 데이터 처리를 지원하기 위해 노력하고 있다.
 
당신은 앞서 언급한 일부, 혹은 대부분의 경우에 RDBMS를 사용할 수 있는가. 물론 필자도 경험이 있고 사람들은 여전히 사용하고 있다. 그러나 이게 제대로 맞게 사용하는 것일까. 그렇지 않다. 보수적이고 꼬장꼬장한 노인들은 동의하지 않겠지만 전통 그 자체가 일을 처리하는데 전통 방식을 사용하는 타당한 이유가 될 수는 없다. editor@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.