사용 사례들이 NoSQL 솔루션의 분화와 수렴을 이끌고 있습니다.

오늘 아침, The 451 블로그의 Matt Aslett은 다음과 같이 블로그에 남겼습니다. NoSQL의 종말의 시작 그는 그 안에서 NoSQL이라는 범주 이름이 쓸모없다는 점을 강조했다. 언제나 그렇듯이 좋은 글이다. 하지만 새로운 소식은 아니다. 사람들은 그 용어가 만들어진 날부터 불평해 왔다.

나는 “어떤 문제를 해결하려고 하는가?”와 같은 유스케이스에 초점을 맞추는 것이 레이블에 초점을 맞추는 것보다 훨씬 더 생산적일 것이라는 맷의 의견에 전적으로 동의합니다. 그러나 맷이 기본 데이터 모델(키-값, 문서, 열 지향, 그래프 등)의 관점에서 분류하는 것이 더 유용할 수 있음을 암시하는 듯한 부분에는 동의하지 않습니다. 이러한 범주들은 특정 작업에 대한 목적 적합성을 평가하는 데 초점을 맞출 경우 미미한 개선만을 제공합니다.

몽고는 도큐먼트 데이터베이스입니다. 카우치도 마찬가지입니다. 하지만 이 두 솔루션은 유스케이스 관점에서 극단적으로 다른 방향으로 향하고 있습니다.

몽고는 문서 데이터베이스입니다. 카산드라는 열 지향 데이터베이스입니다. 멤베이스 그리고 리아크는 키-값 저장소이다. 그러나 이 솔루션들은 사용 사례 관점에서 정면충돌하고 있다. 이들은 현재 고객들에 의해 상호 교환 가능하게 평가되고 있으며, 각각은 기반 데이터 모델과 전혀 관련 없는 기능들에 따라 종종 승패가 갈리고 있다.

그렇습니다. NoSQL은 쓸모없는 분류명입니다.

NoSQL이라는 명칭이 별루인 데에는 적어도 두 가지 좋은 이유가 있습니다:

1. 일부 “NoSQL” 시스템은 실제로 SQL의 방언을 제공합니다. 데이터베이스 내의 데이터에 엑세스하기 위한 쿼리 언어로, Google App Engine에는 GQL 언어. 퀘스트에는 Toad for Cloud Databases Hbase, Azure Tables, Amazon의 SimpleDB 및 기타 “NoSQL” 데이터베이스를 위한 SQL 인터페이스를 제공하고자 하는. 하이브 하둡에 SQL의 방언을 도입하여 ETL을 용이하게 합니다.
2. 맷이 지적했듯이, NoSQL이라는 명칭 아래 너무 많은 종류의 기술이 한데 묶여 있다 오늘날. 의심의 여지가 없습니다. 그러나 복잡한 기술 스택의 한 가지 측면만 이야기하는 것은 실제 문제를 해결하는 데 거의 도움이 되지 않는다고 제안합니다. 인간은 개념과 사물을 분류할 수 있는 깔끔하고 정돈된 범주를 갈망하도록 프로그래밍되어 있습니다. 하지만 몽고(Mongo)의 레이블로서 NoSQL은 몽고가 문서 데이터베이스라고 말하는 것보다 아주 조금 더 유용할 뿐이라고 제안합니다., 당신이 알아내려고 하는 것이 그것이 무엇에 좋은지라면 ~를 위해.

데이터 모델에 따라 분류하는 것도 별 소용이 없다.

그렇다면 이 모든 신흥 솔루션을 아우를 수 있는 깔끔하고 대표적인 카테고리 구성은 과연 무엇일까요? 관찰자가 특정 유스케이스에 해당 솔루션 카테고리가 적절한지 여부를 실제로 판단할 수 있게 해주는 그런 카테고리 말입니다. 저에게는 그 답이 없고, 마땅한 답이 있는지도 잘 모르겠습니다. 어쩌면 사용 사례 그 자체야말로 올바른 범주화를 제공할지도 모른다. 어쨌든, 맷이 언급한 대로 이러한 “데이터베이스 대안”에 대한 사고를 체계화하는 데 도움이 될 것이라고 하는 451 보고서를 읽어보기를 기대하고 있습니다.”

