개발자를 위한 NoSQL 가이드

백엔드 개발 및 빅 데이터의 추세를 따라왔다면 아마도 최근 몇 년 동안 NoSQL 데이터베이스에 대한 소문을 이미 알아차렸을 것입니다. 어떤 사람들은 데이터베이스에 대한 이러한 접근 방식에 영감을 받는 반면, 다른 사람들은 여기에 일종의 트릭이 숨겨져 있다고 생각합니다. 즉, 그 안에 있는 데이터 모델은 일반적인 관계형 데이터베이스와 동일하지 않고, 애플리케이션 프로그래밍 인터페이스도 특이하며, 응용 프로그램은 종종 이해하기 어렵습니다. 이 기사에서는 이러한 NoSQL 데이터베이스가 처음에 왜 만들어졌는지, 어떤 문제를 해결하는지, 왜 그렇게 많은 데이터베이스가 갑자기 필요한지 설명하겠습니다. NoSQL을 처음 접하는 경우, 해당 분야에 대한 철저한 이해를 얻기 위해 먼저 살펴볼 가치가 있다고 생각되는 NoSQL 데이터베이스 유형을 나열하는 기사의 마지막 부분에 특히 관심이 있을 것입니다.

갑자기 새로운 데이터베이스가 필요한 이유는 무엇입니까?

관계형 데이터베이스에 무슨 문제가 있나요?라는 질문이 어리둥절할 수도 있습니다. 요점은 그들이 수년 동안 정말 잘 작동했지만 이제는 더 이상 처리할 수 없는 문제가 있다는 것입니다. 일부 예측에 따르면 2018년 인류는 초당 50,000GB의 데이터를 생성할 것이라고 합니다. 이것은 엄청난 양의 데이터입니다! 보관 및 취급은 심각한 엔지니어링 문제를 야기합니다. 더 나쁜 것은 이 볼륨이 지속적으로 증가하고 있다는 것입니다. 결과적으로 관계형 데이터베이스는 대용량 데이터를 처리하는 데 적합하지 않습니다. 이는 단일 시스템에서 실행되도록 설계되었으며 더 많은 요청을 처리하려는 경우 유일한 옵션은 더 많은 RAM과 더 강력한 프로세서를 갖춘 컴퓨터를 구입하는 것입니다. 불행하게도 하나의 시스템이 처리할 수 있는 쿼리 수는 제한되어 있으며 여러 시스템에 걸쳐 작업을 분산하려면 다른 데이터베이스 기술이 필요합니다. 물론 일부 독자들은 이 시점에서 웃으며 관계형 데이터베이스의 경우 여러 시스템을 사용하는 데 널리 사용되는 두 가지 방법, 즉 복제와 샤딩이 있다고 말할 것입니다. 그것은 사실이지만 이러한 방법으로는 우리의 업무를 처리하기에는 충분하지 않습니다. 읽기 복제 는 각 데이터베이스 업데이트가 읽기 요청만 처리할 수 있는 다른 시스템으로 전파되는 기술입니다. 이 경우 모든 변경 사항은 마스터 노드라고 하는 한 서버에서 수행되고, 읽기 전용 복제본이라고 하는 다른 서버는 데이터의 복사본만 유지합니다. 사용자는 모든 머신에서 읽을 수 있지만 마스터 노드를 통해서만 데이터를 변경할 수 있습니다. 이는 편리하고 널리 사용되는 방법이지만 더 많은 읽기 요청을 처리할 수 있을 뿐이며 필요한 데이터 양을 처리하는 문제는 전혀 해결되지 않습니다. 샤딩은 관계형 데이터베이스의 여러 인스턴스를 사용하는 또 다른 인기 있는 접근 방식입니다. 각각은 데이터 일부에 대한 쓰기 및 읽기 작업을 처리합니다. 예를 들어 샤딩을 사용하여 데이터베이스가 고객에 대한 정보를 저장하는 경우 한 시스템은 이름이 A로 시작하는 고객에 대한 모든 요청을 처리할 수 있고, 다른 시스템은 이름이 B로 시작하는 고객에 대한 모든 데이터를 저장할 수 있습니다. 샤딩을 사용하면 더 많은 데이터를 기록할 수 있지만 이러한 데이터베이스를 관리하는 것은 정말 악몽입니다. ​​시스템 간에 데이터를 정렬하고 필요에 따라 클러스터를 양방향으로 확장해야 합니다. 이론상으로는 간단해 보이지만 올바르게 구현하는 것은 꽤 어렵습니다.

