1 Jeremy Cole , a DBA Team Lead/Database Architect at Twitter, gave a really good talk at the O'Reilly MySQL conference: Big and Small Data at @Twitte..
2 Twitter values stability over features so they've stayed with older releases.
3 Vertica is being used for analytics and large aggregations and joins so they don't have to write MapReduce jobs.

제레미 콜 이라는 트위터 DBA 팀 리더가 MySQL 컨퍼런스에서 발표한 내용.

그거말한것중 재밌는 것:
트윗을 저장하는 옛날 방식(temporally sharding)에서
좀더 분석적인 접근으로 새로운 트윗을 저장하는 방식(T-bird라고 불리는 방식)
으로 전환하는 이야기.

(1) 트윗을 저장하는 예전 방식. (temporally sharding)
temporally sharding은 단순하게 같은 시간 범위의 트윗은 같은 샤드에 함께 저장된다는 것이다.
한 서버가 꽉차면, 두번째 서버에 저장하고, 꽉 차면 세번째 서버에 저장한다.
이것의 결점:
- Load balancing: 사람들은 최근 트윗만 보는데, 예전 트윗이 저장된 서버는 전혀 트래픽을 받지 않는다.
- 비싸다: 3주마다 한 서버를 꽉 채운다.
- 논리적으로 복잡하다: 완전히 새로운 클러스터를 3주마다 구축하는건 DBA에게 고통스럽다.
(2) 트윗을 저장하는 새로운 방식. (T-bird)
당신이 트윗을 하면 T-bird라고 불리는 내부 시스템에 저장됨.(T-bird는 Gizzard로 만들어짐)
보조 인덱스는 T-flock(이것도 Gizzard로 만들어짐) 이라는 분리된 시스템에 저장된다.

각 트윗의 고유ID는 Snowflake(오픈소스)로 생성됨.
snowflake를 쓰면 클러스터들에 좀더 균등하게 샤드할 수 있다.
FlockDB(Gizzard 사용)는 ID-ID 매핑이 사용된다. 즉, ID들간의 relationships을 저장한다.

Gizzard는 Mysql(InnoDB) 위에 구축된 트위터의 분산 데이터 스토리지 프레임워크.
- InnoDB 를 선택한 이유는 데이터가 손상되지 않아서.
- 높은 성능을 얻기 위해 개별노드의 많은 features 들은 turn off 했다. (바이너리 로그, 리플리케이션 같은거) Gizzard는 샤딩, 복제, 스케줄링을 컨트롤한다.
- Gizzard 는 다른 스토리지 시스템을 위한 building block 으로 사용된다.

Gizzard 는 로드 밸런싱에 완벽하게 동작하진 않지만, it allows.
- 서버가 꽉 차는걸 걱정할 필요없이 천천히 증가.
- DBA들이 잠을 잘 수 있다.

MySQL 은 ID generate와 그래프 저장이 안 된다.
평균 DB서버 사양: HP DL380, 72GB RAM, 24 disk RAID10. (메모리와 디스크의 좋은 균형)
MySQL Isn't Used For Everything:
* 카산드라는 쓰기 성능이 높은데, 읽기 성능이 안 좋은 특징. 장점은 저렴한 하드웨어에서 실행 가능, 쉽게 확장가능, schemaless 디자인.
* Hadoop은 구조화되지 않은 대형 데이터셋을 처리하기 위해 사용됨.
* Vertica 는 분석과 큰 데이터의 조합(MapReduce작업 없이)을 위해 사용된다.

http://goo.gl/vlLvU
이곳에 번역 하신 분이 또 계시네요~ ㅋㅋ