반응형

Riak

: Dynamo 계열

  Key/Value Store 방식

  Value는 JSON문서로 저장되는 Document 저장 방식

  유사모델 - MongoDB, CouchDB

 

Riak의 특징 - Consistent Hashing

 

Dynamo계열의 구조라서 Ring 구조 기반의 아키텍처인데,

Hash알고리즘에 의해 데이터 Key에 따라서 적정노드를 찾는 구조.

클러스터링 단위는 node(물리적)/vnode(논리적)가 있는데,

하나의 물리서버에 여러개의 논리서버를 설치할 수 있다.

이 Ring 구조를 Runtime 시에도 동적으로 재설정 할 수 있다.

Riak는 별도의 마스터 노드를 가지지 않는다.

 

Riak의 데이터 구조

  • Bucket
  • Data Structure

 

 

 

반응형
반응형

NoSQL

 : Not Only SQL - RDBMS 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술.

 

Visual Guide to NoSQL Systems

 

* CAP 기반의 DB 분류

 

NoSQL의 특징

  • NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다.
  • RDBMS에 비해 휠씬 더 대용량의 데이터를 저장할 수 있다.
  • RDBMS와는 다르게 일반적인 서버 수십대를 연결해 데이터를 저장/처리한다.
  • 테이블 스키마가 유동적이다.

CAP 이론

  • Consistency : 분산된 노드 중 어느 노드로 접근하더라도 데이터값이 같아야 한다는 기능적 특징이다.(데이터 복제 중에 query가 되면, Consistency를 제공하지 않는 시스템의 경우 다른 데이터 값이 query 될 수 있다. )
  • Availability : 클러스터링된 노드 중 하나 이상의 노드가 FAIL이 되더라도, 정상적으로 요청을 처리할 수 있는 기능을 제공하는 특성.
  • Partition Tolenrance : 클러스터링 노드 간에 통신하는 네트워크가 장애를 겪더라도 정상적으로 서비스를 수행할 수 있는 기능.

NoSQL의 분류

  • Key/Value Store
  • Ordered Key/Value Store - Key/Value Store 와 저장방식은 동일하나. 데이터 내부적으로 Key순서로 Sorting 되어 저장된다. NoSQL은 RDBMS의 Order By와 같은 기능을 제공하지 않기 때문에 Sorting해서 보여주는 것이 용이하다.
  • Document Key/Value Store - Key/Value의 확장된 형태로 저장되는 Value의 데이터 타입이 Document라는 타입을 사용한다. DocumentXML,JSON,YAML과 같이 구조화된 데이터 타입으로 복잡한 계층 구조를 표현 할 수 있다.

NoSQL과 RDBMS의 차이

 : NoSQL은 데이터를 저장하는데 Key에 대한 PUT/GET만 지원한다.

     공통적으로 아래의 기능들을 고민해봐야 한다.

     - Sorting

     - Join    

     - Grouping

     - Range Query

     - Index

 

NoSQL 사용시 주의사항

  • NoSQL의 적용타당성
  • 용도에 맞는 NoSQL제품 채택
  • 데이터 모델링
  • RDBMS와 혼용
  • 적용시 하드웨어와의 설계 호환성
  • 운영 이슈 및 BackUP

 

 

 

반응형
반응형

* 빅데이터 3대 활용 요소

자원

 활용할 수 있는 빅데이터 발견 

기술

 빅데이터 플랫폼의 데이터 저장/관리 기술(NoSQL, ETL) 및 처리 기술(Hadoop)

인력

 Data Scientist 역량 향상

 

NoSQL(Not only Sql)은 지금까지 사용되왔던 관계형 데이터베이스 모델에 얽매이지 않고 비테이블 기반이다.

NoSQL은 추가/추출 Operation과 레코드 저장 기능에 대해서 최적화가 적용되어 대용량 데이터 처리에 대해서

기존 관계형 데이터베이스가 가지고 있던 단점을 보완할 수 있다.

 

* 클라우드 서비스에 적용되는 데이터베이스 솔루션

 

 가상 머신 기반으로 적용

데이터베이스 서비스 

 SQL

데이터 모델

 - Oracle DB

 - IBM DB2

 - Ingres

 - PostgreSQL

 - MySQL

 - NuoDB

 - GaianDB

 - MySQL

 - MS-SQL

 - Heroku PostgreSQL

 - Clustrix DB

 - Xeround cloud DB

 - EnterpriseDB Postgres + Cloud DB

 NoSQL

데이터 모델

 - CouchDB(아마존)

 - Hadoop(아마존)

 - Apache cassandra(아마존)

 - Neo4J(아마존)

 - MongoDB(아마존)

 - Amazon DynamoDB

 - Amazon SimpleDB

 - Cloudant Data Layer

   (CouchDB)

 - Google AppEngine DataStore

 - MongoDB

 

HBase는 구글 빅테이블의 클론 솔루션이며 무한한 데이터 수용 확장성을 지원한다.

HBase는 HDFS(Hadoop Distributed File System)에 구현한 분산 칼럼 기반 데이터베이스이며,

 대규모 데이터셋에 실시간으로 랜덤 엑세스가 필요할 때 사용할 수 있는 Hadoop 응용프로그램이다.

 