관계형 데이터베이스를 개선할 수 있나요?

여러분은 이미 관계형 데이터베이스가 현대 세계에서 생성되는 데이터의 양에 가장 적합하지 않다고 믿게 되었다고 생각합니다. 그럼에도 불구하고 왜 아직까지 여러 시스템에서 효율적으로 실행될 수 있는 "더 나은" 관계형 데이터베이스를 만든 사람이 없는지 궁금할 수도 있습니다. 이 기술은 아직 개발되지 않은 것처럼 보일 수 있으며 분산 관계형 데이터베이스가 곧 나타날 것입니다. 아아, 이런 일은 일어나지 않을 것이다. 이는 수학적으로 불가능하며 이에 대해 아무것도 할 수 없습니다. 이것이 왜 그런지 이해하려면 소위 CAP 정리(Brewer의 정리라고도 함)를 살펴봐야 합니다. 이는 1999년에 입증되었으며 여러 시스템에서 실행되는 분산 데이터베이스가 다음 세 가지 속성을 가질 수 있다고 명시합니다. 일관성 - 모든 읽기 작업은 마지막 해당 쓰기 작업의 결과를 반환합니다. 시스템이 일관성을 유지하는 경우 새 데이터를 쓴 후에는 이미 덮어쓴 이전 데이터를 읽을 수 없습니다. 가용성 ( 가용성 ) - 분산 시스템은 언제든지 들어오는 요청을 처리하고 오류 없는 응답을 반환할 수 있습니다. 파티션 허용 - 일부 서버가 일시적으로 서로 통신할 수 없는 경우에도 데이터베이스는 읽기 및 쓰기 요청에 계속 응답합니다 . 이러한 일시적인 장애를 네트워크 연결 장애라고 하며 서버 속도 저하로 인한 물리적 네트워크 문제부터 네트워크 장비의 물리적 손상까지 다양한 요인으로 인해 발생할 수 있습니다. 이러한 모든 속성은 확실히 편리하며, 우리는 이 모든 속성을 결합할 수 있는 데이터베이스를 정말로 원합니다. 제정신의 개발자라면 아무런 대가도 받지 못한 채 접근성을 포기하고 싶어하지 않을 것입니다. 불행하게도 CAP 정리는 세 가지 속성이 동시에 유지되는 것이 불가능하다고 명시합니다. 이것을 깨닫는 것은 쉽지 않을 수도 있지만 가능합니다. 첫째, 분산 데이터베이스가 필요한 경우 "연결 끊김을 허용"해야 합니다. 이것은 심지어 논의되지도 않았습니다. 연결 끊김은 항상 발생하며 , 그럼에도 불구하고 데이터베이스는 작동해야 합니다. 이제 일관성과 가용성을 모두 달성할 수 없는 이유를 살펴보겠습니다. A와 B라는 두 머신에서 실행되는 간단한 데이터베이스가 있다고 가정해 보겠습니다. 모든 사용자는 두 머신 중 하나에 쓸 수 있으며 그 후에 데이터가 다른 머신에 복사됩니다. 이제 이들 기계가 일시적으로 서로 통신할 수 없고, 기계 B가 기계 A와 데이터를 보내거나 받을 수 없다고 상상해 보십시오. 이 기간 동안 머신 B가 클라이언트로부터 읽기 요청을 받으면 두 가지 옵션이 있습니다.

1. 최신이 아니더라도 로컬 데이터를 다시 가져오세요. 이 경우 가용성이 우선시됩니다(최소한 일부 데이터, 심지어 오래된 데이터 반환).
2. 오류를 반환합니다. 이 경우 일관성이 선호됩니다. 클라이언트는 오래된 데이터를 수신하지 않지만 전혀 데이터를 수신하지 않습니다.

