반응형

'구글 스패너'···막 오르는 SQL 데이터베이스 새 시대 


 원문보기: http://www.ciokorea.com/news/34274


전통적인 데이터베이스를 확장할 때에는 일반적으로 샤딩(sharding)이라는 프로세스가 사용된다. 데이터를 여러 개의 소규모 데이터베이스로 쪼갬으로써 부하를 분산하는 방식이다. 2005년 당시에 애드워즈를 구동하는 데이터베이스는 샤딩을 한 번 다시 하려면 몇 년이 걸릴 정도로 방대해지고 있었다. 새로운 데이터베이스가 필요했고 구글은 직접 구축에 나섰다.


이처럼 구글이 애드워즈 처리를 위해 구축했던 데이터베이스가 스패너(Spanner)라는 제품으로 최근 일반에 공개됐다. 최근 새로운 데이터베이스들이 잇달아 출시되고 있는 가운데 스패너도 합류한 것이다. 최신의 데이터베이스들은 전통적인 관계형 SQL데이터베이스와 비슷하지만 방대한 규모로의 확장성은 훨씬 뛰어나다. 기존의 SQL에 새롭다는 의미의 형용사(New)를 결합해 NewSQL이라고 불리곤 한다.


데이터베이스 시장의 움직임을 주시하는 전문가들은 NewSQL 데이터베이스가 언젠가는 오라클, IBM, 마이크로소프트 등의 거물급 데이터베이스 제품들과 치열한 경쟁을 벌이게 될 것이라고 보고 있다.


스패너란 어떤 제품? 

구글의 스패너는 여러 요건을 충족시키기 위해 등장했다. 한편으로는 방대한 규모로 확장성이 필요했고 다른 한편으로는 전 세계 데이터센터로의 분산도 필요했다. 아울러, 구글은 데이터베이스 프로그래밍 언어의 대표격인 SQL을 사용하는 관계형 데이터베이스를 원했고 여기에 낮은 지연시간과 매우 높은 신뢰성이라는 조건도 추가했다. 구글은 10년 가까운 개발 노력 끝에 2012년 스패너와 이를 구글 내에서 이용한 사례를 소개한 연구 논문을 발표했다.


그 후 몇 년에 걸쳐 구글은 스패너를 자사 클라우드 플랫폼에서 제공되는 데이터베이스로 개발하는 작업을 진행했다. 마침내 올해 초 스패너의 초기 베타 버전이 등장했다.

스패너는 구글의 클라우드에 호스팅되는 분산형 데이터베이스로서 전 세계적인 일관성과 확장성이 특징이다. 이는 데이터 접근이 필요한 최종 사용자와 가깝게 데이터가 존재할 수 있도록 스패너의 인스턴스(instance)가 전 세계 곳곳에 위치할 수 있는 동시에 데이터베이스의 각 복사본은 동일하다는 것을 의미한다. 말은 쉽지만 결코 쉽지 않은 특징이다.


구글 클라우드 내에는 스패너 운용에 필수적인 두 가지 독특한 기능이 있다. 하나는 전 세계 데이터를 동기화 하기 위해 가장 정확한 시간 측정 방식인 원자 시계를 사용하는 트루타임(TrueTime)이라는 타임 스탬프(time-stamp) 기능이다.


다른 하나는 전 세계 구글 데이터센터를 연결하는 구글 내부 광섬유망이다. 스패너의 내부 데이터베이스 트래픽은 일반 인터넷 대신 구글에서 직접 구축하고 통제하는 구글 트래픽 전용 파이프를 통해 전송된다. 전 세계 어느 곳이든 연결되는 스패너 내부 트래픽 전용 고속도로가 있는 셈이다.


NewSQL 시장 

스패너는 클라우드에 호스팅되는 NewSQL 데이터베이스 중 최초로 광범위하게 사용될 것으로 여겨지는 제품 가운데 하나다. 카네기 멜론 대학교(Carnegie Mellon University) 앤드류 파블로 교수는 공동 논문에서 NewSQL에 대해 “지속적으로 발전되는 데이터베이스 기술의 다음 단계”라고 평가했다.


NewSQL 데이터베이스의 개별적인 특징은 새로울 것이 없지만 그 동안 이를 모두 아우르는 데이터베이스는 없었다. 예컨대, 전통적인 관계형 데이터베이스는 SQL를 지원하고 일관성이 강한 반면 확장성이 부족하고 NoSQL 데이터베이스는 확장이 쉬운 반면 SQL 지원이 부족한 단점이 있다.


위 논문에서는 NewSQL 데이터베이스에 대해 “분산된 컴퓨팅 리소스가 풍부하고 저렴한 동시에 응용프로그램의 요구사항은 훨씬 더 커진 새로운 시대가 낳은 산물”이라고 표현했다.


