Transcript NoSQL
NoSQL
이혁재/KASA
2010.08.14
요약
• NoSQL소개
• 데이타베이스 관련 문서
• 대상 : 클라이언트 프로그래머
Online game에서의 데이터저장소
• File ( ISAM )
• DBMS
– mysql
– mssql
– oracle
– memory DB
NoSQL
• NO SQL ?
• Not Only SQL !
• 클래식한 rdb와 다른 database( or datastore )
• 학계에서는 structured storage라는 용어를 사용
NoSQL
why NoSQL?
• 기존 RDB에서의 해결할 수 없는 문제가 생김
• Massive Data에서 낮은 성능
– 대규모 문서를 indexing
– 높은 트래픽의 웹사이트에서 데이타를 표시
– streaming 미디어를 전달
• 하드웨어 장애와 자동화된 복구
• Data Model이 문제 - Schema free
• RDBMS를 사용하는 것보다 구현이 간단한 경우
why NoSQL? ( twitter의 문제 )
• 7 TB/day ( 2+ PB/yr) 저장
• = 10,000 CDs/day
• = 초당 80MB
why NoSQL? ( facebook의 문제 )
• 5700억 view / month
• 다른 모든 사진 사이트(flickr 포함)를 합친 것보다
많은 사진을 서비스
• 30억 photo upload / month
NoSQL의 특징
• 테이블 스키마 없음( item 저장에 좋을 수도? )
• join 오퍼레이션 없음( relation이 없다. )
• 컴퓨터를 늘려서 규모 가변적
• 내부구조 : 분산 hash table
• distributed
• key-value pair나 assocative arrays 인터페이스
• poor ACID( Atomic Consistency Isolation
Durability )
• 부수효과: app 개발 생산성
• open source
분류
• Key-value stores
• Document Database
• Wide column stores
• Graph databases
분류
분류( Key-value stores )
• 하나의 키, 하나의 값, 중복없음, 빠름
• value 는 binary
분류( Document Database )
• key-value이지만 structred value
• data에 대해서 query할 수 있음
분류( Wide column stores )
• sparse, distributed multi-dimensional sorted map
• Google BigTable, Cassandra …
분류( Graph databases )
• 데이터의 관계( 그래프 )를 저장하는 용도
case study
case study
case study
case study
SQL같은 질의는 어떻게 하는가?
• DBMS( SQL )
– SELECT `column` FROM `table` WHERE `id` = key;
• API
– BigTable
table.get(key, "column_family:column")
– Cassandra
keyspace.get("column_family", key, "column")
• Query-language
• MapReduce
MapReduce
• google 의 search엔진에서 사용
– 논문 Simplified Data Processing On Large Cluster
• 데이터 처리 기술
– 프로그래밍 모델과 그 구현
• 함수형 프로그래밍에서 유래
MapReduce
MapReduce
MapReduce
twitter의 해결책( NoSQL과 연관 없는 것도 포함 )
• log문제
– 처음엔 syslog사용
– 크기가 커짐에 따라 scale이 안됨
– 데이타를 잃어버림
twitter의 해결책
• scribe
– FB도 같은 문제를 겪음, open-source
– 로그를 분류를 갖추어 쓰면 나머지는 알아서
scribe가 모아줌
– twitter 개발자도 개발에 기여
– http://github.com/facebook/scribe
twitter의 해결책
• Hadoop
–7TB/day를 어떻게 쓸 것인가에서 시작
–자동화된 복제와 오류복구
–MapReduce-based
–1TB 임의의 정수 데이타를 62초에만에 정렬
–평판, pagerank, 관계계산에 사용
–5분만에 120억 tweet을 count
–트위터 엔지니어들이 LZO로 압축저장하게 기여함
http://github.com/kevinweil/hadoop-lzo
twitter의 해결책
• Pig
–SQL보다 쉬운 데이타 처리 언어
–데이타 분석에 사용
어떤 기능이 유저를 낚이게 하는가?
확률적 봇 탐지
– http://hadoop.apache.org/pig/
twitter의 해결책
• Pig sample
twitter의 해결책
• HBase
– BigTable의 clone ( HDFS위에서 동작 )
– Find People 기능에 사용
– 많은 기능이 HBase사용하여 구축되어지고 있음
– cassandra와 비교됨
cassandra - 낮은 지연시간에 강점
HBase - 배치작업에 강점
– http://hbase.apache.org
twitter의 해결책
• FlockDB
– 유저 간의 follow관계 그래프 디비
– 일반적 rdb로는 어려움이 많아서 자체 제작
join으로 해결안됨
join하려해도 메모리도 문제
–http://github.com/twitter/flockdb
twitter의 해결책
• Cassandra
– tweet저장에 사용
– facebook에서 만듬
– 예전 시스템
MySQL로 분할 저장
memcached( consistency문제가 생김, 복제 문제도 생김 )
application에서도 처리해야 함
테이블을 고칠 수 없음 땜방이 필요
MySQL의 write 한계에 종종 도달
– cassandra를 사용하니 모두 해결!!!
– http://cassandra.apache.org
facebook의 해결책
• Cassandra, Scribe, HADOOP은 twitter와 동일
• PHP, Linux, MySQL
–모두 facebook에 맞추어 변경 또는 최적화
facebook의 해결책
Memcached
– 웹서버와 MySQL서버 cache layer
– distributed memory cache
– http://memcached.org
facebook의 해결책
• HipHop
– PHP를 C++로 convert, g++ compile해서
바이너리로 만들어줌
– 웹 서버의 평균 CPU 사용량을 50% 정도 다운
– http://github.com/facebook/hiphop-php
facebook의 해결책
• Haystack
– 건초 더미?
– Photo Infrastructure
HTTP server ( libevent 안의 프로그램 내장형 http서버 )
Photo Store
Haystack Object Store
Filesystem
Storage
facebook의 해결책
• BigPipe
– 웹페이지를 pagelet이라는 단위로 쪼개서 처리하는
server side system
– 병렬적으로 pagelet을 처리
facebook의 해결책
• Thrift
– 서로 다른 언어를 사용한 개발을 가능하게 해줌
– software framework
– RPC 서버와 클라이언트를 생성해줌
– http://incubator.apache.org/thrift/
– facebook은 C++, Erlang, Java, Python, PHP등을
백앤드에서 사용
reference
• http://en.wikipedia.org/wiki/NoSQL
• http://www.slideshare.net/kevinweil/nosql-attwitter-nosql-eu-2010d8
• http://royal.pingdom.com/2010/06/18/thesoftware-behind-facebook/
• http://www.slideshare.net/mmarth/no-sql-3657930
• http://www.slideshare.net/harrikauhanen/nosql3376398
• http://enzine.tistory.com/entry/HipHop-for-PHP더-빠른-PHP를-위해
Q&A