관계형 데이터베이스는 "일관성"과 "가용성"이라는 속성을 동시에 구현하려고 노력하므로 분산 환경에서는 작동할 수 없습니다. 분산 시스템에서 관계형 데이터베이스의 모든 기능을 구현하려는 시도는 비현실적이거나 실현 불가능할 것입니다 . 반면 NoSQL 데이터베이스는 확장성과 성능에 중점을 둡니다. 일반적으로 연결 및 트랜잭션과 같은 "기본" 기능이 부족하며 데이터 모델은 완전히 다르며 어떤 면에서는 제한적일 수도 있습니다. 이 모든 기능을 통해 이전보다 더 많은 양의 데이터를 저장하고 더 많은 쿼리를 처리할 수 있습니다.

NoSQL 데이터베이스는 일관성과 가용성의 균형을 어떻게 유지합니까?

NoSQL 데이터베이스를 선택하면 오류가 발생할 경우 항상 오래된 데이터나 오류가 발생하는 것처럼 보일 수 있습니다. 실제로 가용성과 일관성만이 사용 가능한 유일한 옵션은 아닙니다. 선택할 수 있는 옵션이 다양합니다. 관계형 데이터베이스에는 이러한 옵션이 없지만 NoSQL을 사용하면 유사한 방식으로 쿼리 실행을 제어할 수 있습니다. 어떤 방식으로든 NoSQL 데이터베이스에서 쓰기 또는 읽기 작업을 수행할 때 두 가지 매개변수를 설정할 수 있습니다. W - 쓰기 작업을 수행할 때 데이터 저장을 확인해야 하는 클러스터의 머신 수입니다 . 데이터를 쓰는 머신 수가 많을수록 다음 읽기 작업 시 가장 최근 데이터를 읽기가 더 쉬워지지만 시간도 오래 걸립니다. R – 데이터를 읽고 싶은 머신 수 . 분산 시스템에서는 클러스터의 모든 시스템에 데이터를 배포하는 데 시간이 걸릴 수 있으므로 일부 서버는 최신 데이터를 갖고 다른 서버는 지연됩니다. 데이터를 읽는 시스템 수가 많을수록 현재 데이터를 읽을 가능성이 높아집니다. 실제적인 예를 살펴보겠습니다. 클러스터에 5대의 컴퓨터가 있고 한 대에만 데이터를 쓴 다음 무작위로 선택한 컴퓨터에서 데이터를 읽기로 결정한 경우 오래된 데이터를 읽을 확률은 80%입니다. 반면에 최소한의 리소스가 사용됩니다. 따라서 레거시 데이터가 괜찮다면 그렇게 나쁜 선택은 아닙니다. 이 경우 매개변수 W와 R은 1과 같습니다. 반면, NoSQL 데이터베이스의 5개 머신 모두에 데이터를 쓰면 모든 머신에서 데이터를 읽을 수 있으며 매번 최신 데이터를 얻을 수 있습니다. 더 많은 수의 시스템에서 동일한 작업을 수행하면 시간이 더 오래 걸리지만 최신 데이터가 중요한 경우 이 옵션을 선택할 수 있습니다. 이 경우 W = R = 5입니다. 데이터베이스 일관성을 위해 필요한 최소 읽기 및 쓰기 수는 얼마입니까? 다음은 간단한 공식입니다: R + W ≥ N + 1 . 여기서 N은 클러스터에 있는 시스템의 수입니다. 이는 5개의 서버에서 R = 2 및 W = 4, R = 3 및 W = 3, R = 4 및 W = 2 중 하나를 선택할 수 있음을 의미합니다. 이 경우 데이터가 어느 머신에 있는지는 중요하지 않습니다. 기록되면 읽기는 항상 최신 데이터가 있는 하나 이상의 머신에서 수행됩니다. DynamoDB와 같은 다른 데이터베이스에는 다른 제한 사항이 있으며 일관된 쓰기만 허용됩니다. 각 데이터 조각은 3개의 서버에 저장되며, 데이터가 기록되면 3개의 시스템 중 2개에 기록됩니다. 그러나 데이터를 읽을 때 다음 두 가지 옵션 중 하나를 선택할 수 있습니다.