궁극적으로 이러한 솔루션을 분류하려면 기본 데이터 모델(키-값, 문서, 컬럼 지향, 그래프 등)만을 넘어 더 넓은 관점에서 살펴봐야 합니다. 오히려 이러한 시스템들은 더 광범위하면서도 관리 가능한 속성 집합을 바탕으로 비교되어야 합니다. 예를 들어, 데이터를 삽입하기 전에 스키마를 선언해야 하는가? 필요한 경우 스키마를 즉석에서 변경할 수 있는가? 이를 수행하는 것이 얼마나 어려운가? 데이터베이스가 (애플리케이션에 대해) 투명하게 여러 대의 서버에 분산될 수 있는가, 아니면 단일 서버 중심의 솔루션인가? 용량을 추가하거나 제거하기 위해 데이터베이스를 중단해야 하는가? 쿼리 언어를 사용하여 데이터베이스를 조회할 수 있는가, 아니면 코드를 작성해야 하는가? 시스템이 쿼리 속도를 높이기 위해 인덱스를 관리하는가? 데이터베이스는 무작위 및 순차 작업에서 어떤 성능을 보이나요? 읽기 대비 쓰기 성능은 어떤가요? 데이터는 내구성 있는 매체에 즉시 기록되나요, 아니면 나중에 기록되나요? 노드 장애 시 데이터 손실 위험은 어느 정도인가요? 데이터센터 장애 시에는 어떨까요? 동기식 작업을 통해 이러한 위험을 줄일 수 있을까요? 그렇게 할 경우 성능에는 어떤 영향을 미칠까요? 데이터베이스가 데이터센터 경계를 넘어 작동할 수 있나요? 작성한 데이터는 항상 읽을 수 있나요, 아니면 리더 간에 데이터 불일치가 발생하는 기간이 있나요?

특정 사용 사례에 대한 목적 적합성을 확인하고자 할 때 이는 분명히 훨씬 더 관련성 높은 질문들입니다. 다시 말하지만, 이러한 질문들에 대한 답변을, 해당 시스템들이 분류되고 있는 세부 범주와 비교해 볼 때 상관계수가 낮은 것으로 나타난다; 그리고 그것들을 모두 하나의 커다란 “NoSQL” 범주에 집어넣든, 아니면 단일 축 데이터 모델 중심 접근 방식(키-값, 문서, 열 지향, 그래프 등)을 기반으로 하위 범주로 나누든 그것은 중요하지 않습니다.

NoSQL은 단순히 90년대 후반 OODBMS 실패의 반복인가?

도대체 왜 NoSQL을 둘러싸고 이토록 큰 소란이 일고 있는 걸까요? 이건 단지 1990년대 후반 우리 모두가 겪었던 객체 지향 데이터베이스(OODB) 열풍의 재현일 뿐인가? 그 당시의 대실패에서 OODBMS 공급업체, 전문가, 투자자들은 점점 더 지배적인 객체 지향 애플리케이션 개발 모델과 “임피던스 불일치’가 심하다는 이유로 관계형 데이터베이스 기술을 희생양으로 삼았다. 개발자들이 데이터를 네이티브 객체 형태로 데이터베이스에 저장하는 것이 더 ”자연스럽다“는 주장이 있었으며, 효율성도 더 높을 것이라는 논리가 제시되기도 했습니다.

하지만 실제로 해결되던 고통은 거의 없었다. 사실, 이미 작동하는 친숙한 기술에서 더 “우아하고” 이론적으로 올바른 접근 방식을 약속하는 검증되지 않은 솔루션으로의 전환은 실제로 단 한 가지, 즉 혼란만을 보장할 뿐이었다. 객체 데이터 모델과 관계형 데이터 모델 간의 “불일치”를 해소하기 위해 설계된 객체-관계 매핑(ORM) 레이어가 완벽한 것은 아니다. 하지만 굳이 그럴 필요가 없다면 세상을 뒤집어엎는 것보다는 낫다. 분석가들이 OODBMS 시장에 대해 예측했던 수백억 달러의 수익은 실현조차 되지 않았다.