* Oracle NoSQL Database 특징

  • 단순한 데이터 모델 지원(Major/Sub key를 사용한 key/value 쌍 지원)
  • 단순한 프로그래밍 모델 지원(ACID transaction과 JSON 지원)
  • Oracle DB & Hadoop 연동
  • 확장가능한 throughput 제공
  • 동적인 용량 추가 동작 지원
  • 설정 가능한 다중 복제를 이용한 높은 가용성 제공

* MongoDB 특징

  • 실행용 공식 Binary 파일은 Windows,Mac, Linux, Solaris에서 사용가능
  • 공식 드라이버는 C,C#,C++, Haskell, JAVA, javascript, Perl, PHP, Python, Ruby, Scala에서 사용가능
  • 임시(Ad-hoc) Javascript Query 지원(모든 문서 속성에서 기준을 사용해 데이터 검색)
  • Query에서 정규 표현식 지원
  • MongoDB의 Query 결과는 limit(),skip(),sort(),count(),distinct(),group()을 포함해 필터링과 수집 및 정렬에 필요한 다양한 함수를 제공하는 커서에 저장
  • 고급 수집용 map/reduce 구현
  • GridFS를 사용하는 대용량 파일 스토리지
  • RDBMS 형태의 속성 인덱싱 지원
  • Query 최적화 기능 지원
  • MySQL 과 비슷한 Master/Slave 복제
  • 참조쿼리를 허용하는 콜렉션 기반 오브젝트 스토리지
  • Auto-sharding 을 이용한 수평적 확장
  • 고성능의 동시성을 구현 가능 : 제자리 쓰기(In-place update)

 

반응형

'프로그래밍 > DataBase' 카테고리의 다른 글

[NoSQL] Riak - Full Text Search  (0) 2013.03.18
[NoSQL] Visual Guide to NoSQL Systems  (0) 2013.03.18
카산드라 - Apache Cassandra  (0) 2013.01.29
[Mobile] SQLite - 모바일기기  (0) 2012.11.07
[Oracle] 오라클 HINT  (0) 2012.09.26
반응형

Apache Cassandra

http://cassandra.apache.org/

 

Getting Started : http://wiki.apache.org/cassandra/GettingStarted

 

 


카산드라는 구글의 BigTable 컬럼 기반의 데이타 모델과 FaceBook에서 만든 Dynamo의 분산 모델을 기반으로 하여 제작되어
Facebook에 의해 2008년에 아파치 오픈소스로 공개된 분산 데이타 베이스.

기존의 관계형 데이타 베이스와 다르게 SQL을 사용하지 않는 NoSQL의 제품중의 하나이며,
대용량의 데이타 트렌젝션에 대해서 고성능 처리가 가능한 시스템이다.

(High-Scale). 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있다.


자바로 작성되었음에도 불구하고, 데이타베이스라는 명칭에 걸맞게 여러 프로그래밍 언어를 지원합니다.
Ruby,Perl,Python,Scala,Java,PHP,C#

데이타간의 복잡한 관계 정의(Foreign Key)등이 필요없고,
대용량과 고성능 트렌젝션을 요구하는 SNS (Social Networking Service)에 많이 사용되고 있습니다.
성능이나 확장성과 안정성이 뛰어나지만 안타깝게도 Global Scale (여러 국가에 데이타 센터를 분리 배치하여 배포하고,
데이타 센타간 데이타를 동기화 하는 요구사항) 은 지원하지 않습니다.

Global Scale이 필요하다면, MySQL기반의 geo replication과 Sharding이 아직까지는 가장 널리 쓰이는 아키텍쳐 같습니다.

Welcome to Apache Cassandra

The Apache Cassandra database is the right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. Cassandra's support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages.

Cassandra's ColumnFamily data model offers the convenience of column indexes with the performance of log-structured updates, strong support for materialized views, and powerful built-in caching.

 

 

 

반응형
반응형

SQLite는 MySQL나 PostgreSQL와 같은 데이터베이스 관리 시스템이지만, 서버가 아니라 응용 프로그램에 넣어 사용하는 비교적 가벼운 데이터베이스이다.

일반적인 RDBMS에 비해 대규모 작업에는 적합하지 않지만, 중소 규모라면 속도에 손색이 없다. 또 API는 단순히 라이브러리를 호출하는 것만 있으며, 데이터를 저장하는 데 하나의 파일만을 사용하는 것이 특징이다. 버전 3.3.8에서는 풀텍스트 검색 기능을 가진 FTS1 모듈이 지원된다. 컬럼을 삭제하거나 변경하는 것 등이 제한된다.

구글 안드로이드 운영 체제에 기본 탑재된 데이터베이스이기도 하다.

 

http://www.sqlite.org/

 

 

반응형
반응형
/*+ ALL_ROWS */

  ALL_ROWS는 Full Table Scan을 선호하며 CBO(Cost Based Optimization)는 default로 ALL_ROWS를 선택 합니다.

 
