.png "back to home page")
『 . 하지만 앞으로 빅데이터를 처리하는 전체 시스템 아키텍쳐상 NoSQL 적용은 피할 수 없을 것입니다. 저희에게는 당장 저희에게 적합하고 성능이 매우 좋은 RDBMS 가 있습니다. 솔직히 이러한 기존 데이터베이스 시스템을 바로 교체할 만한 이유를 지금까지는 찾지 못하고 있었습니다. 』
NoSQL - 도대체 어떻게 선택해야 할까? [kimws.wordpress.com]"어차피 저렴한 하드웨어들로 꾸려서 먹고 사는 웹서비스 입장에서 보면 NoSQL이 MySQL 샤딩해서 쓰는것 보다 특별히 서버를 적게 먹는것 같지도 않고, 제약도 많고, 구조를 제대로 이해하고 문제없이 적용하는 것도 매우 어렵습니다. 다만 확장이 용이하고 확장에 대한 관리가 쉬워보이더라구요. SQL이라는 글자는 들어가있지만 대부분의 경우 기존 SQL을 대체하는데 적합해 보이지 않습니다. 특별히 빅데이터 처리가 필요한 경우가 아닌데도 요즘 유행이라 여기저기서 보이니까 SQL대신 한번 써보고 망하는 경우 많은거 같아요. 저희는 서비스 만드는데 NoSQL + MySQL 샤딩 같이 갑니다."
신기술 신기술하면서 제대로 검토하지 않고 도입했다가 큰일을 치르는 일은 예전부터 많았습니다. 개발자건 기업 전산실이건 마찬가지였던거같고요. 빅데이터가 관심을 끌면서 하둡이나 NoSQL을 도입하는 사례가 늘고 있는데, 철저한 대비 없이 시작부터 하고보는 사례가 종종 있는 모양입니다. 보다 냉정한 접근이 필요할것 같네요.
goodhyun
2/29 '12
answered
플랫폼 연구회의 내용 직접 큐레이션:
어제 황교수님이 준 숙제하다가 필받아서 아침부터 써내려간 포스팅, 주말은 가족과 함께.
NoSQL – 도대체 어떻게 선택해야 할까? kimws.wordpress.com 주말은 아들과 라면 같이 먹는 날 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 오후
사실, 마지막 줄은 전에도 트윗을 잠시 한 적이 있는데요.
"미지의 한계와 조우하게 되어" 프로그램에 어셈블리어를 섞을 수 밖에 없는 일은 분명히 있습니다만, 1) 모두에게 일어나는 일은 아니고, 2) 내공과 실력을 전력 동원할 가치와 여유가 있을 때만 하는 일이겠지요.
인덱스도 스키마도 없고, 프로그래밍 방식도 새롭기 짝이 없어, 그 동안의 데이터베이스의 상식을 재정의해야 하는 여정이 모두에게 맞을 리는 없어요. 그러나 그럴 가치와 여유를 느껴버리셨다면 가야할 수 밖에 없는거지요. :)
goodhyun
3/17 '12
answered
『 필자가 경험한 NoSQL의 가장 큰 장점은 확장성(scale-out)이 아닐까 생각한다. 여기에 상대적으로 빠른 읽기와 쓰기 성능은 보너스이다. 대신 잃을 수 있는 것은 "개발에 필요한 우리의 시간"이다. 』
NHN에서의 실질 사례가 담긴 좋은 글을 이제 봤네요. 결론은 이상. 제 주장과 같습니다.
Ciao.