NoSQL 움직임: 데이터베이스 아키텍처 선택

가이드: 마이크 Loukides는 O의 콘텐츠 전략의 부사장 ' 라일리 미디어, 그는 프로그래밍 언어와 유닉스 시스템 관리에 관심이, 시스템 성능 튜닝 및 유닉스 전력 공구. 이 문서에서는, 마이크 Loukides 앞으로 nosql에 대 한 그의 통찰력 있는 통찰력 넣고 깊이 현대 데이터베이스 아키텍처의 모든 측면에 대 한 생각.

대화 지난 1 년에 바쇼의 cto 인 저스틴 Sheehy는 NoSQL은 스포츠, 기술이 아닌. 나는 즉시 동의 한다, NoSQL의 이전 논의 편안 하기 때문에.

그래서 NoSQL은 스포츠, 기술이 아닌 그것은 왜? 저스틴의 인수는 간단 합니다: 그것은 데이터베이스 아키텍처의 선택 때문에 NoSQL 스포츠 이유입니다. 어떤 하나의 기술 주제 NoSQL 운동의 본질을 모호한 것 이다.

80, SQL Server, Oracle 및 DB2 같은 관계형 데이터베이스는 이후 지배적인 백엔드 비즈니스 시스템. 이러한 관계형 데이터베이스 제품은 우수 하 고 많은 유사점을가지고.

소프트웨어 개발의 지난 15 년 동안 다시 찾고, 우리는 우수한 대규모 데이터베이스 응용 프로그램, 웹 응용 프로그램을 포함 하 여 수를 구축 했습니다. 하지만 관계형 데이터베이스의 탄생 이후 많은 변경 된 데이터베이스 필드에:

서 지 데이터입니다. 비록 저장 용량과 CPU 속도 신속 하 게 개발, 데이터베이스, 데이터의 확산과 함께 대처할 수 있는 하지만 데이터의 볼륨은 참으로 어려운 문제, 모든 중요 한 데이터베이스, 분산에 대 한 필수적입니다. 하위 두 번째 쿼리 응답입니다. 80 's에서 데이터베이스 쿼리 일괄 처리에서 실행 하 고 쿼리는 효율적. 이제는 인터넷 개발 되었습니다 정적 파일에서 복잡 한 데이터베이스에서 지 원하는 사이트에 그리고 대부분의 쿼리에 대 한 우리는 두 번째 수준의 응답 시간. 7 * 24 시간 정상적으로 실행 됩니다. 정적 HTML 파일에 대 한 중복 서버를 설정 하는 것은 쉽습니다, 하지만 복잡 한 데이터베이스 복제는 또 다른 문제입니다. 고속 데이터 스트림 캡처는 점점 더 중요 해지고 있다. 많은 응용 프로그램 배경 데이터베이스 데이터 쿼리를 처리 하는 것 보다 훨씬 빨리 데이터를 흡수. 예를 들어 로그 응용 프로그램 또는 분산된 감지 응용 프로그램 데이터베이스에 쓰기 쿼리 보다 더 빈번 하다. ETL (데이터 추출, 변환 및 로드)은 필수, 하지만 고속 데이터 스트림 캡처 점점 더 중요 해지고 있다. 구조화 되지 않은 데이터입니다. 구조화 되지 않은 데이터는 오래 전에 존재 하 고 데이터 세계에 새로운 풍경이 아니다 하지만 우리 점점 하지 않으려는 데이터 구조 적용. 비용 산. 산 (원자성, 일관성, 격리, 지 속성)이 중요 한, 하지만 현대 응용 프로그램의도 전에 우리 낮은 대기 시간 및 가용성과 같은 다른 기능을 구현 하는 희생을 실현.

수요에 지속적인 변화는 새로운 데이터베이스 솔루션의 생각 하도록 강제:

Distributed。 큰 데이터베이스, 배포에 대 한 단 하나의 이유 이며 또 다른 이유는 최신 응용 프로그램, 특히 웹 응용 프로그램, 많은 온라인 사용자 로부터 즉각적인 응답이 필요한. 응답 시간, 매초 마다 사용자 이탈의 많은 수를 일으킬 것입니다. 실시간 계산입니다. 비즈니스 분석을 지원 하기 위해 온라인 응용 프로그램을 작성 하는 경우 사용자가 불가피 하 게 기대 하지 실시간 비즈니스 분석. 그것은 단지 편리, 문의 수백의 일일 실행 이며 그것은 완전히 우리의 일 변했다. 확장성입니다. 확장성은 비즈니스 분석에 대 한 고객 지향 응용 프로그램을 작성 하는 경우는 큰 문제 이다. 수직 확장성은 이미 제한, 근처와 물리 법칙 3.5 g h z, 인텔의 클럭 주파수를 제한 하 고 수평 확장성 (다중 노드 분산된 시스템의 건설) 유일한 방법입니다. 높은 가용성. 응용 프로그램 아키텍처의 어떤 부분에 있는 실패의 단일 지점 비참 한 결과 가질 수 있으며 데이터베이스 시스템 고가용성 지원을 제공 해야 합니다. 고 가용성 시스템은 자연스럽 게 분산된 시스템. 데이터 조각입니다. 지정된 된 배포 데이터베이스에 대 한 다음 문제 데이터 조각입니다. 관계형 데이터베이스 여러 호스트 간에 수동 조각화를 사용 하거나 자체 데이터의 일부 특성에 따라 데이터 집합을 분할 합니다. MongoDB 데이터 조각 하기 매우 쉽습니다, 그리고 Riak, HBase, 카산드라 분산된 데이터베이스. 리스 (모덜리스)입니다. NoSQL 데이터베이스는 종종 라고 하 리스 (모덜리스) 들은 관계형 데이터베이스의 스키마 모양의 독립 때문에. 사실, NoSQL은 완전히 모덜리스. COUCHDB 등 MongoDB 문서 데이터베이스에 문서는 다양 한 키-값 쌍 (키 값). Riak 문서 데이터베이스 표시 하지만 문서 유형 보다 더 유연한 될 수 있습니다. 카산드라를 HBase 열 기반 데이터베이스 라고 합니다. 대부분의 응용 프로그램 개발에서 NoSQL 데이터베이스는 덜 의향 계획, 더 많은 유연성과 민첩 한 개발에 대 한 더 적합. 산 및 모자입니다. Acid 속성 보급, 하지만 만약 우리가 데이터베이스의 아키텍처에 대 한 생각, 우리가 일관성 등 분산된 시스템에 대 한 격리 ACID 속성을 구현 하기 어려운 찾을. Acid 속성은 중요 한, 그러나 자유 선택 손상 될 필요가 있다. 모자 법률 일관성, 가용성 및 내결함성을 분할 만날 수 있는 두 분산된 컴퓨팅 시스템에서 상태. 스크립팅 언어입니다. 모든 관계형 데이터베이스는 데이터 스크립트 언어 SQL 언어 버전 (예: T-SQL 및 PL/SQL). 비 관계형 데이터베이스의 세계, 거기 또한 스크립팅 언어를 사용할 수 있습니다. Couchdb와 Riak 자바 스크립트를 지원 하 고 그래서 MongoDB를 않습니다. 여러 스크립트 프로그래밍 언어 프로젝트 (를 포함 하 여 돼지와 하이브) 하 둡 프로젝트에서 분할 하는 HBase에 적용 됩니다. Redis 프로젝트는 LUA 스크립트 언어를 통합 한 실험。 RESTful 인터페이스입니다. Couchdb와 Riak restful 인터페이스를 제공합니다. Graphics。 NEO4J는 그래픽을 유지 하기 위해 특별히 설계 된 데이터베이스입니다. 그래프는 매우 유연한 데이터 구조는 데이터베이스의 모든 다른 종류를 시뮬레이션할 수 있습니다. SQL입니다. 우리 NoSQL 움직임에 대해 얘기 하지만 우리는 SQL의 친숙 한 프로그래밍 언어를 무시할 수 없습니다. 누군가가 SQL, 하 둡을 포팅 작업은 그리고 어쩌면 우리는 미래에 하이브리드 데이터베이스 아키텍처를 채택 거 야. 과학적 데이터입니다. SCIDB는 대규모 과학 연구 응용 프로그램, 데이터베이스 프로젝트 그리고 그것의 저장소 모델은 다차원 배열 기반. SCIDB 스토리지 쉽게 PB의 수백에 확장 하 고 수십 TB 당 데이터의 수집 수 있습니다. 혼합된 건축 술입니다. NoSQL 움직임은 데이터베이스 아키텍처의 선택에 밀접 하 게 관련 된다. 아마도 최종 데이터베이스 스키마 선택 하지 단일 데이터베이스 기술 하이브리드 아키텍처 이름입니다. 혼합된 구조 선택만 흡수 하 고 기술 개발에 적응 수 있습니다. 하이브리드 아키텍처는 전통적인 전자 상거래 사이트에 소셜 기능을 통합 하는 최선의 방법입니다.

마지막에 작성 된

NoSQL 움직임 이란 우리가 원하는 데이터베이스 아키텍처 솔루션에 대 한 생각을 주도하 고 있다. 아마도 우리는 결국 아무 보편적인 진리는 이해할 것 이다. (장 Zhiping/컴파일)

(책임 편집기: 유산의 좋은)