구굴에서 제시한 C++ 코딩 가이드

한글버전 :

http://aronze.com/wiki/index.php?title=Google_C%2B%2B_Style_Guide

영문 원본 :

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

사내에 C++ 코딩 가이드가 없다면, 이것을 그대로 사용해도 될듯..

더 많은 정보를 원한다면 여길르 방문..

http://code.google.com/p/google-styleguide/

일정

작성자 : hanburn

작성일 : 2012-01-17

1. 샤딩 ( sharding ) 이란 무엇인가?

2. 샤딩 및 전략

 2.1 vertical partitioning

 2.2 Range Based Partitioning

 2.3 Key or Hash Based Partitioning

 2.4 Directory Based Partitioning

3. 샤딩 적용시 고려사항

1. 샤딩 ( sharding ) 이란 무엇인가?

관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝하는 기술이다. 파티셔닝은 DBMS에서 지원하기도 하는데, 일부 DBMS ( MySQL 5.1 미만에서는 지원 안함) 에서는 지원안하기도 한다. 샤딩은 DBMS 레벨에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 분할하는 방식이다. 따라서 어플리레이션 레벨에서 구현해야 한다.

간단하게 예를 들면, 전 세계의 고객 데이터를 저장하는 대형 데이터베이스를 분산한다고 할때, 미국 고객의 경우는 샤드A, 아시아 고객의 경우는 샤드B, 유럽 고객의 경우는 샤드C로 분할해서 저장할수 있다.  

2. 샤딩 및 전략

샤딩에서 데이터베이스를 분할하는 방법에 대해서 살펴본다. 각 방법마다 장단점과 주의할 점이 있으므로 서비스에 맞게 적절하게 선택하거나 조합하여 사용 한다.

2.1 Vertical Partitioning

    테이블 별로 서버를 분할하는 방식이다. 예를들면 사용자 프로필정보용 서버, 사용자 친구리스트용 서버, 사용자가 만든 컨텐츠( 사진같은것 ) 용 서버등으로 분할하는 방식이다.

    장점 : 구현이 간단하고, 전체 시스템에 큰변화가 필요 없다.

    단점 : 각 서버의 데이터가 점점 거대해지면 추가 샤딩이 필요해진다. ( 1천만명이 1000장의 사진을 생성한다면 컨텐츠 서버에 또 샤딩이 필요할 것이다. )

  2.2 Range Based Partitioning

    하나의 feature(또는 table)가 점점 거대해지는 경우 서버를 분리하는 방식이다. 예를들면 사용자가 많은경우 사용자의 지역정보를 이용해서 user 별로 서버를 분리하거나, 일정데이터라면 년도별로 분리, 거래정보라면 우편번호를 이용하는 방식이다.

    주의점 : 데이터를 분할하는 방법이 예측가능해야 한다.

  2.3 Key or Hash Based Partitioning

    이방식은 웹2.0 사이트에서 기본 파티셔닝 방식으로 알려져있다. 엔티티를 해쉬함수에 넣어서 나오는 값을 이용해서 서버를 정하는 방식이다. 사용자ID가 숫자일 경우 나머지연산( module operation)을 이용하는 방법이다.

    주의점 : 해쉬결과 데이터가 균등하게 분포되도록 해쉬함수를 정하는게 중요하다.

    단점 : 서버의 수를 늘리기 위해서 해쉬함수를 변경하는 작업이 무지무지 비싼 작업이다.

  2.4 Directory Based Partitioning

    파티셔닝 메커니즘을 제공하는 추상화된 서비스를 만드는 것이다.(데이터베이스 액세스 코드와는 떨어져 있는)  샤드키를 look-up 할수 있으면 되므로, 구현은 DB와 cach를 적절히 조합해서 만들수 있다.

3. 샤딩 적용시 문제점들 및 고려사항

 3.1 데이터 재분배 ( Rebalancing data )

  Sharding된 DB의 물리적인 용량한계나 성능한계에 다르면 shard의 수를 늘리는 scale-up 작업이 필요하다. 서비스 정지 없이 scale-up 할수 있도록 설계방향을 잡아야 한다.

 3.2 샤딩으로부터 데이터 조인하기 ( Joining data from multiple shards )

   Sharding-db 간에 조인이 불가능 하기에 처음부터 역정규화를 어느정도 감수해야 한다. Shard의 목정이 대용량 데이터 처리이므로, 대용량처리시 수행성능을 위해서 데이터 중복은 trade-off 관계 임을 이미 알고 있다.

 3.3 샤드에 데이터를 파티션하는 방법 ( How do you partition your data in shards? )

  shard 해쉬함수를 잘 설계해야 한다.

 3.4 샤드간의 트랜잭션 문제

  Global Transaction을 사용하면 shard DB간의 트랜잭션도 가능하다. 그 유명한 XA인데, 성능저하의 문제가 있다.

 3.5 Global Unique Key

  DBMS 에서 제공하는 auto-increament를 사용하면 key가 중복될수 있기 때문에, application 레벨에서 Key 생성을 담당해야 한다.

 3.6 데이터는 작게

  Table의 단위를 가능한 작게 만들어야 한다.

참고

http://www.ibm.com/developerworks/kr/library/j-javadev2-11/

http://highscalability.com/unorthodox-approach-database-design-coming-shard

http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSchemes.aspx

K팝스타 오디션중 백아현, 이미쉘, 나머지하나는 누군지 기억이..

3명이서 배틀을 벌이고 심사평이 나옵니다.

박진영 :

"*프로의 자질 중 하나는 철저한 자기관리이다. 목 상태가 안좋으면 무조건 말을 하지 말았어야 했다. 심지어는 인사할때도 말을 아껴야

했다. 자기관리에 실패했다면 프로로서 실격이다.*"

양현석 : 박진영의 의견에 공감한다.

보아 : “실망을 많이 했다”면서 “녹음실에서 봤을 때가 일주일 전이다. 그 때도 목이 안 좋았다. 근데 이미쉘이 녹음실에서 떠드는 모습을 보고 걱정이 됐다…자기 관리도 실력이다

여기서 대부분의 사람들은 심사평에 공감을 하고, 프로페셔널이란 이런거다 라고 생각하기도 한다. ( http://groups.google.com/group/ksug/browse_thread/thread/5c061ff6863df5bd )

다른 방향에서 생각해보면,

이미쉘을 캐스팅해서 트레이닝을 담당한 SM과 보아는 무엇을 한 것일까?

1주일 전에 이미 목상태가 않좋은것을 알았으면, 미리 주의를 주고 보호장치를 했어야 하는게 아닌가라는 생각이 든다. 가수로써 미쉘이 프로페셔널 부족이었다면, 소속사와 트레이너로써 SM과 보아도 마찬가지로 프로페셔널 부족인 것이다.

혹시, 내막은 보아가 어떤 주의와 방향을 제시했는데 이미쉘양이 정말로 목 관리를 안해서 방송에서 직접적으로 깐걸지도..