Cassandra의 특징 - 토큰링을 배경으로 Key 구간 설정으로 서버(노드)의 추가 및 제거만으로 전체 저장 공간이 DB연하게 확장/축소됨- 다른 서버(노드)에 데이터 복제본을 구성하여 특정 노드 장애시에도 서비스에 영향을 주지 않고 데이터 DB실되지 않도록 함 - Key-Value 구조로 Hash 알고리즘을 통한 O(1) 접근으로 빠른 엑세스 성능을 보여줌- Write(수정/추가/삭제)시 실제 스토리지 구조에 적용하기 전 CommitLog 에 변경사항을 먼저 기록하므로 빠른 성능을 보임.(MySQL 대비 8~15 배) - RDBMS 의 엄격한 Schema 를 적용하지 않음. (Row 마다 속성을 다르게 정의 가능)- RDBMS 에서 제공하는 산술/자료 처리 함 수들을 모두 지원하지는 않음. (현재 극히 일부만 제공, 점진적 확장) - RDBMS 에서 사전에 정의해 놓은 Entity 에 대한 JOIN 을 지원하지 않음. (응용 환경에서 구현해야 함)- 1차 인덱스는 Column Family 의 Column 이름을 기반으로 함. (2차 인덱스는 Column 의 Value) - RDBMS 처럼 주요 접근에 대해 Order by 를 수행 할 경우 수행 시점에서 정렬이 이루어 지지만 Cassandra 의 경우 사전 정해진 인덱스(1차 Column 명, 2차 Column 값)에 대해서만 수행 가능- 데이터 전송 프로토콜로 Thrift 를 이용합니다. Thrift 는 Facebook 에서 시작된 프로젝트인데 Cross-Language 를 지원합니다. 사실상 언어에 의존성 없이 모든 환경에서 이용가능- 물리 파일 저장 구조로 SSTable 을 사용합니다. SSTable 은 구글에서 제안한 것으로 Bigtable 의 구조 형태로 데이터를 저장하고 있습니다. Sorted String Table 의 약자인 만큼 물리 파일 저장 구조 자체가 1차 정렬 조건에 맟추어 사전 정렬된 형태를 DB지하게 됨.(Cassandra 의 경우 CF 의 Column 의 이름)[ 대용량의 데이터를 저장하고 처리해야하고 정렬에 활용되는 속성이 제한되며 데이터 변경이 잦은경우(Email,쪽지의 inbox)가 사용하기에 좋은 환경임 ? Facebook의 Inbook 처리 문제에서 시작 ]