이렇게 새로운 세대의 데이터베이스의 시장은 아직 시작 단계다. NewSQL 데이터베이스 중 가장 주목할 만한 예로는 인메모리(in-memory) 관계형 데이터베이스인 SAP 하나(HANA)를 들 수 있다. 이 밖에도 몇몇 신규업체에서 NuoDB, H-Store, Clusterix, VoltDB, MemSQL 등의 NewSQL을 선보이고 있다.


이 밖에 아마존 웹 서비스의 아마존 오로라(Amazon Aurora)가 MySQL 및 PostreSOL이 지원함에 따라 NewSQL의 일종으로 간주되기도 한다.


NewSQL 데이터베이스의 장점 중 하나는 전통적인 SQL데이터베이스에서 실행되는 응용프로그램이 지원된다는 점이다. 그러나 위 논문 저자들은 그러한 전통적인 데이터베이스에서 실행되는 작업은 보통 핵심 응용프로그램이므로 기업들은 강력한 요인이 없는 한 이를 새로운 데이터베이스로 이동하기를 꺼릴 것이라고 지적했다.


NoSQL 데이터베이스는 확장성이 뛰어나며 소셜, 모바일, 사물 인터넷 응용프로그램을 중심으로 하는 새로운 응용프로그램에 주로 사용될 전망이다. 


NewSQL 시장의 움직임을 주시하는 애널리스트들은 향후 몇 년간 무난한 성장할 것으로 낙관하고 있다. 마켓 어낼리시스(Market Analysis)에서는 NewSQL 데이터베이스 시장이 복합 성장률 26%을 기록하여 2020년까지 10억 달러 규모에 이를 것으로 예측하고 있다.


이는 IDC에서 연간 300억 달러 이상으로 보고 있는 전통적인 관계형 데이터 관리 시장 규모에 비하면 미미한 수준이다. 그러나 전통적인 데이터베이스에 고충을 겪고 있는 고객들이라면 새로운 작업을 위해 기꺼이 NewSQL에 투자할 것이라는 의미이기도 하다.




.


반응형
반응형

MySQL 클론의 역습 – 1 (MariaDB 편)  https://mariadb.org/


https://embian.wordpress.com/2013/06/26/mysql-%ED%81%B4%EB%A1%A0%EC%9D%98-%EC%97%AD%EC%8A%B5-1-mariadb-%ED%8E%B8/


사실 이 글의 제목을 처음에는 “MySQL의 형제들” 이었다.


source가 fork된것이니 형제보다는 부모 자식 관계가 더 맞지 않을까 생각되서, “MySQL의 자식들”이라고 제목을 바꾸었다가 어감이 좋지 않아서 MySQL의 창시자가 자신의 첫째딸 이름을 따서 MySQL이라고 작명한 것에 착안해 “MySQL의 딸들”이라고 바꾸었다.


그런데, 그만 코드가 복제되서 다시 분화된 것인데 이것을 부모 자식간이라고 해야 하나 형제간이라고 해야 하나 쓸데없는 고민에 빠져버렸다.


결국, 장고 끝에 제목은 “MySQL 클론의 역습”이라고 결정했다. (그런데 실제로 MySQL과 클론들끼리 정말 싸우지는 않는다. 심지어 그들 간은 사이가 좋아 보이기 까지 한다.)


헛소리는 여기까지 하고 본문으로 들어가 보자. ^^;


우리나라에서 DB라고 하면 Oracle 아니면, MySQL이다. 특히 웹서비스 환경은 MySQL이 현재까지도 대세라고 할 수 있다.


최근들어 NoSQL이니 BigData니 하는 새로운 페러다임과 프로그램들이 등장하면서 광풍의 조짐이 보이고는 있지만, 여전히 사용함에 있어서는 제한적이고 진입장벽이 만만치가 않다.


아직까지 DB의 메인스트림은 RDBMS이고, 새로운 웹 프로젝트가 진행되면, 당연하듯 DBMS로는 MySQL이 거론되곤 한다.


사실 좀 지루했었다.


뭔가 MySQL이 아닌 새로운 것을 만지고 싶었을 뿐이었다.


그래서 어떤 프로젝트에서 Postfix를 도입해 볼까 하다가 MySQL에 익숙한 엔지니어들과 개발자들의 반대에 부딛혀야 했고,  본인 스스로도 딱히 그 프로젝트에서 Postfix를 써야 할 당위성을 찾기도 힘들어서 포기한적이 있다.


최근 모바일 게임 관련 프로젝트를 진행하면서 MySQL에서 fork된 몇가지 DBMS들을 만져볼 수 있게 되었다. 이해 당사자도 적고, 약간 도전적인 프로젝트이다 보니 아무런 태클 없이 혼자서 자유롭게 DBMS를 선택할 수 있는 기회였다.


