RDBMS의 SP처럼 MongoDB에는 Java Script로 저장 함수를 만들어서 사용 할 수 있다.

각 데이터베이스의 Function에 만들고, eval() 함수로 호출해서 사용한다.


db.system.js.save(

                   { _id: "echoFunction",

                     value : function(x) { return x; }

                   }

                 )


db.eval( "echoFunction( 'test' )" )



- 2.4 버전까지는 성능 상의 문제로 추천하지 않는다.

http://docs.mongodb.org/manual/tutorial/store-javascript-function-on-server/

http://stackoverflow.com/questions/15660161/why-is-it-not-recommended-to-use-server-side-stored-functions-in-mongodb


- 이유는 eval를 사용하면 자바스크립트 코드로 동작하고, 이 SP가 호출 후 끝날 때까지 lock이 걸려서 다른 작업을 할 수 없게 된다.

- 지금은 비추하는 기능이지만 근래 MongoDB의 자바스크립트 라이브러리가 V8 엔진으로 바뀌어서 장래에는 쓸만하지 않을까 예상한다.

- 게임 서비스 도중에는 사용하기 부담스럽겠지만 서비스 이외에 관리 측면에서는 자주 사용하는 기능을 Function으로 만들어 놓고 사용하면 편리 할 것 같다.

- 당연하지만 SP에서 컬렉션 조작도 할 수 있다.


db.eval( function(name, incAmount) {

    var doc = db.myCollection.findOne( { name : name } );

    doc = doc || { name : name , num : 0 , total : 0 , avg : 0 };


    doc.num++;


    doc.total += incAmount;


    doc.avg = doc.total / doc.num;


    db.myCollection.save( doc );


    return doc;

 },


 "eliot", 5 );





Mongo Shell 에서 사용하기


같은 database에 있는 function을 호출 할 수 있다.



MongoDB의 쿼리 명령어도 사용 할 수 있다.





저작자 표시
신고
by 흥배 2016.11.14 08:00

개요

- NoSQL용 SQL 쿼리 엔진으로, 파일 시스템 상의 JSON/CSV/Parquet 등의 파일, Hive 소스, HBase, MongoDB 등에 직접 SQL 쿼리를 던질 수 있다.

- http://drill.apache.org/

- 멀티플랫폼 지원.



Windows 설치 및 시작

- 다운로드 후 아래 처럼 압축을 푼다.

- bin 디렉토리에서 아래 명령어 실행

    - sqlline.bat -u "jdbc:drill:zk=local"

    - 위 명령어는 임베디드 모드로 실행한다는 뜻. 즉 하나의 컴퓨터에서 실행.

- 종료는 !quit



MongoDB 사용하기

- 실행한 후 http://localhost:8047 를 웹브라우져로 연다.

- Storage 탭에서 MongoDB 연결 설정을 한다.

Storage 탭


MongbDB 설정


- 콘솔 화면(클라이언트 실행)에서 show databases; 를 실행한다.

    - MongoDB 설정이 올바르게 되었으면 데이터베이스 이름 중 mongo. 가 붙은 것이 보인다.

- 데이터 베이스 선택

    - user mongo.GameDB;

- 테스트 용 쿼리 실행

    - select * from user limut 10;




웹브라우져로 쿼리 실행하기

- Apache Drill을 원격 서버에 실행한 후 웹브라우져를 통해서 쿼리를 실행한다.

- mongo.데이터베이스.컬렉션 을 모두 입력해야 컬렉션에 쿼리할 수 있다

저작자 표시
신고
by 흥배 2016.10.31 08:00

출처: https://www.infoq.com/news/2016/05/bowers-lessons-learned-nosql

주로 NoSQL을 처음 도입할 때 어떻게 해야 하냐의 이야기에 가깝다.

 

….

 

NoSQL 데이터베이스의 채용에는  NoSQL을 지지하는 지도자와 개발자 및 경영진의 적극적인 관여가 필요하다.

 

교훈 1:

NoSQL을 지지하는 리더가 조직에 있을 것: 조직 전체에 영향력을 갖고 기업 내의 개발자뿐만 아니라 경영진을 납득시키는 인물의 존재가 필수적이다.

 

교훈 2:

경영진의 적극적 관여를 얻을 것: 대기업 경영진은 기업용 상용 데이터베이스를, 신흥 기업의 고위 관리직은 오픈 소스 데이터베이스를 각각 좋아하는 경향이 있다. NoSQL 인수 팀이 NoSQL데이터베이스를 도입하려면 조직의 관리 계층의 개입이 필요한 것이다.

 

교훈 3:

개발자의 적극적 관여를 얻을 것: 개발자에게 NoSQL이 다양한 데이터 구조를 지원하고 애자일 개발을 실현할 것임을 보여야 한다.

/값 데이터베이스가 고 성능을,

와이드 컬럼 데이터베이스가 인터넷 레벨의 스케일링을 제공하는 것에 대해,

문서 NoSQL 데이터베이스는 단기간에 앱 개발을 실현하는 것이다

라고 그는 지적한다.

 

교훈 4:

훈련, 훈련, 훈련: 개발자가 NoSQL에 익숙해지는 것이 무엇보다 중요하다.

기술을 수반하지 않는 NoSQL 도입 활동은 편리한 훈련대에 불과하다.

 

 

그가 권하는 방법은 NoSQL을 사용한 현실적인 솔루션을 단기간에 저렴하게 구축하고 그것을 성공의 실례로 상층부에 알리는 것이다. 데이터베이스 라이선스와 개발 비용의 감소, 확장성 향상이라는 목표를 실증하는 데 의미가 있다.

 

그는 높은 대역 폭, 저 레이턴시, 분석성, 운용성, 볼륨, 속도 같은 요건에 대해서 다른 데이터베이스와 비교하는 방안도 제안했다. 데이터 모델의 유연성, 퍼포먼스, 혹은 수평 측정 가능성 등, NoSQL 데이터베이스 채용의 원동력이 될 수 있는 팩터를 그 안에서 찾아내는 것이다.

 

의사 결정 프로세스에는 팀 전체의 집단 소유권이 있기 때문에 NoSQL 데이터베이스의 채용은 팀 내에서 합의하는 것은 불가피하다.

 

저작자 표시
신고
by 흥배 2016.09.09 08:00

이 문서는 NEXT의 게임 클라이언트/서버 과정 학생이 정리한 것이다. 



저작자 표시
신고
by 흥배 2016.06.27 08:00

Cassandra 사용 사례

- 애플은 지난해 iCloud 등에 저장된 10 페타바이트의 데이터를 7 5000 노드로 구성된 Cassandra에서 운용하고 있다고 발표했다.

- Netflix에서도 2500 노드에서 420 테라바이트의 데이터를 운용하고 있다고 발표 발표했다

(위 사례는 Apache Cassandra Web 사이트 메인 화면에서 소개되고 있다).

- 또 세계적으로 금융 사업을 전개하는 ING 그룹도 온라인 결제 시스템에 Cassandra를 채용하고 있다.

 

 

Cassandra의 최신 버전인 "Cassandra 3.0"이 출시되었다.

Cassandra 3.0에서는 스토리지 엔진 코드가 리팩토링 되어 CQL에 최적화되어 효율이 좋아졌고, 새로운 materialized views 기능이 탑재되었다.

v3.0은 성능과 최적화 측면에서 이 데이터베이스의 혁신의 새로운 이정표가 되었다. 데이터 일관성의 조작을 개선하고 평균 데이터 보존영역을 50% 삭감, 새로운 materialized views 등의 기능은 애플리케이션 개발을 아주 쉽게 해줄 것이다.

 

뷰는 실 테이블에서 작성되는 가상적인 테이블. materialized views는 가상 테이블에 데이터를 cache로 가지므로 실제 테이블에 액세스 할 필요가 없으므로 고속으로 값을 얻을 수 있다.

Cassandra 3.0materialized views에서는 실 테이블의 데이터에 변경이 있는 경우 결과 정합성을 유지하면서 그 변경을 서버 측에서 가상 테이블(materialized views)에 반영한다.

예를 들어 게임의 하이 스코어를 저장할 테이블을 materialized views로 작성한 경우, 애플리케이션에서 그 뷰를 참조하면 언제나 최신의 하이 스코어를 얻을 수 있다.

 

