오늘 아침, The 451의 Matt Aslett은 블로그에서 NoSQL 종말의 시작 에서 NoSQL 카테고리 이름의 쓸모없음을 강조했습니다. 늘 그렇듯이 좋은 글입니다. 하지만 이것은 새로운 소식이 아닙니다. 이 용어가 만들어진 날부터 사람들은 이 용어에 대해 불만을 품어 왔습니다.
저는 사용 사례("어떤 문제를 해결하려고 하는가?")에 초점을 맞추는 것이 레이블에 집중하는 것보다 훨씬 더 생산적이라는 Matt의 의견에 전적으로 동의합니다. 하지만 기본 데이터 모델(키-값, 문서, 열 중심, 그래프 등)에 따라 분류하는 것이 더 유용할 수 있다는 Matt의 주장에는 동의하지 않습니다. 이러한 범주는 특정 작업에 대한 목적 적합성을 평가하는 데 초점을 맞추는 경우에만 약간의 개선 효과를 제공합니다.
몽고는 문서 데이터베이스입니다. Couch도 마찬가지입니다. 하지만 이 두 솔루션은 사용 사례 관점에서 보면 완전히 다른 방향으로 나아가고 있습니다.
몽고는 문서 데이터베이스입니다. Cassandra는 열 중심의 데이터베이스입니다. Membase 와 Riak은 핵심 가치 저장소입니다. 그러나 이러한 솔루션은 사용 사례 관점에서 볼 때 직접적인 충돌을 빚고 있습니다. 오늘날 고객들은 이 솔루션들을 서로 바꿔가며 평가하고 있으며, 기본 데이터 모델과는 전혀 상관없는 기능에 따라 승패가 갈리는 경우가 많습니다.
예, NoSQL은 쓸모없는 카테고리 이름입니다.
NoSQL이라는 명칭이 좋지 않은 데에는 적어도 두 가지 이유가 있습니다:
- 일부 "NoSQL" 시스템은 실제로 SQL의 방언을 제공합니다. 를 데이터베이스 내의 데이터에 액세스하기 위한 쿼리 언어로 사용합니다. Google 앱 엔진에는 GQL 언어. 퀘스트에는 클라우드 데이터베이스용 두꺼비 는 Hbase, Azure Tables, Amazon의 SimpleDB 및 기타 "NoSQL" 데이터베이스를 위한 SQL 인터페이스를 제공하고자 합니다. Hive 는 SQL의 방언을 Hadoop에 도입하여 ETL을 용이하게 합니다.
- Matt가 지적했듯이 NoSQL이라는 기치 아래 너무 많은 종류의 기술이 뭉뚱그려져 있습니다. 오늘. 의심의 여지가 없습니다. 하지만 저는 복잡한 기술 스택의 한 측면으로만 이야기하는 것은 실제 문제 해결에 조금 더 가까워질 뿐이라고 제안합니다. 인간은 개념과 사물을 한데 묶을 수 있는 깔끔한 범주를 원하도록 연결되어 있습니다. 하지만 저는 몽고에 대한 라벨로 NoSQL을 사용하는 것은 몽고가 문서 데이터베이스라고 말하는 것보다 약간 덜 유용하다고 생각합니다, 당신이하려는 일이 좋은 것이 무엇인지 알아내는 것이라면 에 대한.
데이터 모델별로 분류하는 것도 쓸모가 없습니다.
그렇다면 이 모든 새로운 솔루션에 대해 깔끔하고 대표적인 카테고리는 무엇일까요? 관찰자가 솔루션 카테고리가 주어진 사용 사례에 적합한지 여부를 실제로 판단할 수 있는 카테고리는 무엇일까요? 저도 답이 없고 좋은 답이 있는지 잘 모르겠습니다. 사용 사례 자체가 올바른 분류를 제공할 수도 있습니다. 어쨌든 Matt가 언급한 451 보고서가 이러한 "데이터베이스 대안"에 대한 생각을 정리하는 데 도움이 되기를 기대합니다.
궁극적으로 이러한 솔루션을 분류하려면 기본 데이터 모델(키-값, 문서, 열 중심, 그래프 등)만으로는 부족합니다. 오히려 이러한 시스템은 관리하기 쉬운 더 큰 속성 집합을 사용하여 비교해야 합니다: 데이터를 삽입하기 전에 스키마를 선언해야 하나요? 스키마가 필요한 경우 즉석에서 스키마를 변경할 수 있나요? 그렇게 하는 것이 얼마나 어려운가요? 데이터베이스가 (애플리케이션에) 투명하게 여러 머신에 걸쳐 퍼질 수 있나요, 아니면 단일 서버 중심의 솔루션인가요? 용량을 추가하거나 제거하기 위해 데이터베이스를 중단해야 하나요? 쿼리 언어를 사용하여 데이터베이스를 쿼리할 수 있나요, 아니면 코드를 작성해야 하나요? 시스템에서 쿼리 속도를 높이기 위해 인덱스를 유지 관리하나요? 데이터베이스는 임의 및 순차 작업에서 어떤 성능을 발휘하나요? 읽기와 쓰기의 성능은 어떻게 다른가요? 데이터가 즉시 또는 나중에 내구성 있는 미디어에 기록되며, 노드 장애 시 데이터 손실에 노출되나요? 데이터센터 장애는 어떻게 되나요? 동기식 작업을 통해 이러한 노출을 변경할 수 있나요? 그러면 성능에 어떤 영향을 미치나요? 데이터베이스가 데이터센터 경계를 넘어 작동할 수 있나요? 항상 쓰기를 읽을 수 있나요, 아니면 읽기 간에 데이터 불일치 기간이 있나요?
이러한 질문은 특정 사용 사례에 대한 목적의 적합성을 확인하려고 할 때 훨씬 더 적절한 질문입니다. 다시 묻습니다, 이러한 질문에 대한 답변을 이러한 시스템이 분류되는 좁은 범주와 비교할 때 상관 계수가 낮습니다.그리고 이 모든 것을 하나의 큰 'NoSQL' 카테고리로 묶거나 단일 축 데이터 모델 중심 접근 방식(키-값, 문서, 열 중심, 그래프 등)에 따라 하위 카테고리로 나누는 것은 거의 중요하지 않습니다.
NoSQL은 90년대 후반의 OODBMS 실패를 반복하는 것일까요?
그런데 왜 NoSQL을 둘러싼 잡음이 이렇게 많은 걸까요? 1990년대 후반에 우리 모두가 겪었던 객체 지향 데이터베이스 과대 광고의 재연일까요? 그 실패 당시 OODBMS 공급업체, 전문가 및 투자자들은 관계형 데이터베이스 기술을 점점 더 지배적인 객체 지향 애플리케이션 개발 모델에 대한 '장애물'로 치부했습니다. 개발자가 네이티브 객체 형태로 데이터베이스에 데이터를 저장하는 것이 더 '자연스럽다'는 주장이 있었고, 그것이 더 효율적이라는 주장도 있었습니다.
하지만 실제로 해결된 문제는 거의 없었습니다. 사실, 잘 알려져 있고 작동하는 기술에서 보다 "우아하고" 이론적으로 올바른 접근 방식을 약속하는 검증되지 않은 솔루션으로의 전환은 실제로 단 한 가지, 즉 혼란을 초래할 뿐이었습니다. 객체와 관계형 데이터 모델 간의 '불일치'를 해소하기 위해 설계된 객체-관계형 매핑(ORM) 계층은 완벽하지는 않지만, 그럴 필요가 없다면 세상을 뒤집어엎는 것보다는 낫습니다. 분석가들이 예측한 수백억 달러의 매출은 OODBMS 시장에서 실현되지도 못했습니다.
그렇다면 지금 진짜 문제가 있을까요? 기존 데이터베이스 기술이 정말 불충분한 실제 사용 사례 또는 사용 사례가 있습니까? 기술 변화로 인한 혼란이 실질적인 경제적 영향을 미칠 수 있는 곳일까요? 대답은 '그렇다'입니다.
사용 사례는 NoSQL 솔루션의 다양성과 융합을 주도하고 있습니다.
Couch는 모바일 데이터 동기화 사용 사례. 모바일 디바이스가 점점 더 지배적인 컴퓨팅 환경에서 클라우드와 모바일 디바이스 간의 데이터 동기화(네트워크 연결이 끊어진 상태에서도 데이터 가용성 유지)는 많은 애플리케이션이 해결해야 하는 문제입니다. 간헐적인 연결, 동기화된 데이터베이스를 실행해야 하는 다양한 플랫폼, 그리고 이동 및 동기화되는 데이터 세트가 일반적으로 하나의 박스나 디바이스에 들어맞아야 한다는 기대치 등 고려해야 할 사항이 많습니다. Couch는 이러한 요구사항에 초점을 맞추고 적절한 단순화 가정을 통해 그 누구보다 이 사용 사례를 잘 해결하고 있습니다. Couch는 문서 데이터베이스입니다. Mongo도 마찬가지입니다. Mongo는 이 사용 사례에 적합한 솔루션이 아닙니다. 일시적으로 연결된 시스템을 동기화 상태로 유지하도록 설계되지 않았고, 처음에는 단일 노드 데이터베이스로 설계되었음에도 불구하고 작년에 수행된 샤딩 및 복제 작업은 Mongo가 다른 방향으로 나아가고 있음을 분명히 나타냅니다. 이 경우, 분명히 다이버전스 의 솔루션이 있으며, 'NoSQL' 시장의 보다 좁은 '문서 데이터베이스' 분야에서도 마찬가지입니다.
다른 한편으로는 카테고리 간 컨버전스 은 대화형 웹 애플리케이션 뒤에 데이터를 저장하는 또 다른 매우 크고 일반화된 사용 사례를 해결하고자 하는 다른 NoSQL 솔루션들 사이에서 발생하고 있습니다. Membase에서는 매주 이 문제로 고민하는 많은 잠재 사용자들과 이야기를 나누고 있으며, Cassandra(열), Mongo(문서), Riak(키-값)에 대해 지속적으로 평가를 받고 있습니다.
조직이 소비자와 직접 상호 작용할 수 있는 웹 애플리케이션은 새로운 대화형 소프트웨어 시스템 구축의 가장 일반적인 형태가 되고 있습니다. 이러한 시스템은 대규모 사용자 집단에 의한 무작위 동시 사용 패턴이 특징입니다(대규모 청중) 및 대규모 데이터 집합을 축적하는 성향(빅 데이터). 특히 이러한 종류의 애플리케이션에서는 대규모 전용 '빅 아이언' 머신에서 워크로드를 실행하는 것보다 '스케일 아웃'(클라우드 머신 인스턴스, 가상 머신 또는 상용 서버를 더 추가)을 선호하는 클라우드 컴퓨팅 모델에 대한 요구도 높아지고 있습니다. 이러한 현실로 인해 처음부터 다음을 수행할 수 있도록 설계된 새로운 종류의 데이터베이스 관리 시스템이 널리 필요하게 되었습니다. 수평으로 확장 빠르게 증가하는 데이터 세트에 대해 높은 수준의 동시성을 비용 효율적으로 지원할 수 있습니다. 아마도 우리는 이것을 클라우드 데이터베이스탄력적 데이터베이스, 스케일아웃 데이터베이스 또는 자동 샤딩(: P) 데이터베이스 사용 사례입니다.
그렇다면 이 문제를 해결하기 위해 데이터베이스는 무엇을 제공해야 할까요? 저는 간단하고, 빠르고, 탄력적이며, 안전해야 한다고 주장하고 싶습니다. 이 일반화된 '클라우드 데이터베이스' 문제를 해결하는 것을 명시적으로 목표로 하는 Membase, Mongo, Cassandra, Riak을 고려하면 각 점수에 대한 점수는 다양합니다.
첫 번째 특성을 살펴봅시다. 성공하려면 범용 클라우드 데이터베이스를 쉽게 구하고, 개발하고, 프로덕션 환경에서 운영할 수 있어야 합니다.
- 멤베이스는 매우 손쉬운 구입, 설치 및 사용 시작. 몽고도 마찬가지입니다. 어떤 경우에는 멤베이스보다 쉽고, 어떤 경우에는 더 어렵습니다. Cassandra는 거의 모든 상황에서 도전적입니다.
- 몽고는 개발하기 쉬운 - 풍부한 쿼리, 인덱스 관리, 데이터베이스 자체 내에서 다양하고 흥미로운 데이터 유형에 대한 작업 기능을 제공합니다. 멤베이스는 멤캐시와 호환되는 키-값 API를 개발자에게 제공하는데, 사용하기는 매우 쉽지만 많은 일반적인 데이터베이스 작업에서 애플리케이션 개발자의 부담이 몽고에 비해 더 큽니다. Cassandra는 더 복잡한 개발 모델을 제공하지만 풍부한 쿼리를 허용합니다. Riak 쿼리는 맵 축소에만 의존합니다.
- 멤베이스는 프로덕션에서 쉽게 관리는 소규모 또는 대규모 서버 클러스터의 운영에 대한 심층적인 인사이트를 제공하는 풍부한 모니터링 및 관리 도구 세트를 제공하여 시스템 가동 시간을 늘립니다. Mongo는 클러스터 운영에 대한 인사이트가 훨씬 적으며, 이러한 결함은 포스퀘어 중단 이후 Mongo가 주로 지적한 문제였습니다.
나머지 특성인 속도, 탄력성, 안전성에 대해서도 비슷한 비교를 할 수 있습니다. 각 솔루션은 이러한 특정 영역에서는 강하고 다른 영역에서는 상대적으로 약합니다.
하지만 가장 중요한 점은 이러한 각 솔루션은 상대적인 결함을 보완하기 위해 움직이고 있습니다. 고객의 요구를 더 잘 충족할 수 있습니다. 사용 사례에 따른 융합이 이루어집니다. 어떤 프로젝트도 단순히 훌륭한 키-값, 문서, 열 중심의 데이터베이스 관리 시스템에만 초점을 맞추지 않습니다. 각 프로젝트는 실제 문제를 해결하는 데 초점을 맞추고 있으며, 앞서 설명한 대로 대화형 웹 애플리케이션 뒤에 데이터를 저장할 수 있는 비용 효율적인 장소를 제공합니다. 이를 위해 Membase는 쿼리 및 인덱싱 기능을 추가하고 있습니다. Mongo는 최근 초기 단일 서버 솔루션에 샤딩 및 복제본 지원을 추가했으며, 데이터 안전성을 높이기 위해 스토리지 엔진을 재설계하고 있습니다. 또 다른 "NoSQL" 솔루션인 Redis는 진정한 "탄력성"을 갖추기 위해 클러스터 관리 기능을 추가하고 있습니다. 이 사용 사례를 타깃으로 하는 솔루션들 사이에는 분명한 융합이 존재합니다. 이러한 각 프로젝트는 광고 및 오퍼 타겟팅, 소셜 게임, 웹 애플리케이션 세션 상태 관리, 실시간 이벤트 처리를 시스템이 의도하는 사용 사례로 식별합니다. 이들은 모두 대화형 웹 애플리케이션 사용 사례입니다.
비관계형은 클라우드 데이터베이스의 실제적이고 일관된 기술 스레드입니다.
기술적 관점에서 이러한 클라우드 데이터베이스 솔루션에 대해 일관되게 말할 수 있는 한 가지가 있습니다. 이러한 솔루션은 수평적 확장을 목표로 하는데, 관계형 데이터 모델을 사용하면 적절한 성능으로 비용 효율적으로 확장하기가 매우 어렵습니다(불가능합니다). 따라서 이러한 각각의 "NoSQL" 데이터베이스 시스템은 "비관계형" 시스템입니다. 이것이 궁극적으로 "NoSQL"의 의도입니다.
사실 이러한 각 시스템의 핵심은 다음과 같습니다, 키-값 저장소. 값 내부를 살펴보거나 값에 대한 작업을 위해 값을 그룹화하는 데 사용되는 기술은 다양합니다(키-값은 값을 불투명한 블롭으로 보고, 문서는 값을 형식이 지정된 속성-데이터 유형 컬렉션으로 보고, 열 중심 저장소는 별도의 데이터 구조를 사용하여 개별 KV 쌍을 "열"로 그룹화합니다). 그러나 각각의 경우, 관계형 모델에서처럼 데이터 레코드(튜플)를 정규화된 상호 참조 테이블 집합에 저장된 항목으로 분리하는 대신 이러한 클라우드 데이터베이스는 특정 '레코드'에 대한 데이터 필드를 단일 위치에 저장합니다. 따라서 데이터베이스 클러스터의 여러 노드에 레코드를 자동으로 배포("데이터베이스 샤딩")하는 것이 매우 쉽습니다. 이 접근 방식에는 장단점이 있습니다.
단점으로는 정규화 해제 시 데이터 집합의 전체 크기가 증가하고(정규화된 관계형 데이터베이스에서는 참조만 있을 수 있는 일부 데이터가 필연적으로 데이터베이스에 여러 번 저장되므로) 조인 수행의 복잡성이 증가한다는 것입니다. 장점은 여러 대의 저렴한 서버에 데이터를 분산하고 애플리케이션 중단 없이 필요에 따라 그 분포를 쉽게 변경할 수 있다는 점입니다. 또한 데이터를 삽입하기 전에 스키마를 미리 정의(또는 데이터베이스 스키마 변경)할 필요가 없습니다. 확실하지 않은 경우 저장하세요. 나중에 스키마를 유추할 수 있습니다. 이렇게 하면 이전에는 수집하지 못했던 정보를 훨씬 쉽게 수집할 수 있습니다. 이것이 바로 NoSQL 데이터베이스 기술이 궁극적으로 가장 큰 가치를 창출할 수 있는 부분일 것입니다.
이제 더 좋은 이름을 찾아봅시다.
우리는 NoSQL이라는 라벨을 버릴 준비가 되어 있습니다. 사람들이 보다 사용 사례 중심의 분류 체계를 중심으로 뭉칠 수 있다면, 이러한 시스템이 어떤 용도로 좋은지 고민하는 사용자들에게 큰 도움이 될 것이라고 믿습니다.
클라우드 데이터베이스는 위에서 설명한 모든 이유로 인해 Membase가 해결하고자 하는 문제의 핵심을 파악할 수 있는 이름입니다. 하지만 너무 트렌디하거나 무정형적일 수도 있습니다. 사람들의 의견을 듣고 싶습니다.
