delight412 2/27 '12 posted
『 . 하지만 앞으로 빅데이터를 처리하는 전체 시스템 아키텍쳐상 NoSQL 적용은 피할 수 없을 것입니다. 저희에게는 당장 저희에게 적합하고 성능이 매우 좋은  RDBMS 가 있습니다. 솔직히 이러한 기존 데이터베이스 시스템을 바로 교체할 만한 이유를 지금까지는 찾지 못하고 있었습니다. 』
지난해말 빅데이터 관련 포스팅으로 좋은 반응을 받았던 우승이님의 블로그에 NoSQL 관련 내용이 올라왔습니다. 어설프게 NoSQL 도입해서는 안된다는게 핵심인거 같은데, 실제로 IT현장에선 무턱대고 NoSQL 썼다가 낭패를 보는 경우가 있는 모양입니다. 우승이님의 블로그 포스팅에 대해 플랫폼전문가그룹 페이스북 페이지에 올라온 댓글에도 이같은 사례가 있더군요. 안드로이드펍을 운영하늡 박성서님이 올린 내용입니다.

"어차피 저렴한 하드웨어들로 꾸려서 먹고 사는 웹서비스 입장에서 보면 NoSQL이 MySQL 샤딩해서 쓰는것 보다 특별히 서버를 적게 먹는것 같지도 않고, 제약도 많고, 구조를 제대로 이해하고 문제없이 적용하는 것도 매우 어렵습니다. 다만 확장이 용이하고 확장에 대한 관리가 쉬워보이더라구요. SQL이라는 글자는 들어가있지만 대부분의 경우 기존 SQL을 대체하는데 적합해 보이지 않습니다. 특별히 빅데이터 처리가 필요한 경우가 아닌데도 요즘 유행이라 여기저기서 보이니까 SQL대신 한번 써보고 망하는 경우 많은거 같아요. 저희는 서비스 만드는데 NoSQL + MySQL 샤딩 같이 갑니다."

신기술 신기술하면서 제대로 검토하지 않고 도입했다가 큰일을 치르는 일은 예전부터 많았습니다. 개발자건 기업 전산실이건 마찬가지였던거같고요. 빅데이터가 관심을 끌면서 하둡이나 NoSQL을 도입하는 사례가 늘고 있는데, 철저한 대비 없이 시작부터 하고보는 사례가 종종 있는 모양입니다. 보다 냉정한 접근이 필요할것 같네요.


goodhyun 2/29 '12 answered
플랫폼 연구회의 내용 직접 큐레이션: 
Wooseung Will Kim
어제 황교수님이 준 숙제하다가 필받아서 아침부터 써내려간 포스팅, 주말은 가족과 함께.
2012/2/26 12:41 오후
주말은 아들과 라면 같이 먹는 날 2012/2/26 1:04 오후
근데... 마지막에 몇년간 꾸준히 테스트를 해보고 적용하지 않은... 교체할 이유를 찾지 못하셨다고 했는데.... 교체의 목적은 무엇인가요? 처리해야 할 데이터의 크기? 쿼리 속도? 분석에 필요한 시간? 2012/2/26 11:06 오후
쿼리속도와 돈입니다. ^^ 2012/2/26 11:14 오후
테이블 최적화와 SQL 튜닝만으로도 아직 충분한 퍼포먼스가 나온다는 얘기인거죠? 2012/2/26 11:19 오후
그게 ... 하드웨어가 무지 좋아요. ^^ 2012/2/26 11:44 오후
향후 오라클 의존성도 줄이고 하드웨어도 좀 싼걸로 대체하기 위한 중장기적인 포석정도로 생각하시면 됩니다. 2012/2/26 11:45 오후
울나라 대기업들 오라클 의존성은 반드시 낮춰야 합니다. MMM for MySQL을 잘 쓰면 적당한 분산처리도 가능할 것 같은데... 문젠 MySQL도 오라클꺼라... ㅜㅜ 2012/2/27 12:00 오전
MySQL 이 오라클에 인수된 이후 관련 커뮤니티의 핵심개발자들이 SkySQL 이라는 회사를 설립해서 사실상 MySQL 의 또다른 브랜치인 MariaDB 을 개발하고 판매, 컨설팅을 하고 있습니다. 2012/2/27 12:18 오전
다양한 NoSQL이 등장한 상황에서 이 정보가 아주 유용할 듯 하네요..그런데 NoSQL 돌리려면 상대적으로 높은 스펙의 서버가 필요한 건가요? 2012/2/27 8:39 오전
잘 읽었습니다. 행복한 한 주 만드십시오. 2012/2/27 8:57 오전
황치규 서버야 좋을 수로 좋은 거죠. 상대적인 스펙이니까요 2012/2/27 10:16 오전
어차피 저렴한 하드웨어들로 꾸려서 먹고 사는 웹서비스 입장에서 보면 NoSQL이 MySQL 샤딩해서 쓰는것 보다 특별히 서버를 적게 먹는것 같지도 않고, 제약도 많고, 구조를 제대로 이해하고 문제없이 적용하는 것도 매우 어렵습니다. 다만 확장이 용이하고 확장에 대한 관리가 쉬워보이더라구요. SQL이라는 글자는 들어가있지만 대부분의 경우 기존 SQL을 대체하는데 적합해 보이지 않습니다. 특별히 빅데이터 처리가 필요한 경우가 아닌데도 요즘 유행이라 여기저기서 보이니까 SQL대신 한번 써보고 망하는 경우 많은거 같아요. 저희는 서비스 만드는데 NoSQL + MySQL 샤딩 같이 갑니다. 2012/2/27 11:21 오전
Sungsuh Park 제가 드리고 싶었던 말씀을 딱! 해주시네요. ^^ 2012/2/27 11:41 오전
일반적 프로그래밍으로 보면 "어셈블리어를 쓰는 결단"과 흡사하다고 봐요. 감당할 수 있는지 여부라던가, 개발과정의 심리적 흐름이라던가... 2012/2/27 3:06 오후

사실, 마지막 줄은 전에도 트윗을 잠시 한 적이 있는데요. 
goodhyun
Map/Reduce와 hadoop을 볼 때마다 어셈블리어의 추억이 떠오르는 것은 어쩔 수 없다. #데자뷰
2012/2/19 11:47 오후

"미지의 한계와 조우하게 되어" 프로그램에 어셈블리어를 섞을 수 밖에 없는 일은 분명히 있습니다만, 1) 모두에게 일어나는 일은 아니고, 2) 내공과 실력을 전력 동원할 가치와 여유가 있을 때만 하는 일이겠지요. 

인덱스도 스키마도 없고, 프로그래밍 방식도 새롭기 짝이 없어, 그 동안의 데이터베이스의 상식을 재정의해야 하는 여정이 모두에게 맞을 리는 없어요. 그러나 그럴 가치와 여유를 느껴버리셨다면 가야할 수 밖에 없는거지요. :)

CouchDB
J. Chris Anderson(著)
지앤선 (2012.2)
(처음 겪어 보기로는 CouchDB가 괜찮을 듯 하기도 해요. JSON에 문서 기반...)

permanent link
goodhyun 3/17 '12 answered
『 필자가 경험한 NoSQL의 가장 큰 장점은 확장성(scale-out)이 아닐까 생각한다. 여기에 상대적으로 빠른 읽기와 쓰기 성능은 보너스이다. 대신 잃을 수 있는 것은 "개발에 필요한 우리의 시간"이다. 』

NHN에서의 실질 사례가 담긴 좋은 글을 이제 봤네요. 결론은 이상. 제 주장과 같습니다. 

Ciao.  

permanent link