그 외 Cassandra 3.0에서는 사용자 정의 함수, Windows에서의 시험 등도 포함된다.

 

자세한 것은 The Apache Software Foundation announces Apache™ Cassandra™ v3.0

(https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces82)

 

 

 

출처: http://www.publickey1.jp/blog/15/nosqlcassandra_30.html

저작자 표시
신고
by 흥배 2015.11.16 08:00

3.22015년 말에 나올 예정이다.

 

 

도큐먼트 검증

도큐먼트 내용에 검증(키 이름과 값 체크)을 걸 수 있다.

예를 들면

{age: {$gte:0,$lte:150}}

age 0~15사이의 값인지 체크.

 

 

부분적 인덱스

문서 속의 한 값에 따라 인덱스에 포함시킬지를 나눌 수 있다.

예를 들어 사용자 도큐먼트 속에 활성화, 비 활성화 플래그가 있어서 적극적인 사용자만 검색하는 요건인면 비 활성 플래그의 데이터는 인덱스에 포함시키지 않을 수 있다. 이것에 의해 메모리를 효율적으로 이용할 수 있다.

 

 

스토리지 엔진의 추가

지금까지는 MMAP WiredTiger뿐이었지만 새로 인 메모리스토리지 엔진과 암호화할 수 있는 스토리지가 추가된다.

단 암호화 스토리지는 유상 Enterprise 판에만 있는 것 같다.

 

 

BI 툴과 커넥터

BI 툴과 커넥터가 붙을 것 같다. 예상으로는 Tableau 일듯.

 

 

config 서버가 레플리카 셋에

지금까지는 config 서버는 mongod 3대에서 2 PC에서 경신했지만 앞으로는 비 권장되고 대신에 레플리카 셋에서 config를 구축한다.

 

 

Javascript의 엔진이 또 Spidermonkey

지금은 Javascript 엔진은 V8이지만 Spidermonkey이 된다.

분명히 2.4에서 Spidermonkey에서 V8로 바뀌었는데 다시 돌아온 것이 된다.

 

 

mongodump mongorestore가 압축&스트림 전송 대응

mongodump mongorestore가 압축에 대응한다. 또한 원격의 mongod에 대해서 dump한 데이터를 스트림으로 전송 하고 restore 할 수 있게 된다.

 

 

aggregation framework 개량

aggregation framework에 많은 오퍼레이터가 추가되었다. 너무 많아서 생략.

 

 

전문 검색의 개선

전문 검색이 영어 이외에 대응했다! 하지만 유감스럽게도 일본어는 대응하고 있지 않는다.

추가된 언어는 아라비아어, 페르시아어, 우르두어 중국어이다.

외에도 몇 가지 개선이 있는 것 같다.

 

 

새로운 CRUD API

지금까지 CRUD는 한번의 쿼리로 갱신되는 문서 수가 하나이거나 복수여서 알기 어려웠는데 새로운 API가 추가되었다.

예를 들어 update()의 경우 하나를 경신하는 updateOne()이나 복수를 경신하는 updateMany()를 대용할 수 있다.

외에도 findAndModify()도 알기 어려웠으므 갱신으로 치환과 삭제 3개의 대용 API가 생겼다.

 

 

Ops Manager( MMS)개선

파일 시스템의 백업, 쿼리 프로파일링, 인덱스의 시사, 그리고 레플리카 전체의 인덱스를 롤링 업데이트할 수 있게 되었다.

 

 

 

출처: http://qiita.com/fetaro/items/907f4a8791ffb24df9bb

 

저작자 표시
신고
by 흥배 2015.11.06 08:00

데이터를 둘러싼 환경의 변화

데이터 볼륨 확대화 → Google이나 Facebook의 보유 데이터가 페타 바이트 급으로

데이터 처리 응답 속도가 중요 → Web 사이트의 방문자 수가 초당 10 만 액세스

데이터의 다양성비 구조 데이터가 많아지고 있기 때문에 RDBMS으로 저장이 곤란

 

RDBMS의 현황

확장 성 한계에 도달

비정형 메타 데이터 관리가 어려워

빅 데이터화

데이터베이스의 변경에 중지가 따른다