그렇다면 지금 진정한 문제가 존재합니까? 기존 데이터베이스 기술이 진정으로 부족한 실제 사용 사례가 있습니까? 기술 전환의 파괴적 혁신이 실질적인 경제적 영향을 미칠 곳이 있습니까? 대답은 그렇다입니다.

사용 사례가 NoSQL 솔루션의 분화와 통합을 주도하고 있다.

소파가 ~를 차지했다 모바일 데이터 동기화 사용 사례. 모바일 기기가 점점 지배해 가는 컴퓨팅 세계에서, (네트워크에 연결되어 있지 않을 때도 데이터를 사용할 수 있도록) 클라우드와 모바일 기기 간의 데이터 동기화는 많은 애플리케이션이 해결해야 하는 문제이다. 간헐적인 연결, 이러한 동기화된 데이터베이스가 실행되어야 하는 매우 다양한 플랫폼, 그리고 아마도 이동하고 동기화되는 데이터 세트가 일반적으로 단일 상자나 기기에 맞아야 한다는 기대 등 고려해야 할 사항이 많다. Couch는 이러한 요구 사항에 초점을 맞추고 적절한 단순화 가정을 함으로써, 그 어떤 것보다 더 나은 방식으로 이 사용 사례를 해결할 수 있게 해준다. Couch는 문서 데이터베이스이다. Mongo도 그렇다. Mongo는 이 사용 사례에는 적합하지 않은 솔루션이다. Mongo는 일시적으로 연결되는 시스템들을 동기화 상태로 유지하도록 설계되지 않았으며, Mongo가 애초에 단일 노드 데이터베이스로 설계되었다는 사실에도 불구하고 작년에 이루어진 샤딩 및 복제 작업은 Mongo가 다른 방향으로 나아가고 있음을 명백히 보여준다. 이 경우, 분명히 발산 NoSQL 시장의 더 좁은 “문서 데이터베이스” 분야 내에서조차도 다양한 솔루션들이 존재합니다.

반면에 교차 카테고리가 있습니다 융합 대화형 웹 애플리케이션의 데이터를 저장하는 또 다른 매우 크고 일반적인 사용 사례를 해결하고자 하는 다른 NoSQL 솔루션들 사이에서 발생하고 있습니다. Membase에서는 매주 이 문제로 고심하는 많은 잠재적 사용자들과 이야기를 나누고 있으며, 지속적으로 Cassandra(열 기반), Mongo(문서 기반), Riak(키-값 기반)과 비교 평가를 받고 있습니다.

조직이 소비자와 직접 소통할 수 있게 해주는 웹 애플리케이션은, 현재 구축되고 있는 새로운 대화형 소프트웨어 시스템 중 가장 일반적인 형태로 점점 더 자리 잡고 있습니다. 이러한 시스템은 대규모 사용자 집단에 의한 무작위적인 동시 사용 패턴이 특징이며 (많은 청중) 그리고 대규모 데이터 세트를 축적하려는 성향에 의해 (빅데이터). 또한, 특히 이러한 부류의 애플리케이션에 대해 클라우드 컴퓨팅 모델로의 전환이 추진되고 있으며, 여기서는 대형 전용 “빅 아이언” 머신에서 워크로드를 실행하는 것보다 “스케일 아웃”(더 많은 클라우드 머신 인스턴스, 가상 머신 또는 범용 서버 추가)이 선호됩니다. 이러한 현실로 인해 처음부터 설계되어 가능하게 해주는 새로운 부류의 데이터베이스 관리 시스템에 대한 광범위한 필요성이 대두되었습니다. 수평 확장 그리고 빠르게 성장하는 데이터 세트에 대해 높은 수준의 동시성을 비용 효율적으로 지원하기 위해. 아마도 우리는 이것을 다음과 같이 부를 수 있습니다. 클라우드 데이터베이스, 탄력적 데이터베이스, 스케일아웃 데이터베이스 또는 오토 샤딩(: P) 데이터베이스 유스케이스.

