조대협의 블로그

Cassandra Node CRUD Architecture 이번 글에서는 Cassandra 클러스터를 구성하는 각 노드에서 Local Read/Write가 어떤 원리로 이루어지는 지 설명한다.Cassanda에 대한 기반 지식은 아래 예전 포스팅을 참고하기 바란다. Cassandra 소개 및 데이타 모델 http://bcho.tistory.com/440Cassandra의 시조가 되는 Amazon Dynamo 아키텍쳐의 장단점 http://bcho.tistory.com/622Dynamo 기반의 Ring 아키텍쳐 설명 http://bcho.tistory.com/621 (다른 NoSQL인 Riak에 대한 설명이지만 클러스터를 구성하는 Ring 아키텍쳐는 Dynamo 계열이기 때문에 동일하다.)Cassandra ..

요즘 잘나간다는 SNS 서비스 (텀블러, PInterest)등의 내부 서비스 아키텍쳐나 운영 구조를 공개된 글을 보면 SNS 시스템들의 기술 트렌드를 읽을 수 있다. 1. 소규모 조직이다. 얼마전에 FB에 인수된 Instantgram이나 다른 잘나가는 SNS서비스 업체들을 보면 대부분 인력이 20명이내이다. 영업 조직이 있는 솔루션 업체의 경우는 영업이나 Director들을 포함하더라도 40명이 안넘는 것이 대부분이다. 이는 빠른 의사 결정을 가능하게 하기 때문에, 상당히 빠른 서비스 개선을 가능하게 한다. 기술적이나 기획적으로 대단한게 아니라, 하나의 기능을 편하게 만들고 사용자 경험에 상당한 노력을 쏟는다. 2. 오픈 소스로 치덕치덕. & Don't invent wheel again 이런 서비스들 치..

이 구성은 Cassandra나 Riak과 같은 Dynamo 계열에 공통 적용 가능하다. 다른 것들도 마찬 가지일테지만. 1. RAID 5 사용 : NoSQL 클러스터는 Quorum 사용을 통해서 노드에 (서버) 대한 FAIL을 방지 하지만 디스크 장애 자체에 대해서는 보장이 불가능하다. 고로 비용 대비 적정한 RAID 5 사용이 권장 2. IO Scheduler : NOOP 사용. NOOP은 IO Scheduling을 다른 계층이 한다는 것을 전제 한다. 즉 중간에 RAID 구성이나 iSCSI 를 사용하는 경우를 전제한다. 테스트용이나 개발용으로 사용하면서 RAID 구성등을 하지 않는다면, NOOP을 사용할 필요가 없다. 3. ext4 또는 XFS 파일 시스템 사용 : ext3는 1 volume의 max..

NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모. RAID 구성은 5가 정답 NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함. 아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...) IO Scheduler가 성능 튜닝 포인트라고는 하는데... 오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯. 결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.

지금까지 파악한 Riak 장점 1. Masterless 아키텍쳐로 Single Failure Point가 없다. 2. Replication이 빵빵하다. 3. Multi data center replication이 빵빵 (유료 버전만 지원) 4. Full Text Search (Lucene을 내장하여 FTS를 그냥 지원.. 인스톨도 쉬움) 5. Secondary Index 지원 6. 상당히 향상된 Map & Reduce 지원. Erlang 기반이라서 훨씬 신뢰가 감 7. Basho의 Support도 좋음. (경험해본 결과 좋음) 8. Physical storage를 Basho의 bitcask, oracle innostore, google level db,memory 지원 9. Luwak을 이용하여, Big..

http://blogs.digitar.com/jjww/2011/03/riak-vs-couchdb-for-storing-100000-coupons/ CouchDB와 비교한 Performance Report가 있는데 Riak 0.14 버전 기준 작년 3월(1년전)이니 많은 변화는 있었겠지만 얻을만한 데이타가 많다. Indexed insertion is 91% slower than storing just the key data. MapReduce with indexes is 20% faster than MR on the data keys alone. MapReduce with indexes and key filters is 32% faster than MR on the data keys alone. Addin..

NoSQL @ Qbranch -2010-04-15 View more presentations from Mårten Gustafson CouchDB의 Kick-ass replication만 기억에 남네 그랴.

짧으나마 NoSQL 경험해보고 배운 내용을 정리해보면 1. RDB는 Entity를 정의하고 데이타 모델링을 정의한 후에, 쿼리와 APP을 개발한다. 반대로 NoSQL은 App을 먼저 디자인하고, 필요한 쿼리 결과를 먼저 정의 한후에, 그에 맞춰서 데이타 모델링을 해야 한다. 2. 절대 Normalization은 하지 말고, DeNormalization을 할것. 데이타 중복을 허용하여 성능을 높이고, 데이타안에 데이타를 넣는 (Composition) 모델등을 사용하여 Query 수를 줄여야 한다. 3. 내 애플리케이션의 서비스 특성과 이에 맞는 NoSQL을 선택한다. BigTable 계열, Cassandra 계열, Document DB 계열등 많은 계열의 NoSQL이 있고, 그 특성도 매우 다르다 (언뜻 ..

분산 환경 기반의 NoSQL은 예전 포스팅에서도 설명했듯이 크게 Google의 BigTable 논문을 기반으로한 시스템과, Amazon의 Dynamo를 기반으로 한 시스템 두가지로 나뉘어 진다. Dynamo 계열의 NoSQL의 장단점을 간단히 정리해보면 Dynamo 계열 NoSQL의 개요 1. Ring과 Consistent Hasing 먼저 Dynamo 계열 (Cassandra, Riak) 의 NoSQL의 특징은 Ring 토폴로지를 기본으로 하고 있다. Ring 구성이란, 전체 데이타를 1~N (2^160과 같이 큰 범위로) 이라는 특정 레인지로 정의한후 전체 데이타 저장 구조를 Ring 형으로 정의한 후에, 이 Ring을 피자 조각을 나누듯이 여러 Slice로 나눈다. 이를 Partition이라고 하는..

Riak 계보 Riak은 이미들 잘 알고 있는 NoSQL 데이타 베이스이다. Basho.com이라는 회사에서 만들어서 배포하고 있고, 무료 버전인 Community version과 상용 기술 지원을 받을 수 있는 Enterprise version을 지원하고 있다. NoSQL 계보는 크게 두 가지로 나눠지는데, Google의 Big Table 논문을 기반으로 한 HBase,HyperTable 등과, Amazon Dynamo 논문을 기본으로 한 Cassandra등의 계열로 나뉘어 지며, Riak은 Dynamo 계열에 속한다. 데이타 모델에 있어서는 Key,Value 저장형식을 취하는데, Value는 JSON 문서가 저장되는 문서 저장형 데이타 베이스 형식을 취하며, 이는 MongoDB나 CouchDB와 유사..