Cassandra 데이터 모델

레 퍼 런 스
http://www.cnblogs.com/shanyou/archive/2010/02/25/1673781.html
http://www.hellodba.net/2010/02/cassandra.html
http://www.cnblogs.com/JeffreyZhao/archive/2010/02/24/mongodb-tokyo-tyrant-benchmark-1-basic-cru-operations.html
 
NoSQL 이 야 기 를 꺼 내 면 DBA 가 관심 을 가 져 야 할 일이 아니 라 구조 사가 관심 을 가 져 야 할 것 같다.그러나 DBA 로 서 전통 적 인 관계 형 사상 모델 링 을 사용 할 때 NoSQL 의 모델 링 방법 을 알 필요 가 있어 야 한다.
각종 NoSQL 데이터 베 이 스 는 매우 많 습 니 다.제 가 가장 주목 하 는 것 은 BigTable 유형 입 니 다.확장 가능 한 분포 식 컴 퓨 팅 플랫폼 이기 때문에 대량의 구조 화 데 이 터 를 처리 하 는 데 사용 되 고 데이터 베 이 스 는 구조 화 데 이 터 를 처리 하기 때문에 SQL 이 없 는 것 을 제외 하고 데이터 모델 에 있어 비슷 한 점 이 있 습 니 다.카 산 드 라 는 페 이 스 북 에서 시 작 된 버 전 으로 빅 테이블 의 오픈 소스 버 전 으로 볼 수 있 으 며 현재 트 위 터 와 digg.com 에서 사용 되 고 있다.우 리 는 DBA 의 관점 에서 Cassandra 의 데이터 모델 을 이해 하려 고 시도 했다.
NoSQL 은 No SQL 로 간단하게 이해 할 수 없다.그 본질은 No Relational 이 어야 한다.즉,관계 형 이론 적 기반 이 아니 라 우리 의 모든 전통 적 인 데이터 베 이 스 는 이 이론 을 바탕 으로 발 전 된 것 이기 때문에 SQL 은 문제 의 관건 이 아니다.예 를 들 어 일부 NoSQL 데이터 베 이 스 는 SQL 유형의 인 터 페 이 스 를 제공 할 수 있다.클래스 SQL 의 문법 을 통 해 데이터 에 접근 할 수 있 도록 합 니 다.한편,Friendfeed 는 반대로 관계 형 데이터 뱅 크 MySQL 을 이용 하여 관계 화 된 디자인 방법 으로 자신의 KeyValue 저장 을 실현 했다.그래서 NoSQL 의 본질은 No Relational 입 니 다.
Cassandra 특징:
1.유연 한 schema 는 데이터베이스 처럼 schema 를 미리 설계 하지 않 아 도 되 고 필드 를 추가 하거나 삭제 하 는 것 이 매우 편리 하 다(on the fly).
2.range 조회 지원:Key 에 대해 범위 조 회 를 할 수 있 습 니 다.
3.높 은 사용 가능,확장 가능:단일 고장 은 클 러 스 터 서비스 에 영향 을 주지 않 고 선형 확장 이 가능 합 니 다.
Keyspace
Cassandra 의 최대 조직 단원 에는 일련의 Column family 가 포함 되 어 있 으 며,Keyspace 는 일반적으로 응용 프로그램의 이름 입 니 다.너 는 그것 을 Oracle 안의 schema 로 이해 할 수 있 고 일련의 대상 을 포함 하고 있다.
Column family（CF）
CF 는 특정한 Key 의 데이터 집합 으로 모든 CF 는 물리 적 으로 단독 파일 에 저 장 됩 니 다.개념 적 으로 보면 CF 는 데이터베이스 에 있 는 Table 과 비슷 하 다.
Key
데 이 터 는 반드시 Key 를 통 해 접근 해 야 합 니 다.Cassandra 는 범위 조 회 를 허용 합 니 다.예 를 들 어start => '10050', :finish => '10070'
Column
Cassandra 에서 필드 는 가장 작은 데이터 셀 입 니 다.column 과 value 는 하나의 쌍 을 구성 합 니 다.예 를 들 어 name:"jacky",column 은 name,value 는 jacky 입 니 다.모든 column:value 뒤에 시간 스탬프 가 있 습 니 다:timestamp.
데이터베이스 와 달리 카 산 드 라 의 한 줄 에 여러 개의 column 이 있 을 수 있 고 줄 마다 column 이 다 를 수 있 습 니 다.데이터베이스 디자인 의 측면 에서 볼 때 표 에 두 개의 필드 가 있 는데 첫 번 째 는 Key 이 고 두 번 째 는 긴 텍스트 형식 으로 많은 column 을 저장 하 는 데 사용 된다.카 산 드 라 가 매우 유연 한 schema 를 갖 추고 있다 고 말 하 는 이유 다.
Super column
Super column 은 여러 개의 일반적인 column 을 저장 할 수 있 는 특수 한 column 입 니 다.또한 하나의 CF 에 도 여러 개의 Super column 이 있 을 수 있 습 니 다.하나의 CF 는 Column 이나 Super column 만 정의 할 수 있 고 혼용 할 수 없습니다.다음은 Super column 의 한 예 입 니 다.home Address 라 는 Super column 은 세 개의 필드 가 있 습 니 다.각각 street,city 와 zip 입 니 다.

