구굴에서 제시한 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

OAuth는 실제 예제로 잘 설명될 수 있습니다. OAuth 스펙에 있는 유사한이지만, 스펙에서는 HTTP 호출 문법에 초점을 맞춘 반면, 여기에서는 사용자, 컨수머, 그리고 서비스 프로바이더 의 관점에서 OAuth세션을 중심으로 설명합니다. 

볼드체는 사용자과점
색깔글씨는 OAuth 관련 뒤에서 일어나는 일들

1. Jane 은 faji.com에 사진을 2장 올린다.
 - Jane은 사용자(user), faji.com은 서비스프로바이더(service provider), 2장의 사진은 보호된 데이터(protected resource) 라는 용어를 쓴다.

2. 그년은 사진을 인쇄하기 위해서 인쇄전문 사이트인 beppa.com을 방문한다.
 - beppa.com은 컨슈머(consumer) 이다.

3. 그녀는 beppa.com에서 faji.com의 사진을 가져오기 위해서 가져오기 기능을 이용한다.
 - beppa.com과 faji.com은 OAuth를 지원하는 사이트이다.
 - beppa.com는 faji.com에게 리퀘스트 토큰을 요청한다.
 - 받은 리퀘스트 토큰과 함께 faji.com으로 리다이렉트 시킨다.
    ( 그리고 사용자가 승인시 beppa.com으로 다시 돌아오게 )

4. 그녀는 브라우저의 URL을 확인해서 faji.com 임을 확인하 후에 로그인을 한다.

5. 그녀는 로그인후 beppa.com의 사용을 승인한다.
 - 승인시 faji.com은 리퀘스트 토큰을 "사용자 승인이된" 토큰으로 업데이트 한다.

6. 브라우저는 다시 beppa.com으로 리다이렉트 된다.
 - beppa.com은 인증된 리퀘스트 토큰을 액세스 토큰(Access Token)으로 faji.com에게 요청을 해서 변경한다.
 - 액세스 토큰(Access Token)을 통해서 보호된자원에 접근하기 위해 사용한다.
   (여러번 요청가능, 사진 리스트요청 및 각각 사진가져오는 요청등등)

7. beppa.com에는 2장의 사진이 보이면서 인쇄준비 상태가 되었다. 
   그녀는 beppa.com에 faji.com의 아이디/비번을 입력하지 않고, faji.com의 사진을 인쇄할수 있게 된다.

Jackson은 json을 처리하는 3가지 방법을 제공하는데, 여기서는 간단하게 Data Binding 방법을 소개한다.



1. json 데이터를 java object로 변경하기

* json data

{
  "name" : { "first" : "Joe", "last" : "Sixpack" },
  "gender" : "MALE",
  "verified" : false,
  "userImage" : "Rm9vYmFyIQ=="
}

* User클래스

public class User {
    public enum Gender { MALE, FEMALE };

    public static class Name {
      private String _first, _last;

      public String getFirst() { return _first; }
      public String getLast() { return _last; }

      public void setFirst(String s) { _first = s; }
      public void setLast(String s) { _last = s; }
    }

    private Gender _gender;
    private Name _name;
    private boolean _isVerified;
    private byte[] _userImage;

    public Name getName() { return _name; }
    public boolean isVerified() { return _isVerified; }
    public Gender getGender() { return _gender; }
    public byte[] getUserImage() { return _userImage; }

    public void setName(Name n) { _name = n; }
    public void setVerified(boolean b) { _isVerified = b; }
    public void setGender(Gender g) { _gender = g; }
    public void setUserImage(byte[] b) { _userImage = b; }
}








 

1-1. 단순 object로 변경하기 

ObjectMapper mapper = new ObjectMapper(); // can reuse, share globally 


User user = mapper.readValue(new File("user.json"), User.class);

1-3. Gson에서는

2. java object를 json data로 변경하기 

simple 객체나 generics로된 리스트나 모두 아래와 같이 하면 된다.

스프링을 사용하여 Bean들을 자동주입하게 되면서 setter도 만들지 않게 되고,
또한 주입(Inject)할 Bean들이 많아 지만 테스트코드 만드는게 귀찮아 진다.

@Autowired에 대응해서 테스트시에는 Mockito의 방법이 있다.

1. 테스트 런너를 MockitoJUnitRunner 를 사용한다.  

2.  자동 주입받는 객체에 @InjectMock 어노테이션을 붙인다.

3.  Mock 되는 대상은 @Mock 어노테이션을 붙인다.

1. DRY - Don't Repeat Yourself : 중복을 허용치 말라. 프로그래머가 기억해야할 가장 중요한 덕목이다.
2. 추상화의 원칙 : 프로그램에서 각각의 중요한 기능은 소스코드의 한 곳에서만 구현한다.
3. KISS(Keep it simple, stupid) : 간결하게!!
4. YAGNI(You aren't going to need it) 피하기 : 필요없는 기능을 지금 추가하려 들지말라.
5. 작동 가능한 가장 간단한 형태로 만들라.
6. 코드 읽는 이를 생각하게 만들지 말라 : 읽고 이해하기 어려운 코드는 간결하게 바꾸라.
7. 개방 폐쇄(Open/Closed)의 원칙 : 모듈/클래스/함수 등은 확장에는 열려있고, 수정에는 닫혀있어야 한다. 예를들면, 클래스를 만들때 클래스 사용자가 클래스소스를 수정하게 만들지 말고, 클래스를 상속(확장)해서 쓸 수 있게 만들어라.
8. 유지보수하는 사람을 위한 코드를 만들라 : 먼 훗날 나 혹은 다른 사람이 유지보수 할 때 문제 없는 코드를 만들라. "내가 짠 코드를 내가 사는 곳이 어딘지를 아는 미친 살인마가 유지보수 할 것이라는 생각을 가지고 코딩하라"
9. 최소 놀람의 원칙 : 코드가 읽는 이를 놀라게 해서는 안된다. 표준 코딩 컨벤션을 따르고 주석과 명명이 의미 전달을 잘 해야 하며, 잠재적으로 놀래킬 수 있는 부작용을 최소화 하라.
10. 단일 책임(Single Responsibility) 원칙 : 하나의 컴포넌트는 잘 정의된 하나의 작업만 수행하게
11. 결합도(Coupling)를 낮추라 : 코드의 한 부분(코드 블럭,함수,클래스 등)은 다른 코드에 의존을 최소화해야 한다. 변수 공유를 최소화 하라.
12. 응집도(Cohesion)을 높이라 : 비슷한 기능을 하는 코드는 동일한 위치에 두라.
13. 상세한 구현은 숨기라 : 구현을 숨길수록 해당 컴포넌트를 사용하는 코드에 영향을 최소한으로 주고 수정을 할 수 있게 된다.
14. 디미터의 법칙(Law of Demeter) : 직접적 관련인 있는 코드만 호출하라.
15. 조급한 최적화를 피하라.
16. 코드를 재사용하라.
17. 관심사의 분리(Separation of Concerns ) : 서로 다른 기능들이 섞이는 것을 최소화 하라. HTML/CSS, AOP 등.
18. 변화를 포용하라 : 애자일의 원칙중에 하나이며, 위에 나온 많은 원칙들이 코드의 변화를 쉽게하기위한 것들이다.