SQL> SELECT /*+ ALL_ROWS */  ename, hiredate 
     FROM emp  
     WHERE ename like '%%%';
       
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: ALL_ROWS (Cost=1 Card=5 Bytes=80)
   1    0   TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=5 Bytes=80)
    

 

/*+ CHOOSE */

  Hint Level의 CHOOSE는 RBO(Rule Based Optimization)인지 CBO(Cost Based Optimization) 인지를 선택 합니다. 만약 주어진 table의 통계 정보가 없다면 Rule Based 접근 방식을 사용 합니다.

 

/*+ FIRST_ROWS */

  Full Table Scan보다는 index scan을 선호하며 Interactive Application인 경우 best response time을 제공 합니다. 또한 sort merge join보다는 nested loop join을 선호 합니다.

 
SQL> SELECT /*+ FIRST_ROWS */  ename 
     FROM emp 
     WHERE empno=7876;
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=1 Card=1 Bytes=20)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=1 Card=1 Bytes=20)
   2    1     INDEX (RANGE SCAN) OF 'PK_EMP' (UNIQUE) (Cost=1 Card=1)
    

 

/*+ RULE */

  Rule Based 접근 방식을 사용하도록 지정 합니다.

 

/*+ CLUSTER(table_name) */

  Cluster Scan을 선택하도록 지정한다. 따라서 clustered object들에만 적용 됩니다.

 

/*+ FULL(table_name) */

  Table을 Full Scan하길 원할 때 사용 합니다.

 

/*+ HASH(table) */

  Hash scan을 선택하도록 지정한다. 이 hint는 HASHKEYS parameter를 가지고 만들어진 cluster내에 저장된 table에만 적용이 됩니다.

 

/*+ INDEX(table_name index_name) */

  지정된 index를 강제적으로 쓰게끔 지정 합니다.

 

/*+ INDEX_ASC(table_name index_name) */

  지정된 index를 오름차순으로 쓰게끔 지정 합니다. Default로 Index Scan은 오름차순 입니다

 

/*+ INDEX_DESC(table_name index_name) */

  지정된 index를 내림차순으로 쓰게끔 지정 합니다.

  아래 예제는 제일 큰 것 하나만 조회되므로, max 함수의 기능을 대신할 수 있습니다.

 
SQL> SELECT /*+ index_desc(emp pk_emp) */  empno
     FROM   emp
     WHERE  rownum = 1 ;
    

 

/*+ INDEX_FFS(table index) */

  Full table scan보다 빠른 Full index scan을 유도 합니다.

 

/*+ ORDERED */

  From절에 기술된 테이블 순서대로 join이 일어나도록 유도 합니다.

 

/*+ USE_HASH (table_name) */

  각 테이블간 HASH JOIN이 일어나도록 유도 합니다.

 

*+ USE_MERGE (table_name) */

  지정된 테이블들의 조인이 SORT-MERGE형식으로 일어나도록 유도 합니다.

 

/*+ NOPARALLEL(table_name) */

  NOPARALLEL hint를 사용하면, parallel query option을 사용하지 않도록 할 수 있다.

 

/*+ PARALLEL(table_name, degree) */

  PARALLEL hint를 사용하면 query에 포함된 table의 degree를 설정할 수 있습니다.

  예를 들어, 다음과 같이 hint를 적어 degree 4로 parallel query option을 실행하도록 할 수 있습니다. 이 때 parallel이란 글자와 괄호( '(' )사이에 blank를 넣지 않도록 주의해야 합니다.

 
SQL> SELECT /*+ PARALLEL(emp, 4) */   * 
     FROM emp;
    

 

DEGREE의 의미 및 결정

  Parallel Query에서 degree란 하나의 operation 수행에 대한 server process의 개수 입니다. 이러한 degree 결정에 영향을 주는 요인들에는 다음과 같은 것들이 있습니다.

  • (1) system의 CPU 갯수
  • (2) system의 maximum process 갯수
  • (3) table이 striping되어 있는 경우, 그 table이 걸쳐있는 disk의 갯수
  • (4) data의 위치 (즉, memory에 cache되어 있는지, disk에 있는지)
  • (5) query의 형태 (예를 들어 sorts 혹은 full table scan)

  한 사용자만이 parallel query를 사용하는 경우, sorting이 많이 필요한 작업과 같은 CPU-bound 작업의 경우는 CPU 갯수의 1 ~ 2배의 degree가 적당하며, sorting보다는 table scan과 같은 I/O bound 작업의 경우는 disk drive 갯수의 1 ~ 2배가 적당합니다.

  동시에 수행되는 parallel query가 많은 경우에는 위의 각 사용자의 degree를 줄이거나 동시에 사용하는 사용자 수를 줄여야 합니다.

반응형
반응형

빅데이터의 본질과 활용방안

http://719121812.blog.me/20164478750

반응형
반응형

 SQL Relay - Database connection pool with support for lots of languages and databases.


Download : http://sourceforge.net/projects/sqlrelay/ 


Looking for the latest version? Download sqlrelay-0.46.zip (3.5 MB)

반응형

+ Recent posts