MySQL 이 오라클 손에 넘어가고 부터 걱정한 사람들이 많았는데 MySQL 을 개발했던 담당자들도 걱정이 많았나 봅니다. MySQL 이 5.5.30 부터 변화가 없던 것을 우려해서 만들었다고 하는데요. (결국 그 우려는 현실로 드러났지요 http://goo.gl/a7AOs )

그것은 바로 마리아디비  (https://mariadb.org/ )입니다.  MySQL 하고 현재 100% 호환이라고 합니다. 즉 MySQL 서버대신 마리아디비로 바꿔버려도 그대로 동작한다고 합니다. (심지어 인스토 파일 이름도 install_mysql 어쩌구 입니다 ㅎㅎ) 

오라클이 하는 짓이 짜증나신다면 한번쯤 생각해볼만한 대안이라고 볼 수 있습니다.
 
저번에 살짝 언급했던 일을 처리중입니다. ( 요기에서 언급함 ) 뭐 우리가 무슨 힘이 있겠습니까? 해달라면 해줄 뿐이지 ㅎㅎ 

바꾸면서 나도 무슨 테이블인지, 무슨 컬럼인지 자세히 봐야지만 알 수가 있는 네이밍 컨벤션이더군요.. 투덜 투덜..

아 이제 그만 투덜되고!! 그렇다고 많지도 않지만 또 어찌보면 많은 부분을 다 찾아주기가 귀찮더군요. 그래서 어떻게 하면 편하게 바꿀 수 있을까를 고민했습니다. 

'훌륭한 해커는 게을러 지기 위해서 프로그래밍을 한다!!' 라는 멋진 사상과 부합되간다면 저도 훌륭하지는 않지만 해커의 길로 나선 것이라고 볼 수가 있습니다.  더구나 제가 쓰는 텍스트 에디터가 바로 이맥스 아닙니까? 바로 개발 들어갔습니다. 



바껴야 될 쿼리 부분을 리젼으로 지전하고 change-table 함수를 호출해 주면 변환은 끝입니다.

 
최근에 자기 기업 스타일과 다른 디비 설계 컨벤션을 썼다고 설계 품질이 낮다고 지적하면서 이걸 전체 회신으로 보내는 엽기 행각을 당했다. (디비 테이블명을 명사 복수형으로 쓰는게 그렇게 이상한가? -ㅅ- person / people , user / users  등등) 

대체 설계품질을 뭐로 따지는 건가? 디비 컬럼명을 대문자로 안 썼다고? 어트리뷰트가 컬럼명으로 전환이 안된다고?

심지어 모델 케이스 툴을 안쓰냐고 (거의 ㅉㅉ 가 뒤에 붙어있는지 음성 지원 효과도 되는 듯한..) 원하면 교육시켜준다는 소리까지..

그거 다 알거든요? 몇년전에 쓰다가 그냥 대충 만들어도 되길래 안 쓰는거거든요?

완전 느낌이  "C/C++ 코딩할 때 헝가리안 표기법 안쓰니까 당신 초급 개발자네요 열심히 노력하세요.." 라는 지적을 당한 기분!! 그르르르릉!! 
바야흐로 폭발적인 데이터의 시대가 왔습니다. 저번 포스트 에서도 언급을 했지만 RDBMS 와 다르게 확장을 주요 특징으로 하는 것이 NoSQL 입니다. 즉 '분산' 으로 그 폭발적인 데이터들을 전부 수용이 가능합니다.

이러한 NoSQL 중에서 CouchDB 를 잠시 살펴보기로 하겠습니다.

http://couchdb.apache.org/

위 링크에서 대략적인 것을 살펴 볼 수가 있습니다. CouchDB 의 가장 큰 특징은 (절대적으로 제 관점입니다)

Subversion 같은 파일 레파지토리 시스템 (File Repository System)을 분산 DB 형태로 바꾸어 놓은 것이라고 할 수 있습니다

세세한 몇가지 특성을 살펴보기로 하겠습니다.

1. Erlang 이란 언어로 쓰여짐
 
가장 빠른 속도를 자랑한다는 소리만 많이 들었습니다만 아직 써보지는 않았습니다. 컴퓨터 언어세계에서 몇개국어 이상을 하다 보니 더 이상 언어 배우는게 힘들더군요. (게임할 시간도 부족.. 쿨럭)

2. DB 속성중 일관성 (Consistency) 가 강화 됐다.
 
저번 포스트 에서 언급 했던 CAP 이론중에서 CP 쪽 특성을 가지고 있는 것이라고 볼 수 있습니다.

3. 사용하기 쉽다
 
몽고디비 (MongoDB) 같은 계열의 특징입니다. 가장 주요하게 설치될때 웹서버도 같이 설치되고 클라이언트랑 HTTP로 통신하고 데이터를 Json 방식으로 주고 받습니다. 당연히 사용하기 쉽겠지요?

4. 양방향 복제 (Bi-Directional Replication)
 
생물학에서 나온 용어 입니다. 초기 세포분열이 시작될때 한 시점을 바탕으로 해서 양쪽으로 똑같이 복제 되가는 형태를 말합니다. 여기서는 데이타가 초기에 디비에 저장될 때, 똑같이 양쪽으로 복제가 일어나는 것을 말하나 봅니다.

5. Document - Based 방식

데이타를 문서 형태로 저장합니다. 초장에 설명 드릴 때 SVN (Subversion) 방식의 디비화 라는 설명을 드렸습니다.

6. RESTful HTTP API 를 지원한다.
 
3번하고 연결되는 내용이기도 합니다만, 성격이 조금 다르지요. 말 그대로 API 형태로 RESTful 방식을 지원합니다.

7. 읽고 쓸 때 락 (Lock)이 없다.
 
보통의 디비랑 다른 점이라고 할 수 있지만, SVN 시스템을 써보셨다면 이해하실 것입니다. 락은 없지만 Conflict 는 생길 수가 있다는 점이 특징입니다. 따라서 마치 SVN 처럼 Conflict 가 생겼다면 변경된 내용이 추가되서 변경할 수 있게 합니다.

8. Crash-Only 설계가 적용되었다.
 
데이터 파일이 항상 무결한 상태에 있음을 보장하기 위해서 캐쉬에 일부 저장했다가 커밋시 커밋된 데이터나 관련된 자료구조를 덮어 쓰지 않는다고 합니다. 개별적인 특징으로 시스템이 돌아가던 서버가 갑자기 꺼진다고 해도 데이터는 무결한 상태가 유지되는 것입니다. 즉 일반적으로 셨다운 (Shutdown)이 없다고 합니다.

9. MVCC (Multi-Version Concurrency Control) 지원
 
이것이야 말로 가장 SVN 같은 시스템과 비슷한 기능입니다. 여러 클라이언트가 동일한 문서를 보고 있다고 해도 그 동일한 문서가 같은 버젼일 수가 없습니다. 즉 어려운 말로 하자면 읽기의 시작부터 끝까지 일관된 스냅샷 (Snap Shot)을 보게 됩니다.

10. 인덱스 업데이트가 언제나 파일 끝에서만 발생하도록 설계됨

11. 컴팩트(Compact) 를 시켜줘야 한다.
 
 데이터 파일을 저장하는 단위는 일정 크기 (MongoDB 는 16메가)로 늘어나게 되어 있는데 , 이 파일의 크기가 한 없이 늘어나는게 아니라 어느 정도 데이터의 가감이 일어나면 크기를 다시 일정한 크기로 줄여줘서 유지하는 방식을 말합니다.

12. _changes 를 이용한 실시간 갱신

사용자가 보고 있는 문서(Document)가 변경 됐으면 _changes 메시지가 클라이언트측에 도착합니다. 그래서 실시간으로 갱신이 되거나, 편집중이였으면 Conflict 가 발생합니다.

13. JQuery Library 가 포함되어 있다.
 
Javascript 형식의 Map/Reduce 도 지원하는데 이러한 것이 가능한 이유가 독립적으로 JQuery Library 가 포함되어 있기 때문입니다.

14. 활용 되는 곳
 
누적 데이터나, 데이터가 전반적으로 바뀌는 변화가 별로 없는 곳, 실행될 질의가 미리 정의되어 있는 곳 , 데이터들의 버젼 관리가 중요한 곳 (마치 Subversion 을 디비화 시킨것 처럼) 보통 CRM (Customer Relationship Management) 나 CMS (Conversational Monitor System) 같은 곳에서 쓰이기 좋습니다.




+ Recent posts