그렇다면 이 문제를 해결하기 위해 데이터베이스가 제공해야 하는 것은 무엇일까? 나는 그것이 단순하고, 빠르고, 탄력적이며, 안전해야 한다고 주장한다. 이 일반화된 “클라우드 데이터베이스” 문제를 명시적으로 해결하고자 하는 Membase, Mongo, Cassandra, Riak을 고려해 보면, 이 각 항목에 대한 점수는 다양하다.

첫 번째 특성부터 살펴보겠습니다. 성공하려면 범용 클라우드 데이터베이스는 구하기 쉽고, 이를 기반으로 개발하기 쉬우며, 운영 환경에서 다루기 쉬워야 합니다.

• Membase는 극도로 구입, 설치 및 사용이 쉬운. 몽고도 마찬가지입니다. 어떤 경우에는 Membase보다 쉽고, 어떤 경우에는 더 어렵습니다. 카산드라는 거의 모든 상황에서 어렵습니다.
• 몽고는 개발하기 쉬운 – 데이터베이스 내에서 풍부한 쿼리, 인덱스 관리, 그리고 흥미로운 다양한 데이터 타입에 대한 연산 기능을 제공합니다. Membase는 개발자에게 Memcached 호환 키-값 API를 제공하는데, 이는 사용하기는 매우 쉽지만 Mongo에 비해 많은 일반적인 데이터베이스 연산에서 애플리케이션 개발자에게 더 큰 부담을 줍니다. Cassandra는 더 복잡한 개발 모델을 제공하지만 풍부한 쿼리를 허용합니다. Riak 쿼리는 전적으로 맵리듀스(map-reduce)에 의존합니다.
• Membase는 프로덕션에서 관리하기 쉬운, 소규모 또는 대규모 서버 클러스터의 운영에 대한 깊은 통찰력을 제공하여 시스템 가동 시간을 높여주는 풍부한 모니터링 및 관리 도구 세트를 제공합니다. Mongo는 클러스터 운영에 대한 통찰력이 훨씬 적으며, 이러한 결함은 FourSquare 장애 이후 Mongo가 주로 지적한 부분이었습니다.

나머지 특성인 빠름, 유연성, 안전성에 대해서도 유사한 비교를 할 수 있습니다. 각 솔루션은 이러한 영역 중 특정 부분에서는 강하고 다른 부분에서는 상대적으로 약합니다.

하지만 가장 중요한 점은 이러한 솔루션들은 각각 상대적인 취약점을 보완하기 위해 움직이고 있습니다. 고객의 요구를 더 잘 충족하기 위해서입니다. 유스케이스에 의해 주도되는 수렴 현상이 존재합니다. 단순한 훌륭한 키-값, 문서, 또는 열 지향 데이터베이스 관리 시스템이 되는 것에 초점을 맞춘 프로젝트는 없습니다. 각 프로젝트는 앞서 설명한 바와 같이 대화형 웹 애플리케이션 이면에 데이터를 저장할 비용 효율적인 공간을 제공하는 등 실제 세계의 문제를 해결하는 데 초점을 맞추고 있습니다. 이를 위해 Membase는 쿼리 및 색인 기능을 추가하고 있습니다. Mongo는 최근 초기 단일 서버 솔루션에 샤딩 및 복제 지원을 소급 적용했으며, 데이터 안전성을 높이기 위해 스토리지 엔진을 재설계하고 있습니다. 또 다른 “NoSQL” 솔루션인 Redis는 진정한 “탄력적(elastic)”인 성격을 갖추기 위해 클러스터 관리 기능을 추가하고 있습니다. 이 사용 사례를 대상으로 하는 솔루션들 사이에는 명확한 수렴이 있습니다. 이 프로젝트들은 각각 광고 및 오퍼 타겟팅, 소셜 게이밍, 웹 응용프로그램 세션 상태 관리, 그리고 실시간 이벤트 처리를 자사의 시스템이 의도된 사용 사례로 식별합니다. 이들은 모두 대화형 웹 응용프로그램 사용 사례입니다.