이 글은  그 때 research 했던 MySQL fork program 들에 대한 간단한 소개 글이다.


MySQL이 Oracle에 편입된 후, MySQL의 향후 운명에 대한 우려의 목소리가 많아졌다.


이러한 우려 속에서 MySQL의 대안을 찾으려는 움직임이 많아지고 있는데, 그것들 중 대표적인 것으로 MySQL에서 fork된 프로젝트들을 꼽고 싶다.


이 글에서는 MySQL fork 프로젝트들 중 가장 많이 알려진 세가지 프로젝트에 대해서 정리 하려고 한다.


1. MariaDB


MariaDB 의 주요 개발자는 Michael Monty Widenius라는 사람으로 MySQL을 개발했던 사람이고, 그 MySQL을 Sun에 10억 달러(약 1조원)에 매각하면서 핀란드 10대 부자중 한 명이 된 사람이기도 하다.


하지만 MySQL을 인수했던 Sun이 다시 Oracle로 인수되자, Monty Program AB이라는 회사를 설립하고 MySQL의 소스를 기반으로 MySQL과 완벽하게 호환이 되는 DBMS를 개발 하는데, 이것이 MariaDB이다.


MySQL, MariaDB 둘 다 Monty의 딸 이름을 따서 만들었는데 MySQL은 첫째 딸, MariaDB는 둘째딸의 이름에서 따론 것이라고 한다.(딸바보인가보다)


MariaDB는 MySQL의 소스를 가져다 만들기도 했지만, 목표자체가 MySQL을 완벽하게 대체하는 것이다 보니, 기존 MySQL과 완벽하게 호환이 된다.


프로그램의 룩앤필도 거의 똑같고 지원하는 함수들도 모두 일치하며 심지어 파일 이름들도 그대로 MySQL의 것을 가져다 쓰고 있다.


개발자들이 그냥 보기에는 이게 MariaDB인지 MySQL인지 모를 정도이다. (Client의 프롬프트가 “MariaDB” 로 뜨는 것 말고는 정말 똑같다.)


당연히 php-mysql 이라던지, jdbc-mysql-connector같은 기존 db connection library도 그대로 사용할 수 있기 때문에 실제로 개발자들은 MySQL에서 MariaDB로 DB 서버가 바뀐다고 해도 전혀 소스코드 수정이 필요없으며, 추가적인 DBMS에 대한 학습도 거의 필요가 없다.


즉, MySQL을 다룰줄 아는 개발자라면 MariaDB의 진입장벽은 거의 없는 수준이라고 할 수 있다.


하지만, MySQL을 완벽하게 대체한다는 사실만으로 기존에 MySQL을 잘 사용하던 사람들이 막연한 불안감이나 새로운 프로그램에 대한 단순한 호기심만으로 MariaDB로 갈아타지는 않을 것이다.


그럼 MySQL 대신 MariaDB를 썼을 때 얻을 수 있는 잇점들은 어떤 것이 있을까?


첫번째 장점은 월등히(?) 빠른 쿼리 타임을 들 수 있다.


인터넷이 돌아다니는 다양한 퍼포먼스 테스트 결과를 보면 전반적인 쿼리 성능이 MySQL에 비해 좋은 것을 알 수 있다.


특히, sub query나 join query 같은 경우 따로 MariaDB의 특징으로 소개할 만큼 성능 향상이 있다.


그리고 본인이 직접 테스트한 결과에서는 Partitioning table에 대한 select 쿼리 결과가 특히 눈길을 끌었는데, 자세한 테스트한 결과는 따로 추가 글을 작성할 예정이다.


두번째 장점은 다양한 추가 기능들이다.


이 글에서는 다양한 추가 기능들중 몇가지만 소개하고자 한다.


1. Microseconds in MariaDB


테이블을 생성할 때 시간관련 자료형에 정밀도를 설정 할 수 있다.


CREATE TABLE example(


col_microsec DATETIME(6),


col_millisec TIME(3)


);


정밀도는 0부터 6까지 설정할 수 있으며, 설정된 값만큼의 microseconds가 출력된다.


SELECT CURTIME(4);


–>10:11:12.3456


2. Microseconds Precision Processlist


INFORMATION_SCHEMA.PROCESSLIST 테이블에 TIME_MS 컬럼이 추가 되었다.


processlist를 볼때 MySQL에서는 실행타임이 초단위까지 밖에 나오지 않았다면 MariaDB에서는 microseconds 단위까지 확인 할 수 있다.


3. Table Elimination


