NoSQL 을 시작 할 때 왜 NoSQL 을 사용 합 니까?
5999 단어 NoSQL
InfoQ 에서 NoSQL 에 관 한 칼럼 을 개설 하 게 되 어 매우 영 광 스 럽 습 니 다.InfoQ 는 제 가 매우 존중 하 는 기술 매체 입 니 다.또한 저 는 InfoQ 를 통 해 국내 에서 NoSQL 의 발전 을 추진 하고 저 처럼 관심 이 있 는 친구 가 가입 하고 싶 습 니 다.이번 NoSQL 칼럼 시 리 즈 는 NoSQL 을 전체적으로 소개 한 다음 에 NoSQL 을 자신의 프로젝트 에 적합 한 장면 에 어떻게 활용 하 는 지 소개 하고 성공 사례 도 적당 하 게 분석 할 것 입 니 다.NoSQL 을 성공 적 으로 사용 한 경험 이 있 는 친구 가 저 에 게 단서 와 정 보 를 제공 해 주 기 를 바 랍 니 다.
NoSQL 개념
웹 2.0 의 신속 한 발전 에 따라 비 관계 형,분포 식 데이터 저장 은 신속 한 발전 을 이 루 었 고 그들 은 관계 데이터 의 ACID 특성 을 보장 하지 않 는 다.NoSQL 개념 은 2009 년 에 제기 되 었 다.NoSQL 의 가장 흔 한 해석 은'non-relational'이 며,'Not Only SQL'도 많은 사람 이 받 아들 이 고 있다.('NoSQL 이라는 단 어 는 1998 년 에 경량급 관계 데이터 뱅 크 의 이름 으로 사용 되 었 다.)
NoSQL 은 우리 가 가장 많이 사용 하 는 당수 key-value 에 의 해 저장 되 었 습 니 다.물론 다른 문서 형,열 저장,도형 데이터 베이스,xml 데이터 베이스 등 도 있 습 니 다.NoSQL 개념 이 제기 되 기 전에 이런 데이터 베 이 스 는 각종 시스템 에 사용 되 었 으 나 웹 인터넷 응용 에 사용 되 지 않 았 다.예 를 들 어 cdb,qdbm,bdb 데이터베이스.
전통 관계 데이터베이스 병목
전통 적 인 관계 데이터 베 이 스 는 좋 은 성능 을 가지 고 안정 적 이 며 역사적 인 시련 을 겪 었 으 며 사용 이 간단 하고 기능 이 강 하 며 대량의 성공 사례 도 쌓 았 다.인터넷 분야 에서 MySQL 은 절대적 으로 앞장 서 는 왕 이 되 었 다.과장 되 지 않 게 MySQL 은 인터넷 의 발전 에 탁월 한 기 여 를 했다.
90 년대 에 한 사이트 의 방 문 량 이 많 지 않 았 기 때문에 하나의 데이터 베 이 스 를 이용 하면 쉽게 대처 할 수 있 었 다.그 때 는 정적 웹 페이지 가 더 많 았 고 동적 인 상호작용 유형의 웹 사이트 가 많 지 않 았 다.
최근 10 년 이 되자 웹 사 이 트 는 빠르게 발전 하기 시작 했다.뜨 거 운 포럼,블 로그,sns,웨 이 보 는 웹 분야 의 트 렌 드 를 이 끌 고 있다.초기 에 포럼 의 데이터 도 크 지 않 았 다.만약 에 인터넷 을 일찍 접 했다 면 그때 텍스트 형 으로 저 장 된 포럼 프로그램 도 있 었 다 는 것 을 기억 할 수 있 고 일반적인 포럼 의 데이터 가 얼마나 많은 지 상상 할 수 있다.
Memcached+MySQL
그 후에 방 문 량 이 증가 하면 서 거의 대부분 MySQL 구 조 를 사용 하 는 사이트 가 데이터 베이스 에서 성능 문제 가 발생 하기 시작 했다.웹 프로그램 은 기능 에 만 집중 하지 않 고 성능 도 추구 했다.프로그래머 들 은 데이터 뱅 크 의 압력 을 완화 시 키 고 데이터 뱅 크 의 구조 와 색인 을 최적화 하기 위해 캐 시 기술 을 대량으로 사용 하기 시작 했다.처음에는 파일 캐 시 를 통 해 데이터베이스 압력 을 완화 하 는 것 이 유행 하기 시 작 했 지만 방 문 량 이 계속 증가 할 때 여러 대의 웹 기 계 는 파일 캐 시 를 통 해 공유 할 수 없고 대량의 작은 파일 캐 시 도 비교적 높 은 IO 압력 을 가 져 왔 다.이때 Memcached 는 자 연 스 럽 게 매우 유행 하 는 기술 제품 이 되 었 다.
Memcached 는 독립 된 분포 식 캐 시 서버 로 서 여러 웹 서버 에 공 유 된 고성능 캐 시 서 비 스 를 제공 합 니 다.Memcached 서버 에 서 는 hash 알고리즘 에 따라 여러 대의 Memcached 캐 시 서 비 스 를 확장 합 니 다.그 다음 에 일치 성 hash 가 캐 시 서버 를 증가 하거나 감소 시 켜 재 hash 로 인 한 대량의 캐 시 실효 의 폐 해 를 해결 했다.당시 면접 을 보 러 가면 Memcached 경험 이 있다 고 하면 가산 점 을 받 을 것 이다.
Mysql 주종 읽 기와 쓰기 분리
데이터 베 이 스 를 기록 하 는 압력 이 증가 하기 때문에 Memcached 는 데이터 베 이 스 를 읽 는 압력 만 완화 할 수 있 습 니 다.읽 기와 쓰 기 는 하나의 데이터베이스 에 집중 되 어 데이터 베 이 스 를 감당 할 수 없 게 하고 대부분의 사 이 트 는 주종 복제 기술 을 사용 하여 읽 기와 쓰기 분 리 를 실현 하여 읽 기와 쓰기 성능 과 읽 기 라 이브 러 리 의 확장 성 을 향상 시 키 기 시작 했다.Mysql 의 master-slave 모드 는 이때 의 사이트 표지 가 되 었 다.
테이블 라 이브 러 리
웹 2.0 의 지속 적 인 고속 발전 에 따라 Memcached 의 고속 캐 시,MySQL 의 주종 복사,읽 기와 쓰기 분 리 를 바탕 으로 MySQL 메 인 라 이브 러 리 의 쓰기 압력 에 병목 이 생기 기 시 작 했 고 데이터 의 양 이 지속 적 으로 급증 했다.MyISAM 은 시계 자 물 쇠 를 사용 하기 때문에 높 고 보 내 면 엄격 한 자물쇠 문제 가 발생 할 수 있다.대량의 고 병발 MySQL 응용 프로그램 은 MyISAM 대신 InnoDB 엔진 을 사용 하기 시작 했다.또한 쓰기 스트레스 와 데이터 증가 의 확장 문 제 를 완화 하기 위해 분 표 라 이브 러 리 를 사용 하 는 것 이 유행 하기 시작 했다.이때 분 표 분 고 는 인기 기술 이 되 었 고 면접 의 인기 문제 이자 업계 에서 토론 하 는 인기 기술 문제 이다.바로 이때 MySQL 은 아직 불안정 한 표 분 구 를 내 놓 았 고 기 술 력 이 보통 인 회사 에 희망 을 가 져 다 주 었 다.MySQL 은 MySQL Cluster 클 러 스 터 클 러 스 터 클 러 스 터 클 러 스 터 를 출시 했 지만 인터넷 에서 성공 사례 가 거의 없고 성능 도 인터넷 의 요 구 를 만족 시 키 지 못 해 높 은 신뢰성 에 큰 보증 을 제공 했다.
MySQL 의 확장 성 병목
인터넷 에서 대부분의 MySQL 은 IO 집약 형 이 어야 합 니 다.사실은 MySQL 이 CPU 집약 형 이 라면 MySQL 이 성능 문제 가 있 을 수 있 습 니 다.최적화 가 필요 합 니 다.빅 데이터 양 이 높 고 병발 환경 에서 MySQL 응용 개발 은 갈수 록 복잡 해 지고 기술적 도전 성도 점점 커지 고 있다.분 표 분 고의 규칙 파악 은 모두 경험 이 필요 하 다.타 오 바 오 처럼 기 술 력 이 강 한 회사 가 투명 한 미들웨어 층 을 개발 하여 개발 자의 복잡성 을 차단 하지만 전체 구조의 복잡성 을 피 할 수 없다.라 이브 러 리 시트 의 하위 라 이브 러 리 는 일정 단계 까지 확장 문제 에 직면 해 있다.그리고 수요 의 변경 으로 새로운 라 이브 러 리 방식 이 필요 할 수도 있다.
MySQL 데이터베이스 도 큰 텍스트 필드 를 자주 저장 하기 때문에 데이터베이스 테이블 이 매우 커서 데이터베이스 복 구 를 할 때 매우 느 리 고 데이터 베 이 스 를 신속하게 복구 하기 어렵다.예 를 들 어 1000 만 4KB 크기 의 텍스트 는 40GB 크기 에 가 깝 고 이 데 이 터 를 MySQL 에서 줄 일 수 있다 면 MySQL 은 매우 작 아 질 것 이다.
관계 데이터 베 이 스 는 매우 강하 지만 모든 응용 장면 에 잘 대처 할 수 없다.MySQL 의 확장 성 이 떨어진다(복잡 한 기술 이 필요 하 다).빅 데이터 에서 IO 의 압력 이 크 고 표 구조 변경 이 어렵다.바로 현재 MySQL 을 사용 하 는 개발 자 들 이 직면 하고 있 는 문제 이다.
NOSQL 의 장점
확장 하기 쉽다
NoSQL 데이터 베 이 스 는 종류 가 다양 하지만 하나의 공 통 된 특징 은 관계 데이터 뱅 크 의 관계 형 특성 을 제거 하 는 것 이다.데이터 간 에는 관계 가 없어 서 확장 이 매우 쉽다.어느새 구조 적 차원 에서 확장 가능 한 능력 을 가 져 왔 다.
빅 데이터 양,고성능
NoSQL 데이터 베 이 스 는 모두 매우 높 은 읽 기와 쓰기 성능 을 가지 고 있 으 며,특히 빅 데이터 양 에서 도 마찬가지 로 우수 하 다.무관 성 덕분에 데이터베이스 의 구조 가 간단 하 다.일반적으로 MySQL 은 Query Cache 를 사용 하 는데 매번 표 의 업데이트 Cache 가 효력 을 잃 고 큰 입자 의 Cache 로 웹 2.0 에 대한 상호작용 이 빈번 한 응용 에서 Cache 의 성능 이 높 지 않다.한편,NoSQL 의 Cache 는 기록 급 이 고 입자 가 작은 Cache 이기 때문에 NoSQL 은 이 차원 에서 성능 이 매우 높다.
유연 한 데이터 모델
NoSQL 은 저장 할 데이터 에 미리 필드 를 만 들 필요 가 없 으 며 사용자 정의 데이터 형식 을 언제든지 저장 할 수 있 습 니 다.관계 데이터베이스 에서 필드 를 추가 삭제 하 는 것 은 매우 번 거 로 운 일이 다.엄 청 난 양의 시계 라면 필드 를 늘 리 는 것 은 악몽 이다.이 점 은 빅 데이터 양의 웹 2.0 시대 에 특히 두 드 러 졌 다.
고가 용
NoSQL 은 성능 에 그다지 영향 을 주지 않 는 상황 에서 사용 가능 한 구 조 를 편리 하 게 실현 할 수 있다.예 를 들 어 카 산 드 라,HBase 모델 은 복제 모델 을 통 해 도 높 은 사용 이 가능 하 다.
총결산
NoSQL 데이터베이스 의 등장 은 관계 데이터(예 를 들 어 MySQL)가 어떤 면 에서 부족 한 점 을 보완 하고 어떤 면 에서 개발 원가 와 유지 원 가 를 크게 절약 할 수 있다.
MySQL 과 NoSQL 은 모두 각자 의 특징 과 사용 하 는 응용 장면 을 가지 고 이들 의 밀접 한 결합 은 웹 2.0 의 데이터 베이스 발전 에 새로운 방향 을 가 져 다 줄 것 이다.관계 데이터 베 이 스 를 관계 에 주목 하 게 하고 NoSQL 은 저장 소 에 주목 합 니 다.
참고 읽 기
NoSQL：http://nosql-database.org/
NoSQL 의 위 키 소개:http://en.wikipedia.org/wiki/NoSQL
NoSQL 관련 블 로그:http://nosql.mypopescu.com/
NoSQL 관련 블 로그:http://blog.nosqlfan.com/
시 나 웨 이 보 NoSQL 마이크로 그룹:http://q.t.sina.com.cn/127870
저자
손 립 은 현재 봉황 망 에서 하부 팀 의 연구 개발 업 무 를 맡 고 있다.소 후 와 쿠 6 에 근무 했다.다년간 의 인터넷 취업 경험 과 프로그램 개발,분포 식 검색엔진 의 개발,높 은 병발,빅 데이터 양 사이트 시스템 구조 최적화,높 은 가용성,신축성,분포 식 시스템 캐 시,데이터 베이스 분 표 라 이브 러 리(sharding)등 풍부 한 경험 을 가지 고 운영 모니터링 과 자동화 운영 제어 에 경험 이 있 습 니 다.오픈 소스 프로젝트 phoplock,phopbuffer 의 작성 자.최근 에 NOSQL 데이터베이스 저장 소 인 넷 DB 를 개 발 했 는데 NoSQL 데이터베이스 애호가 입 니 다.그의 시 나 웨 이 보 는:http://t.sina.com.cn/sunli1223
장 개 봉 의 본문 에 대한 기획 과 심사 에 감 사 드 립 니 다.
좋은 웹페이지 즐겨찾기
