최근 연구 NoSQL 읽기 몇 가지 정보

올해의 가장 큰 프로젝트 중 하나를 완료 한 후 초점 그래서 NoSQL에 초점을 직장 밖에 서 약간의 시간이 오후 역할에서 저장소 관련 작업을 전환 했다 (주로 blog.nosqlfan.com)에서 정보를 관련

NoSQL 관련

[번역] NoSQL 생태계

Http://blog.nosqlfan.com/html/2171.html

이것은 최고의 가장 완벽 한 문서 NoSQL 본 적.

NoSQL의 나의 이해

http://www.dbthink.com/?p=687

기본적으로 간단한 kv 저장으로 타락 한 MySQL 작가 관점, 거 대 한 데이터를 얼굴에 동의

NoSQL 제품 분류 차트

Http://blog.nosqlfan.com/html/530.html

자동 샤 딩 이해 하지 않습니다.

대용량 데이터 처리-저장, MapReduce 및 쿼리의 SMAQ 아키텍처

Http://blog.nosqlfan.com/html/652.html

이 우리를 구현 하려고 했습니다 저장 검색의 통합 아닌가요?

카산드라를 HBase에 사용 되는 BigTable 모델

Http://blog.nosqlfan.com/html/704.html

마지막으로 무엇 인지 열 기반 스토리지 및 데이터 통합의 기술

일반 RDBMS와는 달리 일반적인 RDBMS는 일반적으로 연속 디스크 공간에 데이터의 한 행과 행 유형. 열 저장은 각 열의 순차 저장. 그래서 그것은 필드에 null 필드를 처리 하는 데 너무 많은 공간을 차지 하지 않습니다. 또한 유연 하 고 느슨하게 정의 된 열 정의 지원할 수 있습니다. 그건 우리가 일반적으로 스키마 없는 전화.

NoSQL 이론-메모리는 새로운 하드 드라이브, 하드 디스크는 새 테이프

Http://blog.nosqlfan.com/html/683.html

NoSQL 저장소의 초석

NoSQL에 대 한-우리가 왜 스토리지의 쓰기 성능을 최적화 하 시겠습니까?

Http://blog.nosqlfan.com/html/737.html

장소에 NoSQL에 대 한 생각은 현상을 통해 본질을 보면,

NoSQL의 제품의 많은, 우리가 벤치 마크를 통해 볼 수 있는 것 이다 매우 높은 쓰기 성능 읽기 성능에서 상당한 이득을 아니 또는 심지어 전통적인 RDBMS에 감소.

SSD 기반 데이터베이스 성능 최적화

Http://blog.nosqlfan.com/html/917.html

임의로 읽기 키-값의 큰 숫자, SSD의 변화는 일반적으로 향상 시킬 수 있습니다 TPS 약 10 배 시간, 응답 시간은 기본적으로 1/4로 감소 된다

NoSQL의 필요한 수치에 대해 자세히 알아보기

Http://hi.baidu.com/pkugsis/blog/item/99358dcb347bb5f153664fff.html

NoSQL의 기본 서류, 그리고 신중 하 게 그들을 읽을 시간이 있다.

Redis 관련

날카로운 Redis

Http://blog.nosqlfan.com/html/129.html

보고 해야 합니다 시작 하기

Redis 동시성 성능 테스트 벤치 마크

Http://blog.nosqlfan.com/html/538.html

최대 120000, 독립 실행형 인지, 모르는 번호 4 k 감소, 시작 하지만 천천히 동시 TPS 또는 QPS는

Redis에 몇 가지 오해

Http://blog.nosqlfan.com/html/868.html

AOF 목표로 주로 데이터의 신뢰성 및 높은 수준의 가용성, Redis에 목표를 달성 하기 위해 다른 방법이 있다: 복제. Redis의 높은 성능, 복제에서 지연이 있다. 이 실패의 단일 지점 및 고가용성 구현 예방을 달성 한다.

Mogodb 관련

간단한 MongoDB

Http://blog.nosqlfan.com/html/219.html

PPT 잘, 그것은 ^_^ 학습 가치가

MongoDB MapReduce

Http://blog.nosqlfan.com/html/469.html

맵 리듀스 비교 전체 참조

(I) 자국의 MongoDB

Http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_1.html

그것은 매우 간단 합니다.

성능 테스트: sql 서버 대 MongoDB

Http://blog.nosqlfan.com/html/484.html

결과 MongoDB는 SQL 서버 보다 약 10 배 배, 업데이트는 약 20 배 배 빠른, 두 배 빠른에 대 한 선택 이다.

MongoDB에서 인덱스의 사용

Http://blog.nosqlfan.com/html/271.html

MongoDB의 인덱스는 매우 상세한 하지만 MongoDB의 인덱스는 RDBMS 인덱스 처럼 아주 많이 때문에 이해 하기 쉽습니다.

MongoDB 클러스터

Http://blog.nosqlfan.com/html/544.html

딩, MongoDB 쿼리 데이터 병합 과정을 작동 합니까 여러 노드에서 배포 하는 경우?

정사각형 최대 11 시간의 가동 중지 시간

Http://blog.nosqlfan.com/html/696.html

부서진된 카산드라 신화, MongoDB는 또한 문제가 있다, NoSQL 여전히 킹? 또는 아무 다이아몬드입니다.

HBase 관련

HBase와 함께 시작 하기

http://labs.chinamobile.com/mblog/4110_22332

그것은 정말 읽기 쉬운, 주로 열, 열 faimly 이해

HBase 소개

http://www.tbdata.org/archives/1509

잘 쓰기, 읽기 많은 것 들, 하지만 여전히 많은 질문

hbase-소개

Http://www.doc88.com/p-80782858011.html

외국인의 HBase 소개, 기억 한 지점: 태그, 하지만 값 길이 크기를 될 수 있는 열을 이해 하 고

Oschina hbase 데이터 요약

Http://www.oschina.net/question/tag/hbase

HBase 관련 콘텐츠는 또한 많은, 본적

HBase에 대 한 PPT

Http://blog.nosqlfan.com/html/464.html

그것은 매우 상세한, 아마 내가 이해 해 서 같은.

HBase 수준 2 인덱스와 조인

Http://kenwublog.com/hbase-secondary-index-and-join

난 모르겠어요, 하지만 HBase의 지원 수준 두 인덱싱에 대 한 매우 어렵습니다 볼 수 있습니다.

HBase와 카산드라의 주요 디자인 아이디어의 비교

Http://kenwublog.com/cassandra-and-hbase-design-pattern-compar