homeAddress: {street: "binjiang road",city: "hangzhou",zip: "310052",}

Sorting
데이터 베 이 스 는 Order by 를 통 해 정렬 규칙 을 정의 할 수 있 습 니 다.Cassandra 가 추출 한 데이터 순 서 는 항상 일정한 것 입 니 다.데이터 저장 시 정 의 된 규칙 에 따라 저장 되 었 기 때문에 추출 순서 가 확정 되 었 습 니 다.이것 은 커 다란 성능 장점 입 니 다.재 미 있 는 것 은 Cassandra 는 column value 가 아 닌 column name 에 따라 정렬 합 니 다.다음 과 같은 몇 가지 옵션 을 정의 합 니 다.Bytes Type,UTF8 Type,LexicaluUIDType,TimeUUIDType,Ascii Type,  LongType 과 함께 column name 에 따라 정렬 하 는 방법 을 정의 합 니 다.실제로 column name 을 서로 다른 유형 으로 인식 하여 유연 하 게 정렬 하 는 목적 을 달성 하 는 것 이다.UTF8Type 은 column name 을 UTF 8 인 코딩 으로 변환 해 정렬 하고,LongType 은 64 비트 long 형 으로,TimeUUIDType 은 시간 기반 UUID 로 정렬 합 니 다.예 를 들 면:
Column name 은 LongType 에 따라 정렬 합 니 다.

{name: 3, value: "jacky"},
{name: 123, value: "hellodba"},
{name: 976, value: "Cassandra"},
{name: 832416, value: "bigtable"}

Column name 은 UTF8Type 에 따라 정렬 합 니 다.

{name: 123, value: "hellodba"},
{name: 3, value: "jacky"},
{name: 832416, value: "bigtable"}
{name: 976, value: "Cassandra"}

다음은 트 위 터 의 Schema 를 살 펴 보 겠 습 니 다.

<Keyspace Name="Twitter">
  <ColumnFamily CompareWith="UTF8Type" Name="Statuses" />
  <ColumnFamily CompareWith="UTF8Type" Name="StatusAudits" />
  <ColumnFamily CompareWith="UTF8Type" Name="StatusRelationships"
    CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />
  <ColumnFamily CompareWith="UTF8Type" Name="Users" />
  <ColumnFamily CompareWith="UTF8Type" Name="UserRelationships"
    CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />
</Keyspace>

