많은 NoSQL 데이터베이스와 SQL 데이터베이스를 접했습니다. 이러한 데이터베이스의 강점과 약점을 측정하기위한 다양한 매개 변수가 있으며 확장 성은 그 중 하나입니다. 이러한 데이터베이스의 수평 및 수직 확장의 차이점은 무엇입니까?
답변:
수평 확장 은 리소스 풀에 더 많은 시스템 을 추가하여 확장하는 반면 수직 확장은 기존 시스템에 더 많은 전력 (CPU, RAM)을 추가하여 확장 할 수 있음을 의미합니다. .
이것을 기억하는 쉬운 방법은 서버 랙에있는 기계를 생각하는 것입니다. 수평 방향으로 더 많은 기계를 추가하고 수직 방향으로 더 많은 자원을 기계에 추가 합니다.
데이터베이스 세계에서 수평 스케일링은 종종 데이터의 파티셔닝을 기반으로합니다. 즉, 각 노드는 데이터의 일부만 포함합니다. 수직 스케일링에서 데이터는 단일 노드에 상주하며 스케일링은 멀티 코어를 통해 수행됩니다. 해당 머신의 CPU 및 RAM 리소스
수평 스케일링을 사용하면 기존 풀에 더 많은 머신을 추가하여 동적으로 스케일링하는 것이 더 쉬운 경우가 종종 있습니다. 수직 스케일링은 종종 단일 머신의 용량으로 제한되며, 용량을 초과하는 스케일링에는 종종 다운 타임이 발생하고 상한이 있습니다.
수평 스케일링의 좋은 예는 Cassandra, MongoDB, Google Cloud Spanner입니다 . 수직 스케일링의 좋은 예는 MySQL-Amazon RDS (클라우드 버전의 MySQL)입니다. 작은 기계에서 큰 기계로 전환하여 수직으로 쉽게 확장 할 수 있습니다. 이 프로세스에는 종종 다운 타임이 포함됩니다.
GigaSpaces XAP , Coherence 등과 같은 In-Memory Data Grid 는 종종 디스크에 바인딩되지 않기 때문에 수평 및 수직 스케일링에 모두 최적화됩니다. 다중 코어 지원을 통한 분할 및 수직 확장을 통한 수평 확장.
이전 게시물에서이 주제에 대한 자세한 내용을 확인할 수 있습니다 : 스케일 아웃 vs 스케일 업 및 NOSQL 대안의 공통 원칙
이제 시스템이 이전보다 더 많은 요청을 처리 할 수 있도록 리소스를 늘리는 확장이 필요합니다.
시스템 속도가 느려지고 현재 요청 수를 처리 할 수없는 경우 시스템을 확장해야합니다.
이것은 두 가지 옵션을 제공합니다. 현재 사용중인 서버의 리소스를 늘리십시오. 즉, RAM, CPU, GPU 및 기타 리소스의 양을 늘리십시오. 이것을 수직 스케일링이라고합니다.
수직 스케일링은 일반적으로 비용이 많이 듭니다. 시스템 내결함성을 유지하지 않습니다. 즉, 단일 서버로 실행중인 응용 프로그램을 확장하는 경우 해당 서버가 다운되면 시스템이 다운됩니다. 또한 스레드 크기는 수직 스케일링에서 동일하게 유지됩니다. 수직 스케일링은 프로세스가 진행되는 동안 잠시 시스템이 다운 될 수 있습니다. 서버에서 자원을 늘리려면 다시 시작해야하며 시스템이 중단됩니다.
이 문제에 대한 또 다른 해결책은 시스템에 존재하는 서버의 양을 늘리는 것입니다. 이 솔루션은 기술 산업에서 많이 사용됩니다. 결국 각 서버에서 초당 요청 속도가 줄어 듭니다. 시스템을 확장해야하는 경우 다른 서버를 추가하기 만하면됩니다. 시스템을 다시 시작할 필요는 없습니다. 각 시스템의 스레드 수가 줄어 처리량이 높아집니다. 각 애플리케이션 서버와 동일하게 요청을 분리하려면 웹 서버에 리버스 프록시 역할을하는로드 밸런서를 추가해야합니다. 이 전체 시스템을 단일 클러스터라고 할 수 있습니다. 시스템에 이와 같이 더 많은 양의 클러스터가 필요한 많은 수의 요청이있을 수 있습니다.
시스템에 스케일링을 도입하는 전체 개념을 얻으시기 바랍니다.
수동 샤딩의 복잡성없이 수평 확장을 가능하게하는 SQL 기반 데이터베이스 서비스 인 언급되지 않은 추가 아키텍처가 있습니다. 이러한 서비스는 백그라운드에서 샤딩을 수행하므로 전통적인 SQL 데이터베이스를 실행하고 MongoDB 또는 CouchDB와 같은 NoSQL 엔진과 마찬가지로 확장 할 수 있습니다. 내가 익숙한 두 가지 서비스 는 PostgreSQL 용 EnterpriseDB 와 MySQL 용 Xeround 입니다. Xeround의 심층 게시물을 통해 SQL 데이터베이스의 스케일 아웃이 왜 어려운지 설명하고 어떻게 다르게 수행하는지 설명했습니다. 벤더 게시물이므로 소금 한 알로 처리하십시오. Wikipedia의 Cloud Database 항목 도 확인하십시오., SQL 대 NoSQL 및 서비스 대 자체 호스팅, 벤더 목록 및 각 조합에 대한 확장 옵션에 대한 좋은 설명이 있습니다. ;)
수평 확장은 머신을 추가하는 것을 의미하지만 머신이 클러스터에서 동일 함을 의미합니다. MySQL은 복제본을 사용하여 데이터 읽기 측면에서 수평 적으로 확장 할 수 있지만 일단 서버 메모리 / 디스크 용량에 도달하면 서버 전체에서 데이터 샤딩을 시작해야합니다. 이것은 점점 더 복잡해진다. 복제 속도가 데이터 속도 변화에 대응하기에는 너무 느리기 때문에 복제본간에 데이터 일관성을 유지하는 것이 종종 문제입니다.
Couchbase는 또한 많은 상용 고 가용성 응용 프로그램 및 게임에서 사용되는 환상적인 NoSQL Horizontal Scaling 데이터베이스이며이 카테고리에서 가장 높은 성능을 자랑합니다. 클러스터 전체에서 데이터를 자동으로 분할하여 노드를 추가하는 것이 간단하며, 저렴한 가격의 상용 하드웨어 인스턴스 (예 : AWS의 High Mem, High Disk 머신 대신 Large를 사용)를 사용할 수 있습니다. Membase (Memcached)에서 빌드되었지만 지속성을 추가합니다. 또한 Couchbase의 경우 모든 노드가 읽기 및 쓰기를 수행 할 수 있으며 장애 조치 복제 (mySQL과 같은 모든 서버에서 전체 데이터 세트 복제가 아님) 만 클러스터에서 동일합니다.
성능 측면에서 우수한 Cisco 벤치 마크를 확인할 수 있습니다. http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server
다음은 Couchbase Architecture에 대한 훌륭한 블로그 게시물입니다. http://horicky.blogspot.com/2012/07/couchbase-architecture.html
기존의 관계형 데이터베이스는 클라이언트 / 서버 데이터베이스 시스템으로 설계되었습니다. 수평으로 확장 할 수 있지만 그렇게하는 프로세스는 복잡하고 오류가 발생하기 쉽습니다. NuoDB와 같은 NewSQL 데이터베이스는 기존 RDBMS의 SQL / ACID 속성을 유지하면서 수평으로 확장 할 수 있도록 설계된 메모리 중심 분산 데이터베이스 시스템입니다.
NuoDB에 대한 자세한 내용은 기술 백서를 참조하십시오 .
Oracle과 같은 SQL 데이터베이스 인 db2는 공유 디스크 클러스터를 통한 수평 확장도 지원합니다. 예를 들어 Oracle RAC, IBM DB2 purescale 또는 Sybase ASE Cluster edition입니다. 수평 확장을 달성하기 위해 Oracle RAC 시스템 또는 DB2 purescale 시스템에 새 노드를 추가 할 수 있습니다.
그러나 mongodb, CouchDB 또는 IBM Cloudant와 같은 noSQL 데이터베이스와 다른 접근 방식은 데이터 샤딩이 수평 확장의 일부가 아니라는 것입니다. noSQL 데이터베이스에서는 수평 스케일링 중에 데이터가 분쇄됩니다.
많은로드 밸런서를 추가하면 추가 오버 헤드와 대기 시간이 발생하며 이는 nosql 데이터베이스에서 수평으로 확장하기위한 단점입니다. 사람들이 RPC가 강력하지 않기 때문에 RPC가 권장되지 않는다고 말하는 이유와 같습니다.
실제 시스템에서는 오늘날 시스템의 멀티 코어 및 클라우드 컴퓨팅 기능을 모두 활용하기 위해 sql 및 nosql 데이터베이스를 모두 사용해야한다고 생각합니다.
반면에 복잡한 트랜잭션 쿼리는 Oracle과 같은 SQL 데이터베이스를 사용하는 경우 성능이 우수합니다. NoSql은 샤딩을 통한 빅 데이터 및 수평 확장성에 사용될 수 있습니다.
허용되는 답변은 수평 대 수직 스케일링의 기본 정의에 있습니다. 그러나 데이터베이스의 수평 확장은 Cassandra, MongoDB 등에서 만 가능하다는 일반적인 생각과 달리 수평 확장은 기존의 RDMS에서도 가능하다는 점을 덧붙이고 싶습니다. 타사 솔루션을 사용하지 않고도 마찬가지입니다.
많은 회사, 특히 SaaS 기반 회사를 알고 있습니다. 이것은 간단한 응용 프로그램 논리를 사용하여 수행됩니다. 기본적으로 일련의 사용자를 여러 DB 서버로 나눕니다. 예를 들어, 일반적으로 클라이언트, DB 서버 / 연결 문자열 등을 저장하는 "메타"데이터베이스 / 테이블과 클라이언트 / 서버 매핑을 저장하는 테이블이 있습니다.
그런 다음 각 클라이언트의 요청을 매핑 된 DB 서버로 전달하십시오.
이제 일부는 이것이 수평 분할과 유사하지만 "실제"수평 스케일링이 아니라고 말할 수 있으며 어떤 방식 으로든 적합 할 것입니다. 그러나 최종 결과는 여러 DB 서버로 DB를 확장 한 것입니다.
수평 적 확장에 대한 두 가지 접근 방식의 유일한 차이점은 DB 소프트웨어 자체에서 한 가지 접근 방식 (MongoDB 등)이 수행된다는 것입니다. 그런 의미에서 스케일링을 "구매"하고 있습니다. 다른 접근법 (RDBMS 수평 스케일링의 경우)에서 스케일링은 애플리케이션 코드 / 로직에 의해 빌드됩니다.