처리에 많은 시간이 걸렸다( : EC 사이트에서 제품 카탈로그 업데이트 12 시간)

상용 RDBMS는 스케일 업이 너무 비싸다

스키마 재정의에 공수가 너무 많이 소요된다

 

 

NoSQL 등장

NoSQL의 특징은 다음과 같다.

- 비 구조 데이터의 취급이 용이하다

- 수평 분산이 용이하다(결과 무결성)

RDBMS "강한 일관성'을 유지하기 위해 수평 분산이 머리 아프다.

 

 

Hadoop의 차이

Hadoop의 특징은 다음과 같다.

- 배치 분산 처리가 용이하다

- 사전에 데이터를 넣을 수 있다

- 응답 속도보다는 전체의 처리를 우선한다

 

 

NoSQL 분류

KVS

- 키 밸류 형 ... redis, memcached, Oracle Coherence,

- 열 지향 와이드 컬럼 스토어 ... Cassandra, HBASE, Cloud Datastore

 

문서 형

MongoDB, Couchbase, MarkLogic, PostgreSQL, MySQL, DynamoDB MS-DocumentDB

 

그래프 형

Neo4j

 

유행했던 Hadoop은 이미 철이 지났다. 문서 형, 키 밸류 형이 현재이고, 그래프 형은 앞으로.

 

 

KVS

redis

장점

redis3에서 샤딩이 가능

배열에 PUSH, POP 가능

PUB, SUB 가능

트랜잭션 가능

 

단점

메모리 크기 이상 사용할 수 없다

디스크에 미리 쓰기는 할 수 없다

자동로드 밸런싱을 할수 없다

 

Cloud Datastore

장점

데이터 구조에서 엔티티의 부모-자식 관계를 가질 수 있다

부분적인 트랜잭션을 할 수 있다같은 엔티티 그룹 내에서 가능 (강한 무결성) → 다른 엔티티 그룹과도 결과 무결성

 

단점

Not 하나 밖에 할 수 없다

정렬을 먼저 해야 한다

 

 

HBASE

장점

HDFS가 필수 (등장 인물이 많다)

Hadoop과 궁합이 좋다

강한 일관성을 가진다

데이터 압축이 가능하다

 

단점

5 대 미만에서는 사용할 수 없다 (대규모 전용​​)

단독으로 전개 할 수 없다(Hadoop Zookeeper )

 

 

cassandra

특징

DynamoDB와 같은 수평 분산 방식

CQL SQL스럽게 다룰 수 있다

 

 

 

문서 유형

mongoDB

※ 소규모 용

장점

SQL 이상의 집계 쿼리(MS-DocumentDB와 더불어 최강)

역할 기반 액세스 관리

대량 데이터 처리

실시간으로 질의 생성

 

단점

트랜잭션을 할 수 없다

다중 마스터 업데이트

 

 

couchbase

※ 대형 전용

장점

다중 마스터

CRUD MapReduce(사전에 정한 쿼리)

GUI 콘솔이 제공된다

 

단점

임시 쿼리

 

 

DynamoDB

장점

최근에는 JSON을 지원(드라이버가 흡수)

다른 AWS 서비스와의 연계

 

단점

집계 정렬, JSON 검색을 할 수 없다

인덱스가 비동기, 수에 제한

 

 

Microsoft DocumentDB

장점

SQL과 흡사한 쿼리

자동 인덱싱

트랜잭션 지원

형 검사

 

단점

집계, 정렬을 할 수 없다

복수 인덱스를 할 수 없다

Azure에서만 사용할 수 있다

 

 

MarkLogic

특징

원래는 XML, RDF 트리플, 최근 JSON

XQuery 가능

분류 표시, 드릴 다운 가능

트랜잭션 가능

액세스 관리, 감사, 경고가 가능

 

 

 

그래프 형

Neo4j

장점

노드관련노드 (JSON으로 표현)

Cypher

GUI가 멋지다

 

단점

수평 분산을 할 수 없다

커뮤니티 버전은 GPL 라이센스

 

 

 

NoSQL 판별 방법

흔히있는 캐치 프레이즈는 패스해도 OK

 

차별화되는 요소

- 데이터 구조

- 응용 프로그램의 인터페이스

- 트랜잭션