1. 엄격하게 일관된 읽기(Strict Consistency Read)는 세 대 중 두 대의 시스템에서 데이터를 읽고 항상 가장 최근에 작성된 데이터를 반환하는 방식입니다.
2. 데이터를 읽을 머신 하나가 무작위로 선택되는 최종 일관성 읽기입니다. 그러나 이로 인해 일시적으로 오래된 데이터가 반환될 수 있습니다.

NoSQL 데이터베이스가 왜 그렇게 많습니까?

소프트웨어 개발 분야의 최신 뉴스를 접한다면 MongoDB, DynamoDB, Cassandra, Redis 등 다양한 NoSQL 데이터베이스에 대해 들어보셨을 것입니다. 아마도 이렇게 다양한 NoSQL 데이터베이스가 필요한 이유가 무엇인지 궁금할 것입니다. 그 이유는 간단합니다. 다양한 NoSQL 데이터베이스가 다양한 문제를 해결하도록 설계되었기 때문입니다. 이것이 경쟁하는 데이터베이스의 수가 너무 많은 이유입니다. NoSQL 데이터베이스는 네 가지 주요 범주로 분류됩니다.

문서 중심 데이터베이스

이러한 데이터베이스는 복잡하게 중첩된 문서를 저장하는 기능을 제공하는 반면, 대부분의 관계형 데이터베이스는 1차원 행만 지원합니다. 이 기능은 예를 들어 시스템에 여러 주소가 있는 사용자에 대한 정보를 저장해야 하는 경우와 같이 많은 경우에 유용할 수 있습니다. 문서 지향 데이터베이스를 사용하는 경우 이 경우 주소 배열을 포함하는 복잡한 개체를 간단히 저장할 수 있는 반면, 관계형 데이터베이스에서는 두 개의 테이블(사용자 정보용 테이블과 주소용 테이블)을 만들어야 합니다. 문서 지향 데이터베이스는 개체 모델과 데이터 모델 사이의 격차를 해소합니다 . PostgreSQL과 같은 일부 관계형 데이터베이스도 이제 문서 지향 스토리지를 지원하지만 대부분의 관계형 데이터베이스에는 여전히 이 기능이 부족합니다.

키/값 데이터베이스

키/값 데이터베이스는 일반적으로 가장 간단한 NoSQL 모델을 구현합니다. 기본적으로 분산 해시 테이블을 제공하므로 주어진 키에 데이터를 쓰고 이를 사용하여 다시 읽을 수 있습니다. 키/값 데이터베이스는 확장성이 뛰어나고 다른 데이터베이스보다 대기 시간이 훨씬 짧습니다.

그래프 데이터베이스

예를 들어 소셜 네트워크나 영화 및 배우에 대한 정보와 같은 많은 주제 영역을 그래프로 표현할 수 있습니다. 관계형 데이터베이스를 이용해 그래프를 표현할 수는 있지만 어렵고 불편하다. 그래프 데이터가 필요한 경우 그래프에 대한 정보를 분산 클러스터에 저장할 수 있고, 그래프에 대한 알고리즘을 효율적으로 구현할 수 있는 전문적인 그래프 데이터베이스를 사용하는 것이 좋습니다.

컬럼형 데이터베이스

컬럼형 데이터베이스와 다른 유형의 데이터베이스 사이의 주요 차이점은 데이터가 디스크에 저장되는 방식입니다. 관계형 데이터베이스는 각 테이블마다 파일을 생성하고 모든 행의 값을 순차적으로 저장합니다. 열 기반 데이터베이스는 테이블의 각 열에 대한 파일을 생성합니다. 이 구조를 사용하면 데이터를 집계하고 특정 쿼리를 보다 효율적으로 실행할 수 있지만 데이터가 해당 데이터베이스의 제한 사항에 맞는지 확인해야 합니다.

어떤 데이터베이스를 선택해야 합니까?

