몽고 카우치
간만에 기술 관련 글 하나. (예전에도 이거로 고민한 적이 있다)
CouchDB와 MongoDB중에서 몽고를 선택한 이유는
- 몽고가 워낙 빠르고 ( 카우치도 빨라졌다고는 하지만 첫인상이 중요 ...)
- 카우치쪽의 view 어찌구보다는 몽고쪽이 익숙하다
는 점 때문.
몽고를 레일스3와 함께 실무에 적용하면서 첫번째로 걸렸던 것은 파일업로드용 젬인 paperclip 이나 아이폰 메시지 푸시용 젬인 apns 따위를 돌아가게 하기위해서는 소소한 코딩을 해줘야 한다는 점이었다. 이건 견딜만 했다. 새로운 기술을 도입하기 위해서 이런 저런 수선을 하는건 약간은 재미있으니까.
두번째 걸림돌은 로그용 테이블이었다. 사용자가 어떤 글을 읽으면 “글번호+사용자아이디+일시” 를 저장해두고 싶었다. 이게 나중에 나름 쓸모가 있는데, mysql 에서는 archive 타입으로 테이블을 생성하면 별 문제없이 저장하고, 활용할 수 있다. 하지만, 몽고디비는 빠른 응답을 위해 모든 데이터를 메모리에 올려둔다. 따라서… 당장은 활용할 일이 없는 데이터도 모두 메모리에 올라가있게된다. 사이트를 오픈하고 하루에 5000분이 찾아주신 사건이 있었는데, 메모리를 채워버리는 바람에 3일치만 저장하고 이전은 날리도록 수정해야 했다.
세번째 걸림돌은… 필드이름이 각각의 레코드에 반복적으로 저장된다는 점이다. 이건 잘알려진 사항이고, 잘 대처한다고 생각하면서 코딩을 했지만, 하다보면 target_id 라던가, statement, address 따위를 tid, stmt, addr 따위로 줄여서 쓰거나, 심지어는 그마저도 줄여서 써놓고는 원래 무슨 변수였더라… 노려보게 된다. (책상위는 절대 정리하지 않으면서도, tid 를 t로 stmt를 s로 addr을 a로 줄여놓게되는 일종의 병이 있다.)
이상이 코딩 중간중간 귀찮아지는 점들.
따라서,
한동안 다시 mysql+ xxx 로 돌아가려하는데.. 그 이유는
- 응답속도만을 놓고보면, 몽고가 정말 만족스럽다. 하지만 mysql + memcached로 비슷하게 만들수있다. 그리고, 이렇게 하면 메모리는 아끼고, 나머지는 하드로 내려간다.
- 스키마없음(schema-less)은 실제 써보고 나니까, 정말 좋은건지 잘 모르겠다. 스키마를 마음대로 바꿀수 있다는 거는 참 좋은 일이긴 한데... (초기에 프로토타이핑할 때는 확실히 편했다. 하지만 그 후에는? ) 레일스에서 migration을 쓰는 쪽도 가끔 귀찮은 일이 생기곤 하지만, 그렇다고 스키마없는 디비가 정말 좋았어요, 라는 말 까지는 나오지 않는다.
- 맵리듀스라는 녀석은, 굳이 써보고 싶은 마음에 태그의 갯수를 세는 map, reduce함수들을 만들었는데, 음... 장난치는 것 같다. 이게 필요할 정도로 서비스가 대박나지도 않았고...
이상, 아직 몽고디비를 실무에 적용하기에는 딸려보인다는 결론.
이후에는, mysql+xxx 에서 xxx를 무엇으로 할까하는건데.
기존처럼 memcached로 갈것인지(안정적이고 빨랐다. 여기에 mongo를 넣어도 ..)
redis같은 녀석을 써서 rpush/rpop으로 소셜 비스무리한 기능이라도 넣어볼까
아니면 membase (이게 언제쯤 couchbase랑 합쳐질지는 모르겠지만… 그럼 그냥 memcached잖아? 암튼)로 가볼까.
하는 정도.
P.S. 한번 NoSQL에 들어갔으니, GraphDB에도 함빠져볼까 싶어서 Neo4J 도 한참 노려봤는데.. .. 일단 밥벌이 코딩부터 !
P.P.S 11년동안 쌓인 여행후기들이 SQL문장으로 백업했을때.. 1.5G정도다. 몽고가 아무리 낭비벽이 있다고 해도.. 어쩌면 거의 문제가 안될 수도 있다.. http://www.linode.com/에서 메모리 4G짜리 가상머신이 한달에 15만원이니까…