트 위 터 라 는 키 스페이스 를 보 았 습 니 다.여러 개의 CF 가 포함 되 어 있 습 니 다.그 중에서 StatusRelationships 와 UserRelationships 는 Super column 을 포함 한 CF 로 정의 되 었 습 니 다.Compare With 는 column 의 정렬 규칙 을 정 의 했 고 Compare Subcolumns With 는 subcolumn 의 정렬 규칙 을 정 의 했 습 니 다.여기 서 두 가지 가 있 습 니 다.TimeUUIDType 과 UTF8 Type 입 니 다.우 리 는 column 에 대한 정 의 를 보지 못 했다.이것 은 column 이 유연 하 게 변경 할 수 있다 는 것 을 의미한다.
이해 하기 편 하도록 관계 형 데이터 베 이 스 를 모델 링 하 는 방법 으로 트 위 터 의 Schema 를 묘사 해 보 겠 습 니 다.하지만 이것 이 바로 Cassandra 의 데이터 모델 이 라 고 오해 하지 마 세 요.Cassandra 에 게 모든 줄 의 colunn 은 데이터베이스 처럼 표를 만 들 때 만 들 수 있 는 것 이 아 닙 니 다.
Users CF 는 사용자 의 정 보 를 기록 하고,Statuses CF 는 트 위 터 의 내용 을 기록 하 며,StatusRelationships CF 는 사용자 가 본 트 위 터 를 기록 하고,User Relationships CF 는 사용자 가 본 followers 를 기록한다.정렬 방식 이 TimeUUIDType 이라는 것 을 알 게 되 었 습 니 다.이 유형 은 시간 에 따라 정렬 된 UUID 필드 입 니 다.column name 은 UUID 함수 로 생 성 되 었 습 니 다.(이 함 수 는 UUID 를 되 돌려 주 었 습 니 다.이 UUID 는 현재 시간 을 반영 하여 이 UUID 에 따라 정렬 할 수 있 습 니 다.timestamp 와 유사 합 니 다)그래서 결 과 는 시간 에 따라 정렬 됩 니 다.트 위 터 를 사용 해 본 사람들 은 모두 알 고 있 습 니 다.당신 은 항상 자신의 최신 트 위 터 나 최신 friends 를 볼 수 있 습 니 다.
기억
카 산 드 라 는 열 기반 저장 소(Bigtable 도 마찬가지)로 열 기반 데이터 베이스 와 같은 이치 입 니 다.
API
다음은 데이터베이스,Bigtable 과 Cassandra API 의 대비 입 니 다.

Relational			SELECT `column` FROM `database`.`table` WHERE `id` = key;
BigTable			table.get(key, "column_family:column")
Cassandra: standard model	keyspace.get("column_family", key, "column")
Cassandra: super column model	keyspace.get("column_family", key, "super_column", "column")

카 산 드 라 데이터 모델 에 대한 나의 이해:
1.column name 은 실제 값 을 저장 하고 value 는 비어 있 습 니 다.Cassandra 는 column name 에 따라 정렬 되 고 열 에 따라 저장 되 기 때문에 column name 을 이용 하여 실제 값 을 저장 하고 value 부분 은 비어 있 습 니 다.예 를 들 어"jacky":"null","fenng":"null"
2.Super column 은 하나의 색인 으로 볼 수 있 습 니 다.약간 관계 형 데이터 베이스 에 있 는 외 키 와 같 습 니 다.슈퍼 column 을 이용 하면 빠 른 포 지 셔 닝 을 실현 할 수 있 습 니 다.왜냐하면 이것 은 column 을 되 돌 릴 수 있 고 순 서 를 정할 수 있 기 때 문 입 니 다.
3.정렬 은 정의 할 때 확정 되 고 추출 한 데 이 터 는 반드시 정확 한 순서에 따라 배열 되 는데 이것 은 커 다란 성능 장점 이다.
4.매우 유연 한 schema,column 은 유연 하 게 정의 할 수 있 습 니 다.실제로 colume name 은 많은 경우 에 value 입 니 다.
5.column 뒤의 timestamp 마다 명확 한 설명 을 찾 지 못 했 습 니 다.데이터 다 중 버 전이 나 바 텀 에서 데 이 터 를 정리 할 때 필요 한 정보 일 것 이 라 고 추측 합 니 다.
마지막 으로 구 조 를 말하자면 구조의 핵심 은 취사선택 이 라 고 생각 합 니 다.CAP 든 BASE 든 모두 이 원칙 을 말 합 니 다.구조의 아름다움 은 여러 가지 문 제 를 완벽 하 게 해결 할 수 있 는 구조 가 없다 는 것 이다.데이터 베이스 와 NoSQL 은 모두 응용 장면 이 있 는데 우리 가 해 야 할 일 은 바로 자신 에 게 적당 한 구 조 를 찾 는 것 이다.
–EOF–
이 글 은 제 가 참고up and running with cassandra했 습 니 다.그 밖 에 트 위 터 가 제공 하 는 API 도 참고 하여 트 위 터 의 schema 디자인 을 이해 하 는 데 도움 을 주 었 습 니 다.이 글 은 이해 가 부정 확 한 부분 이 많 을 것 이 니 여러분 의 지적 을 바 랍 니 다.