비관계형 데이터베이스는 클라우드 데이터베이스에서 진정하고 일관된 기술적 흐름입니다.

기술적 관점에서 이러한 클라우드 데이터베이스 솔루션들에 대해 일관되게 말할 수 있는 한 가지가 있습니다. 그것들은 수평적 확장을 목표로 하며, 관계형 데이터 모델을 채택하면서 허용 가능한 성능으로 비용 효율적으로 그렇게 하는 것은 매우 어렵고(불가능에 가깝습니다). 따라서 이러한 각 “NoSQL” 데이터베이스 시스템은 “비관계형” 시스템입니다. 그것이 궁극적으로 “NoSQL”이 의도했던 바입니다.”

사실 이러한 각 시스템의 핵심은, 키-값 저장소. 그것들은 값 내부를 들여다보거나 값들을 그룹화하여 처리하는 데 사용되는 기법에서 차이가 납니다(키-값(key-value) 방식은 값을 내부를 알 수 없는 덩어리로 보고, 문서(document) 방식은 값을 서식화된 속성-데이터 타입 모음으로 보며, 열 지향(column-oriented) 저장소는 별도의 데이터 구조를 사용하여 개별 KV 쌍을 “열”로 그룹화합니다). 그러나 관계형 모델에서처럼 데이터 레코드(튜플)를 상호 참조되는 정규화된 테이블 세트에 분산 저장하는 것과 달리, 각 경우에 이러한 클라우드 데이터베이스는 특정 “레코드”의 데이터 필드를 단일 위치에 저장합니다. 이로 인해 데이터베이스 클러스터 내의 여러 노드에 걸쳐 레코드를 자동으로 분산(“데이터베이스 샤딩”)하는 것이 매우 쉬워집니다. 이 접근 방식에는 장단점이 있습니다.

단점 측면에서, 비정규화는 (정규화된 관계형 데이터베이스였다면 참조 형태로만 존재했을 일부 데이터가 데이터베이스 내에 불가피하게 여러 번 저장됨으로써) 데이터셋의 총 용량을 증가시키고, 조인 작업의 복잡성을 증가시킵니다. 장점 측면에서는, 데이터를 여러 저렴한 서버에 쉽게 분산시키고 애플리케이션 중단 없이 필요에 따라 해당 분산 방식을 변경할 수 있게 해줍니다. 또한 데이터를 삽입하기 전에 스키마를 미리 정의해야 하는(또는 데이터베이스 스키마를 변경해야 하는) 요구 사항을 없애줍니다. 의심스러울 때는 일단 저장하십시오. 스키마는 나중에 유추할 수 있습니다. 이는 이전에 수집되지 않았을 수도 있는 정보를 훨씬 더 쉽게 수집할 수 있도록 만들어 줍니다. 궁극적으로 이것이 바로 NoSQL 데이터베이스 기술이 가장 큰 가치를 창출하게 될 부분일 것입니다.

그럼 더 나은 이름을 찾아봅시다.

우리는 NoSQL이라는 명칭을 버릴 준비가 되어 있습니다. 만약 사람들이 좀 더 유스케이스 중심의 분류 체계를 결집할 수 있다면, 이는 이러한 시스템이 무엇에 유용한지 파악하느라 고군분투하는 사용자들에게 큰 승리가 될 것이라고 믿습니다.

클라우드 데이터베이스는 위에서 설명한 모든 이유로 인해 멤베이스가 해결하고자 하는 문제의 본질을 정확히 짚어내는 이름입니다. 하지만 다소 유행에 치우치거나 모호할 수도 있습니다. 다른 분들의 의견이 궁금합니다.