NoSQL에 획기적인 것이 있습니까? [닫은]

나는 매우 탄탄한 관계형 데이터베이스 사람이며 제 3 정규 형식까지 모든 것을 이해하고 SQL의 대수 집합 이론에 감사하며 아마도 상한 마음을 관계 화 할 수 있습니다.

아내와 데이트 밤에 대한 관계형 데이터베이스 구조를 파악하지 못했지만 아내와 데이트 밤에 관계형 데이터베이스 프로젝트에 대해 생각했습니다 ..

이제 NoSQL에 대해 듣고 연구하고 있습니다. 추격을 자르고, NoSQL에 대해 획기적인, 수학적으로 소설 적이거나, "관계형으로 데이터를 구성 할 필요조차 없습니다. 이것이 훨씬 쉬워요"유형의 접근 방식이 있습니까?

NoSQL은 데이터 구조의 슈퍼 쉘과 같은 것입니까? 내 마음에 데이터는 궁극적으로 검색 할 구조를 가져야하며 검색은 일종의 언어로 정의되어야합니다.

NoSQL은 혁신적인 것보다 진화 적입니다. 본질적으로 "외부 데이터베이스 스토리지"라는 기존 아이디어와 "관계형 테이블이 아닌 익숙한 데이터 구조 사용"을 결합합니다.

관계형 데이터베이스보다 더 많은 유형의 데이터베이스가 있습니다 (예 : 계층 적 데이터베이스) . 오늘날의 표준에 따르면 구식이지만 데이터의 데이터 구조 (예 : COBOL 레코드) 와 실제로 잘 맞습니다 . 요점은 데이터베이스의 데이터가 레코드를 사용한 프로그래밍 언어로 레코드가 배치되는 방식에 가깝게 모델링되었다는 것입니다.

빨리 감기의 발명에 관계형 데이터베이스 데이터베이스 문제를 분리 마지막으로, 제대로 정상화 할 때, 데이터와 데이터 사이의 관계의 대부분의 유형을 시각화 할 수있는 좋은 방법입니다. 다른 유형의 데이터베이스에 비해 이해하기 가 정말 쉽습니다. 그러나 완전히 실패하는 것은 프로그램에서 객체와 클래스를 미러링하는 방식으로 데이터를 저장하는 것입니다. 따라서 객체 관계형 매핑 의 발명 . 즉, 데이터베이스 디자인은 실제로 데이터베이스 를 사용하는 프로그램 디자인에 방해 가되므로 Hibernate 와 같은 ORM 라이브러리가 필요합니다. 깨끗하고 일관된 반면, 무언가가 옳지 않다는 내 생각에는 의심의 여지가 항상 있습니다.

이로 인해 두 가지 유형의 데이터베이스 인 오브젝트 데이터베이스 와 NoSQL이 발생했습니다 .

두 가지 모두 관계형 데이터베이스에서 발생하는 문제를 해결하려고 시도하면서 계층 적 데이터베이스의 정신을 자극하는 공포에 노출시키지 않습니다. 데이터는 여전히 모호하게 테이블과 유사한 저장소에 배치되지만 실제로는 관계형 테이블보다 프로그래밍 데이터 구조와 유사합니다. 객체 데이터베이스는 대부분 잘 정의 된 규칙을 따르지만 NoSQL은 다소 임의적이라는 것을 이해합니다. 예를 들어, 테이블은 해시 테이블 또는 배열로 시각화 될 수 있습니다. Oracle SQL Developer 또는 SQL Server Management Studio 와 유사한 임의의 도구를 사용하여 쿼리를 쉽고 명확하게 정의 할 수있는 방법은 없습니다 .

아이디어는 원하는 쿼리를 표현하는 대신 SQL 데이터베이스 엔진에 더 적합한 SQL 쿼리를 함께 묶지 않고 코드에서 쉽게 검색 할 수있는 데이터 구조를 정의 할 수 있다는 것입니다. 예를 들어, 관계형 데이터베이스에서는 퍼지 또는 부분 일치가 더 어려워지고 성능이 저하되는 반면 NoSQL 데이터베이스는 이러한 검색에 최적화되어 짧은 시간 안에 완료되는 구조를 가질 수 있습니다.

NoSQL을 쿼리하기위한 언어가 있습니다. 그러나 관계형 데이터베이스에 대한 SQL과 같은 범용 언어 는 없습니다 .

늦은 편집 :

NoSQL 데이터베이스에 대해 잘 알고 있지만이 질문은 주제에 관한 양질의 책을 구입하고 주제에 대한 진정한 전문가가 되겠다는 최종 목표로 책을 읽기 시작하는 데 자극이되었습니다. 나머지 의견은 NoSQL Distilled : Pramod Sadalage 와 Martin Fowler 의 신흥 세계 다국어 지속성 에 대한 간단한 안내서를 기반으로 합니다.

저자는 관계형 데이터베이스가 Amazon 및 Google과 같은 사이트에 필요한 데이터를 제공 할 수있는 클러스터에 적합하지 않다고 말합니다. NoSQL은 이러한 틈새 시장에 맞도록 개발되어 ACID의 동시성과 내구성을 완화하여 대부분 정적 데이터를 사용하십시오 (따라서 ACID 트랜잭션은 중요하지 않습니다).

또한 NoSQL 데이터베이스는 스키마 (10 페이지)없이 작동하므로 NoSQL 데이터베이스가 데이터 구조를보다 쉽게 ​​수정할 수 있습니다. SQL 데이터베이스에서도 스키마를 수정할 수 있기 때문에 공식 스키마가 있는지 여부는 확실하지 않습니다. 그럼에도 불구하고, 유명한 저술가 두 명이 주장 할 가치가 있으므로 조사 할 가치가 있습니다.