데이터베이스를 선택하는 것은 일반적으로 실망스러운 문제이며, 사용 가능한 옵션이 너무 많아서 부담스러운 작업처럼 보일 수 있습니다. 좋은 소식은 하나만 선택할 필요가 없다는 것입니다. 모든 기능을 구현하고 모든 시스템 데이터에 액세스할 수 있는 단일 모놀리식 애플리케이션을 만드는 대신 마이크로서비스 라는 또 다른 최신 패턴을 사용할 수 있습니다. 즉 , 애플리케이션을 독립 서비스 세트로 분할합니다. 각 서비스는 자신의 제한된 문제를 해결하고 이 문제를 해결하는 데 가장 적합한 자체 데이터베이스만 사용합니다.

이 모든 것을 어떻게 배워야 합니까?

데이터베이스가 너무 많아서 모두 학습하는 것은 불가능한 작업처럼 보일 수 있습니다. 좋은 소식: 꼭 이렇게 할 필요는 없습니다. NoSQL 데이터베이스에는 몇 가지 기본 유형만 있으며, 작동 방식을 이해하면 나머지 유형도 훨씬 쉽게 이해할 수 있습니다. 또한 일부 NoSQL 데이터베이스는 다른 데이터베이스보다 훨씬 더 자주 사용되므로 가장 널리 사용되는 솔루션에 집중하는 것이 가장 좋습니다. 다음은 여러분이 살펴봐야 할 가장 일반적으로 사용되는 NoSQL 데이터베이스 목록입니다.

1. 몽고DB . 아마도 시장에서 가장 인기 있는 NoSQL 데이터베이스일 것입니다. 회사가 관계형 데이터베이스를 기본 데이터 저장소로 사용하지 않는다면 아마도 MongoDB를 사용할 것입니다. 이것은 좋은 도구 세트를 갖춘 유연한 문서 저장소입니다. MongoDB는 초기에 어떤 경우에는 데이터 손실 로 인해 나쁜 평판을 받았지만 그 이후로 안정성과 신뢰성이 크게 향상되었습니다. 더 자세히 알고 싶다면 이 MongoDB 과정을 살펴보세요


2. 다이나모DB . Amazon Web Services(AWS)를 사용한다면 DynamoDB에 대해 자세히 알아보는 것이 좋습니다. 풍부한 기능 세트와 다른 많은 AWS 서비스와의 통합을 갖춘 매우 안정적이고 확장 가능하며 지연 시간이 짧은 데이터베이스입니다. 가장 좋은 점은 직접 배포할 필요가 없다는 것입니다. 수천 개의 쿼리를 처리할 수 있는 확장 가능한 DynamoDB 클러스터를 설정하는 것은 몇 번의 클릭만으로 가능합니다. 관심이 있으시면 이 과정을 살펴보세요.


3. Neo4j . 가장 일반적인 그래프 데이터베이스입니다. 그래프 데이터 모델을 사용하려는 사람들에게 적합한 확장 가능하고 안정적인 솔루션입니다. 더 자세히 알아보려면 이 과정부터 시작하세요 .


4. 레디스 . 여기에 설명된 다른 데이터베이스는 핵심 애플리케이션 데이터를 저장하는 데 사용되는 반면 Redis는 주로 캐시를 구현하고 보조 데이터를 저장하는 데 사용됩니다. 많은 경우 위에서 언급한 데이터베이스 중 하나가 Redis와 함께 사용됩니다. 자세한 내용은 이 과정을 확인하세요 .

2018년에는 NoSQL로

NoSQL 데이터베이스는 광범위하고 빠르게 성장하는 분야입니다. 이를 통해 이전에는 상상할 수 없었던 양의 데이터를 저장하고 처리할 수 있지만 비용이 발생합니다. 이러한 데이터베이스에는 관계형 데이터베이스에서 익숙한 기능이 많지 않으며 이를 사용하도록 설정하는 것이 어려울 수 있습니다. 그러나 일단 익숙해지면 엄청난 양의 읽기 및 쓰기 요청을 처리할 수 있는 확장 가능한 분산 데이터베이스를 생성할 수 있습니다. 이는 점점 더 많은 양의 데이터가 생성됨에 따라 매우 중요할 수 있습니다. 원본: https://simpleprogrammer.com/guide-nosql-software-developers/