Talk Lowy(kr)

듣기 버전 :  https://youtu.be/_JtfZzISH5g 역시 한국의 유투브 방송에는 NoSQL이랑 RDBMS랑 비교하면서 초심자 분들에게 NoSQL이 좋아 하는 식으로 방송하는게 많이 보이는데요, 이건 잘못하면 RDBMS는 안써도 되 라는 느낌으로 들립니다. 실제로 그런 사례도 몇 번 일어난 것을 보면 제대로 알려드려야 할 것 같아서 이 주제를 가지고 나왔습니다. 넌 뭐가 잘났는데 하시는 분들을 위해 제 자랑을 또 해드려야지요. 전 하둡으로 4000만 dau가 있는 서비스의 1.76PB 짜리를 설계 구축 해봤습니다. 카우치베이스로 32TB 데이터 올리다가 터뜨려 먹은 적도 있습니다. 몽고디비 운영중에 이건뭐지 하고 리밸런싱 커맨드 날렸다가 락걸려서 8시간 서비스 정지도 시켜봤습니다. 저를 nosql의 n자도 모른다고 하시려는 분들! 사실 전 nosql을 제대로 못써봤습니다! Nosql의 진가는 최소 일간 10억 유니크 엑세스 부터가 아닐까요? Nosql을 처음 봤을 때 그 구조에 대해 경악 했지요. NoSQL이 대단한 것은 데이터 저장 구조가 아닙니다. MySQL도 SQL Server도, ORACLE도 JSON Query를 지원하기 때문에 하나의 필드에 다 때려 넣고 표준 SQL에 JSON Query구문만 추가하면 필드처럼 인식 가능합니다. 비정형 데이터를 RDBMS가 못넣는다는 것은 이미 10년 전 이야기지요.. 많은 영상에서 하드웨어 구조 같은것은 설명을 하나도 못봤는데요.. NoSQL은 만약 100개의 노드에 데이터가 뿌려져 있다고 합시다. 그러면 Namenode에 검색용 쿼리를 날립니다. 그러면 Namenode는 100개의 노드에 동일 쿼리를 던집니다. 그리고 그 중에 해당 쿼리에 데이터가 있으면 그 데이터만 Name node에 가져옵니다. 그걸 머지해서 리턴을 해주지요. 어떤 내용이냐면, 만약 100GB의 하드를 가진 서버 100대에 NoSQL을 설치하고 데이터를 마구 넣었습니다. 동일하게 10TB의 하드디스크 한대에 RDBMS를 설치하고

누군가 요청해서 재미삼아 만들었음.. mongodb를 mysql에서 불러들이는 방법은 몇 가지가 있는데요..  1. mongodb에 mysql 모듈을 설치해서 mysql에서 호출하는 방법..   -> 설정이 많이 필요해서 귀찮음 2. mongodb에 mysql 5.7이후라면 json import를 이용해서 json으로 집어넣는 방식   -> mongodump를 이용해서 json 파일로 넣고 json_import를 이용해서 테이블에 넣으면 되기 때문에 간단한 명령으로 쉽게 정리 됨.    단점은 KVS(Key Value Store)로 저장되기 때문에 쿼리가 살짝 귀찮아짐.. 기존 쿼리를 사용할 수 없다.  SELECT doc->>"$.name" AS name FROM test.my_restaurants WHERE doc->>"$.cuisine" = "Italian"    요런 느낌으로 쿼리를 짜야 함. 3. mongodump로 json으로 떨군 뒤에 jq로 읽어서 쉘로 필드를 뽑은 뒤에 mysql커맨드로 insert처리를 함.       #!/bin/bash      # Useful date text     TodayYYYYMMDDHH24MISS= `date '+%Y%m%d%H%M%S'`     TodayYYYYMMDD= `date '+%Y%m%d'`     TomorrowYYYYMMDD= `date +%Y%m%d --date '1 day'`     YesterdayYYYYMMDD= `date +%Y%m%d --date '1 day ago'`     NextMonthYYYYMMDD= `date +%Y%m%d --date '1 month'`     PrevMonthYYYYMMDD= `date +%Y%m%d --date '1 month ago'`     delete sqldump.sql     j

얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.  이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.  2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더 2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.  4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.  물론 세세한건 보지 않았지만,  당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까? 안에서 추가로 쪼개기에는 EBS사이즈가 작으니.. 개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.  이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.  그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.  AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제) 그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.  그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는