- 보조 인덱스 복합 인덱스

-쿼리 (정렬, 한계, 데이터의 부분 업데이트 집계)

- 다중 마스터 복제

- 액세스 권한 관리

- 학습 비용 (문서의 양 노하우가 많음)

 

성능의 단순 비교는 할 수 없다

원래 일관성과 인터페이스가 통일되어 있지 않다

→ NoSQL 성능 비교 보고서는 그다지 맞지 않다(쿼리에서는 MySQL 쪽이 빠를 수 있다)

 

최신 정보를 확인하기

 

 

출처: http://dev.classmethod.jp/event/dbtechsowcase-tokyo-2015-e-22/

 

저작자 표시
신고
by 흥배 2015.06.18 08:00

우연찮게 알게 된 NoSQL 이.

SSD에 최적화 되어 있으며 기존 NoSQL에 비해 10배의 성능 향상이 있다고 한다.

그리고 In-Memory 타입으로도 사용 가능해서 Redis 대신으로 사용 가능하다.

 

공식 사이트: http://www.aerospike.com/

 

일반적인 NoSQL형 데이터베이스의 10, SQL형 데이터베이스의 100배 성능을 실현.

 

Aerospike는 인 메모리형 실시간 NoSQL데이터베이스. RAM 상에 인덱스를 SSD상에 데이터를 배치하는 유연성 높은 인 메모리 기술을 가지고 있으며, 대규모 데이터를 실시간으로 고속으로 처리할 수 있다.

 

확장성도 높고, ACID 지원과 다운 타임 제로라는 특징도 있다.

 

서버 측은 하이브리드형 메모리 시스템과 실시간 엔진을 바탕으로 그 위에서 스마트 클러스터와 데이터 센터 레플리케이션 기능이 동작한다. 노드를 추가하면 자동으로 데이터의 재배치와 부하 분산이 행해져 샤딩이나 수동으로 조작과 설정을 할 필요가 없다.

복수의 데이터 센터를 사용한 클러스터 구축도 가능.

서버 측 모니터링 시스템도 제공.

 

소스 코드도 공개 되어 있다. 공개된 것은 Aerospike Community Edition(CE)판 버전 3.3.5.

서버 및 클라이언트의 양쪽 모두의 코드가 공개되어 있다.

라이센스는 서버 측이 GNU AGPL, 클라이언트 측이 Apache License 2.

기술 지원이 추가된 Enterprise Edition도 있다.

 

 

특징

Key Value Store

OSS

CAP 정리에서 AP

AWS에서는 AMI도 있음.

SSD 최적화

기존 KVS 보다 10배 빠르다

SSD & 메모리 뿐만이 아닌, 메모리만, 메모리&디스크 타입도 있다.

현재 광고업계에서 다수 사용 사례가 있다.




 

아키텍처 중 일부

스키마 레스

RDBMS에 비교하면

database=namespace

table=set

row=record

colum=bin

병렬 지향의 데이터 층을 가지고 있다.

Partition

데이터는 클러스터 내에 4096의 파티션으로 분할 되어 골고루 배치.

예를 들어 노드 4개이면 1 노드에 1024의 파티션이 존재.

데이터의 액세스는? 가용성은?

대부분의 상황에서 데이터에 접속을 1 홉임을 보증.

파티션 정보를 항상 클라이언트 측에 보냅니다. 이 정보를 파티션 맵이라고 부른다.

1대 서버가 고장 나서 마스타 데이터가 없어진 경우, 레플리카 데이터의 위치를 파티션 맵에서 산출할 수 있다.

 

 

SSD & Memory형 이용

키 자체는 메모리에도 SSD에도 저장되지 않는다.

키는 해시화 되어 1 레코드 64 바이트의 인덱스로 메모리 상에 보존

요컨대 Memory 사용량은(레코드 수 * 64바이트)이므로 Memory는 설계하기 쉽다.

애매한 HWM(HighWaterMark). default 60%로 이것을 넘는 것은 소프트웨어적으로 성능을 보장하지 않는다. 넘으면 낡은 것을 지워 나간다. 낡은 것을 지워서라도 계속 동작하려고 한다.

