데이터베이스 세계의 오래된 것과 새로운 것, SQL과 NoSQL, 기존 기업과 스타트업 사이의 적대감이 마침내 가라앉고 있습니까? 징후는 '예'를 가리키며 이는 업계에 좋은 일이 있음을 나타냅니다.
이번 선거 시즌 동안 우리는 적어도 미국의 사회 양극화 상태에 대해 합리적으로 동의할 수 있습니다. 그러나 그러한 상황은 유감스럽고 기술적으로 적대적 지향은 훨씬 덜 정당합니다.
데이터베이스 세계는 당파적이거나 획일적이어서는 안 됩니다. 인터넷과 이를 위한 시스템 구축을 통해 우리는 요구 사항이 조직마다, 심지어 조직 내에서도 다양하다는 사실을 알게 되었습니다.
결국 서로 다른 진영은 온건하고 조화를 이루고 본질적으로 합쳐져야 합니다. 그들은 서로 다른 강점을 가질 수 있고 갖고 있지만, 파벌로 분리되기보다는 스펙트럼을 따라 함께 조화를 이루어야 합니다.
그리고 그렇습니다. 저는 여기서 데이터베이스에 대해 이야기하고 있습니다. 특히 소위 NoSQL 데이터베이스 및 관계형 데이터베이스 관리 시스템(RDBMS)에 대해 설명합니다.
무슨 일이에요?
거의 8년 전, 새로운 종류의 데이터베이스를 설명하는 NoSQL이라는 용어가 만들어졌습니다. 이 카테고리의 제품과 오픈 소스 프로젝트는 테이블 스키마의 가변성을 수용할 수 없고 클러스터링되고 지리적으로 분산된 시스템에서 사용자를 해방시켰습니다. 인프라는 대부분의 프로그래밍 언어와는 다른 데이터 표현 패러다임을 사용하고 새 데이터가 기록되는 동안 작업을 차단하는 큰 번거로움을 안겨줍니다. 데이터베이스.
그러나 이러한 새로운 자유로 인해 SQL(Structured Query Language) 자체에 대한 강조가 사라진 것 이상으로 대부분의 LOB(기간 업무) 시스템에 매우 근본적인 많은 RDBMS 기능이 사라졌습니다. 희생된 기본 기능에는 기본 키 이외의 열에 대한 인덱스, 테이블 간의 명시적 조인 및 소위 "ACID"가 포함되었습니다. 보증 - 데이터베이스의 한 부분이 업데이트되고 다른 부분(예: 대변 및 일치 차변)에 대한 보상 변경이 발생한 경우 불가분하게.
친선
이러한 데이터베이스 관리 아키텍처의 조정이 마침내 본격화되었습니다. 이번주 발표는 몽고DB (표준 문서 저장소 NoSQL 데이터베이스)의 시조 데이터베이스의 향후 3.4 릴리스와 그래프 데이터베이스의 3.1 베타 릴리스 네오4j 2주 전이 이 일의 큰 부분을 차지했습니다. 다른 변경 사항도 쌓여가고 있으며, 각 변경 사항은 데이터베이스 전쟁을 종식시키는 평화주의자의 데이지입니다.
또한 읽어보세요: Couchbase NoSQL 데이터베이스가 SQL 종교를 받아들입니다.
또한 읽어보세요: DataStax Enterprise 3.1: NoSQL; 네, CQL입니다.
또한 읽어보세요: Couchbase 2.0 출시 JSON 문서 저장소 구현
Neo4j는 ACID 보장을 포기하고 이를 NoSQL의 사랑으로 대체하는 호전적인 NoSQL 접근 방식을 완화했습니다. "최종 일관성." 대신 Neo4j 3.1은 "인과적 일관성"(참고: 이는 "인과적"이며 아니다 "평상복"). 이 모델을 사용하면 작업이 더욱 ACID와 유사해지며 개발자는 쓰기 직후에 데이터베이스 읽기가 발생할 때 필요한 데이터베이스 일관성 수준을 표시할 수 있습니다.
네오레트로
결국 클러스터의 모든 서버가 업데이트를 받게 되며 영향을 받는 데이터 읽기가 매우 빠르게 이루어집니다. 하지만 중간 기간에 해당 데이터에 대한 읽기 요청은 어떻게 되나요? 버전 3.1을 사용하면 Neo4j 개발자는 해당 프로세스가 먼저 전체 완료되어야 하는지 또는 읽기가 즉시 수행될 수 있는지 지정할 수 있습니다.
그러나 균형과 미묘한 차이를 명목으로 개발자는 변경 사항이 서버의 "쿼럼"에 복제될 때 트랜잭션이 커밋되도록 허용할 수도 있으며, 그 중 하나는 읽기 요청에 응답합니다. 각 옵션은 성능과 일관성 측면에서 서로 다른 절충안을 의미합니다. 요구사항이 스펙트럼에 따라 존재할 때에도 마찬가지입니다.
앰비몽고
이번 주 초 Tony Baer가 자세히 다룬 것처럼 MongoDB 3.4는 더 이상 단순한 문서 저장소가 아닙니다. 즉, JSON(JavaScript Object Notation)으로 인코딩된 데이터의 저장 및 유지 관리 그 이상입니다. 엔터티. MongoDB는 이제 별도의 NoSQL 범주였던 그래프 처리도 수용합니다. 패싯 기반 검색 기술도 추가되었습니다. 인터넷 및 기업 검색 엔진이 취하는 접근 방식과 유사하게 패싯 탐색을 통해 데이터를 OLAP BI 사용자에게 친숙한 패러다임인 차원 값을 검색하거나 필터링합니다. 기술.
또한 읽어보세요: MongoDB 3.4는 일부 기업 데이터베이스 격차를 메웁니다.
그리고 이것이 충분하지 않다면 MongoDB 3.4는 가장 정식으로 SQL 쿼리 인터페이스를 지원할 것입니다. 그러면 사실상 모든 주요 BI 패키지가 필요 없이 MongoDB에 데이터 소스로 연결될 수 있습니다. 특수 드라이버, 특히 MongoDB의 SQL 방언은 분명히 오픈 소스 RDBMS의 방언과 호환될 것이기 때문입니다. MySQL.
또한 읽어보세요: Pentaho는 MongoDB와의 기본 통합을 추가합니다.
레드먼드에서 영감을 받았나요?
이러한 변경 사항에서 특히 흥미로운 점은 기존 RDBMS인 Microsoft와 거의 동일한 아키텍처 타협을 따른다는 것입니다. SQL Server라는 전통에도 불구하고 Microsoft는 얼마 전 DocumentDB라는 자체 클라우드 기반 NoSQL 데이터베이스를 출시했습니다. 이름에서 알 수 있듯이 이 제품은 문서 저장소 NoSQL 데이터베이스입니다.
그러나 Microsoft는 출시 당시 DocumentDB에 SQL 쿼리 인터페이스와 구성 가능한 데이터베이스 일관성 수준이라는 두 가지 범주 조정 기능(지금은 친숙하게 들릴 수 있음)을 추가했습니다. 최근에 Microsoft는 MongoDB API 호환 인터페이스를 추가했습니다. 이는 이제 두 제품 모두 두 쿼리 모델을 모두 제공한다는 것을 의미합니다. 그리고 MongoDB의 추가 발표와 함께 아틀라스 클라우드 서비스에서는 두 플랫폼이 실제로 정면으로 맞붙고 있습니다.
이것이 충분하지 않다면 Microsoft의 거의 25년 된 RDBMS 제품인 SQL Server의 최신 버전이 이제 동일한 JSON 형식으로 데이터 저장 및 검색 DocumentDB 및 MongoDB의 기본입니다. 그렇다고 해서 "MS SQL"(Microsoft 이외의 개발자 집단에서는 SQL Server를 종종 언급함)이 이제 NoSQL이라는 의미는 아닙니다. 이것이 의미하는 바는 카테고리의 구별이 모호해진다는 것입니다. 그들은 또한 점점 더 잘못된 이름이 되어가고 있습니다.
산업이 필요하다
그것은 좋은 일입니다. 결국 산업이 발전하려면 내분을 멈추고 조화롭게 전진해야 하기 때문이다.
한 이데올로기에 의한 지배는 좋지 않으며, 반대 접근 방식은 변화를 위한 진지한 캠페인을 조직하고 시작해야 할 수도 있습니다. 그러나 결국 양측은 서로에게서 배울 수 있으며 더욱 계몽되고, 보다 포용적이며, 덜 적대적인 환경을 형성할 수 있습니다. 고객은 이익을 얻고 공급업체도 이익을 얻습니다. 이를 통해 양쪽 모두 자유롭게 새로운 문제를 해결하고 해결할 수 있습니다.