여러개의 table 조인으로 구성된 쿼리의 경우, 사용하기 편하기 view table을 따로 구성하기도 하는데, view table에서 특정 컬럼을 select할 경우 실제로 조인된 table들중 쿼리에 필요 없는 테이블이 발생할 수 있다.


MariaDB는 이런 경우 자동으로 쿼리에 필요 없는 테이블을 조인쿼리에서 제거해주는 기능을 가지고 있다. (이 특징은 성능 향상쪽에 가까운것 같기도 하다.)


4. Virtual Column


다음의 테이블 스키마를 보자.


create table table1 (


-> a int not null,


-> b varchar(32),


-> c int as (a mod 10) virtual,


-> d varchar(5) as (left(b,5)) persistent);


table1의 c 컬럼은 가상컬럼이다. 실제로 storage에 저장되지 않고 query 실행시간에 계산되어 출력된다.


table1의 d 컬럼은 실제로 storage에 저장이 되는 가상컬럼으로, insert나 update 때 계산되어 저장 되는 컬럼이다.


더 많은 추가 기능들이 있는데, 추가기능에 대한 설명은 여기에서 확인 할 수 있다.


한가지 주의할 점은 MariaDB의 추가 기능들을 사용할 경우 혹시라도 부득이하게 MySQL로 돌아가야 될 경우 호환이 안될 수도 있다는 점을 유의해야 한다.


마지막으로 MariaDB는 다양한 Storage Engine을 지원한다.


1. Aria


Aria 엔진은 MyISAM과 호환되면서 추가적으로 Transactional기능이 추가된 Engine이다.


2. XtraDB


InnoDB의 대체 Engine으로 다음에 설명할 Percona사에서 개발한 Storage Engine이다.


3. PBXT


일반적인 목적의 transactional storage engine으로 현재 더이상 maintaine 되지 않고 있어서 MariaDB에 기본 탑제되어 있지 않지만, 필요한 경우 재컴파일을 통해 사용할 수 있다.


4. FederatedX


Federated Storage Engine의 fork engine으로 Federated engine은 원격 서버의 table에 접근해서 Insert, Update, Delete, Select 를 할 수 있도록 해주는 engine이다.


5. OQGRAPH


Open Query Graph storage engine의 약자로 트리나 그래프 형태로 출력될 수 있도록 데이터를 저장하는 engine이다.


6. IBMDB2I


MySQL 5.1.55에서 빠졌던 엔진인데, MariaDB에서는 아직까지 지원하고 있다.


7. SphinxSE


Full Text Search Engine 으로 Full Text Search가 필요한 경우 사용할 수 있을 듯 하다.


8. Cassandra in MariaDB-10.0


NoSQL DBMS인 Cassandra cluster에 MariaDB를 통해 접근 할 수 있도록 10.0 버전에 추가되었다.


3가지 측면에서 MariaDB의 장점에 대해서 설명했는데, 개인적으로는 첫번째 장점인 성능 향상 만으로도 MariaDB를 쓰는 이유는 충분한 것 같다.


본인 입장에서는 추가 기능의 필요성은 아직까지 피부로 와닿지 않았고, 추후 MySQL이나 Percona로 전환해야 될지도 모르는 이슈 때문에 전혀 고려대상이 되지는 못했다.



.

반응형
반응형
NoSql 활용 - 특징

 

- 다수의 사용자 요청을 빠른 시간 내에 모두 처리

- 서비스에서 읽기/쓰기 비율 중 데이터 쓰기 비율이 높음

- 저장된 데이터의 일관성이 중요하게 여겨짐

- 스키마가 없는 데이터 형태(schema-less)

- 네트워크 기반 분산 데이터베이스가 가진 확장성

 

* 저장과 처리 시간 주기에 맞춰 데이터 종류를 나누어 보자.

 - 빠른 주기로 빈번하게 저장 및 처리되는 캐시 영역의 데이터

     : 수 ms 단위로 데이터 처리

 - 일정 주기로 아카이빙돼 시점 복원이 가능하도록 관리되는 데이터

     : 수 분 이내로 이전 상태로 복구 가능한 데이터 처리

 - 일정 주기로 데이터를 집계해 게임 내에 다시 반영하는 데이터

    : 실시간 랭킹, 개인 요약 정보, 최근 아이템 교환 비율 등

 - 각종 사용자 이벤트 발생에 따라 그 이력을 관리하는 로그 데이터

 

* 저장형태에 따른 구분

 Key-value

 Ordered Key-value

 Wide Column Store

 Document

 Graph

 

* NoSQL - 어떻게 선택해야 할까? : http://platformadvisory.kr/archives/608

 

* 한 눈에 살펴보는 PostgreSQL : http://helloworld.naver.com/helloworld/227936

반응형
반응형

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

+ Recent posts