저는이 두 가지 요점이 NoSQL이 혁명이 아니라 진화라는 나의 주요 요점을 강화하는 데에만 기여한다고 생각합니다. 그들은 여전히 ​​데이터를 저장하고 규모와 수정 가능성을 점진적으로 향상시킵니다. 또한 NoSQL은 관계형 데이터베이스를 데이터 스토리지의 왕으로 삼으려고하지 않으며 관계형 방식으로 확장하고 변형해야하는 데이터 유형에 대한 대체 데이터 스토리지 수단을 제공하기 만합니다. 데이터베이스가 충분히 지원되지 않습니다.

Erik Meijer & Gavin Bierman이 작성한이 논문을 " 여러분의 생각과 는 달리 SQL과 NoSQL은 실제로 같은 동전의 양면 일뿐"이라고 생각 합니다. 요컨대, 수학적으로 말하는 것은 같은 이론에 근거하지만 약간의 차이점이 있다고 주장합니다.

몇 가지 흥미로운 차이점은 제 의견으로는 다음과 같습니다. 교차 유형 종속성 (SQL의 FK)의 방향은 SQL 및 NoSQL의 반대이며 컬렉션 유형은 NoSQL에서 설정하도록 제한되지 않으므로 일부 이론 이론 연산 NoSQL 세계에는 더 이상 적용되지 않지만 일부는 여전히 유효합니다. 이 기사의 또 다른 흥미로운 점은 SQL 및 NoSQL 데이터베이스를 모두 쿼리하기 위해 제안 된 단일 쿼리 언어입니다. LINQ라고하며 이전에이 이름을 들어 본 적이 있다고 생각되면 정확합니다. 이것이 C #의 Microsoft 쿼리 언어입니다.

Snowman의 답변은 데이터 구조에서 SQL과 NoSQL의 차이점과 액세스 방식에 대해 올바르게 설명합니다. 그러나 아마도 더 중요한 차이점은 각각의 문제 영역입니다.

NoSQL은 SQL의 후계자가 아닙니다. 오히려 NoSQL 의 다양한 브랜치는 다른 SQL을 향상시키기 위해 일부 SQL 품질을 희생합니다 . CAP 정리 는 분산 데이터베이스 시스템이 다음 특성을 모두 만족시키는 것이 불가능하다는 것을 나타냅니다.

• 일관성
• 유효성
• 분할 공차

따라서 일부 NoSQL 변형은 대신 BASE 원칙을 따르며 , 이는 고전적인 SQL 데이터베이스의 기초가되는 ACID 의 항상 완전 일관성 제약 조건을 완화 합니다. 일관성을 보장하지 않으면 데이터와 사용자 쿼리가 많은 웹 사이트와 같이 광범위하게 분산 된 시스템에서 고가용 성과 파티션 허용 오차를 결합 할 수 있지만 완벽한 일관성에 대한 요구는 거의 없습니다. 따라서 이러한 NoSQL 데이터베이스는 Google , Facebook 및 Amazon 의 핵심입니다 . 따라서 귀하의 질문에 대답하기 위해 : 예, NoSQL은 그러한 대규모 웹 서비스를 거의 가능하게한다는 점에서 획기적인 것 입니다.

NoSQL은 다양한 분야이므로 변형은 CAP 삼각형 내에서 가능한 모든 매개 변수 조합을 포괄 합니다.

NoSQL의 일반적인 사용 사례는 일반적인 SQL 기반 데이터베이스와 비교했을 때 생산성이 크게 향상되었습니다. 여기에는 몇 가지 요소가 있습니다.

하나는 하우스 키핑입니다. 대부분의 NoSQL은 오픈 소스이며 몇 가지 명령으로 워크 스테이션 또는 VM에 설치할 수 있으며 기본적으로 합리적인 기본값으로 작업 할 수 있습니다. 내 경험상 Postgres와 MySQL조차도 그렇지 않습니다. 구성은 일반적으로 개발 목적으로 워크 스테이션에서도 시작하는 데 필요합니다.

다른 답변은 자세히 설명했듯이 편리한 개발입니다. Mongo의 JSON 인덱싱 기능 또는 redis 및 Riak의 키 / 값 의미는 모든 특정 웹앱이 작업을 완료하는 데 필요할 수 있으며 API는 쉽습니다. 일부 NoSQL은 자체 RESTful API를 제공하지만 SQL을 사용하면 일반적으로 직접 작성해야합니다.

이러한 요소들로 인해 NoSQL 데이터베이스는 소규모 프로젝트에 적합합니다. 픽업 시간이 짧은 경향이 있습니다. 물론 프로덕션 환경에서는 보안과 규모를 구성해야하지만 코딩 및 공동 작업을 빠르게 시작할 수있는 기능은 강력하며 획기적인 주장입니다.

또한 위와 관련하여 회사 내부 또는 앱 간 응용 프로그램 서비스와 같은 소규모 응용 프로그램의 경우 팀은 DBA 팀을 포함하지 않고 성능 또는 무결성을 잃지 않고 프로덕션 NoSQL 데이터베이스를 세울 수 있습니다. 결과적으로 문제. 전문가 용 DBA는이 점이 마음에 들지 않지만 DBA를 방해의 원천 (옳고 그름)으로 보는 개발자는 때때로 NoSQL을 다루지 않아도되는 방법으로 NoSQL을 봅니다. 나는 이것을 고백합니다-한 번 소규모 응용 프로그램을 Postgres에서 SQLite로 변경하여 적의 DBA를 없애고 DBA 승인 프로세스와 액세스 제한을 피하기 위해 Oracle 대신 Mongo에서 구현하기로 선택했습니다. 두 경우 모두 부작용이 없습니다.