넘어서는 안 될 SW(StopWrite). 넘었을 경우 이후 기록할 수 없다. ReadOnly 상태.

 

 

지원 OS

현재 리눅스 플랫폼만 지원한다.

 

클라이언트 라이브러리 언어

Java, C#, C, Go, PHP, Python, Ruby, Perl, Erlang, Node.js

 

Redis vs Aerospike

http://www.slideshare.net/sunilvirus/redis-vs-aerospike

 

Aerospike on Amazon EC2에서 100 TPS를 단 1.68 달라/시 로 실현하는 방법

http://highscalability.com/blog/2014/8/18/1-aerospike-server-x-1-amazon-ec2-instance-1-million-tps-for.html

 

라이센스

오픈소스와 상업용 두 가지 버전이 있음.

오픈소스용을 사용할 때는 사용한 소스를 공개해야 한다(즉 오픈소스 프로젝트에 사용에 적합)

http://www.aerospike.com/products-services/

 

 

 

 

저작자 표시
신고
by 흥배 2015.01.29 08:00

Store a JavaScript Function on the Server

  • RDBMS SP처럼 MongoDB에는 Java Script 저장 함수를 만들어서 사용 있다.
  • 데이터베이스의 Function 만들고, eval() 함수로 호출해서 사용한다.

 

 

db.system.js.save(

                   { _id: "echoFunction",

                     value : function(x) { return x; }

                   }

                 )

   

db.eval( "echoFunction( 'test' )" )

 

 

db.eval( function(name, incAmount) {

    var doc = db.myCollection.findOne( { name : name } );

   

    doc = doc || { name : name , num : 0 , total : 0 , avg : 0 };

   

    doc.num++;

    doc.total += incAmount;

    doc.avg = doc.total / doc.num;

   

    db.myCollection.save( doc );

    return doc;

 },

 "eliot", 5 );

 

Mongo Shell 에서 사용하기

  • 같은 database 있는 function 호출 있다.

  • MongoDB 쿼리 명령어도 사용 있다.

 

C#에서 사용

  • 아래와 같은 방법으로 사용할 있다. 그런데 값을 반환 받을 없다 -_-;

 

BsonValue bv = BasicLogDB.Eval("myAddFunction", 5, 5);

  • C#
에서 어떻게 사용할지 모르겠음 -_-;

신고
by 흥배 2014.03.14 08:00

1. 정기적으로 계측한다.

- Collection/Document 수 증감.

ex) db.usercollection.find.count()

ex) db.usercollection.stats()

 

- Disk 사용현환 파악

 

 

2. 정기적으로 백업

MongoDB 프로세스를 중단이 가능한 경우

=> 데이터 파일을 복사(OS 명령어)하면 OK(콜드 백업)

 

프로세스를 멈추지 못하는 경우

=> MongoDB의 툴인  mongodump 이용

 

 

3. 정기적으로 데이터 최적화

정기적으로 RepairDatabase 커맨드 실시

ex) mongod --repair

--repair 옵션 지정으로 프로세스 기동

 

ex) db.repairDatabase()

mongo 셀 상에서 명령 실행

 

이점

Disk 사이즈(데이터 파일) 축소

=> Insert/Delete 뿐인 Collection의 경우 실은 Mongo Document 안은 빵꾸가 생겨서 사용 효율이 쉽게 나쁘게 된다.

 

Index 최적화(Rebuild)

 

단점

시간이 걸린다. 모든 데이터가 대상이 된다.

서버에 그 시점의 데이터 파일 사이즈 이상의 빈 공간이 없으면 에러가 된다.

 

v2계에서 컬렉션 단위로 최적화 가능. Index rebuild 해 준다.

ex) db.collection.compact()

Disk 사이즈는 줄지 않는다.

 

 

4. 정기적으로 버전 업

성능. 기능 개선

Index 사이즈 Down

성능 Up

Journaling에 의한 내장해성 Up

버그 픽스 



5. 많은 동시 접속을 받을 수 있다.

PostgreSQL의 경우 보통 1000개 접속이 한계이지만 MongoDB의 경우 클라우드의 2GB 머신에서 20000 접속을 받을 수 있음.


저작자 표시
신고
by 흥배 2014.01.17 08:00
| 1 2 |

티스토리 툴바