데이터베이스에 대해 수평 및 수직 스케일의 차이
저는 많은 NoSQL 데이터베이스와 SQL 데이터베이스를 발견했습니다.이러한 데이터베이스의 강점과 약점을 측정하기 위한 다양한 매개변수가 있으며 그 중 하나가 확장성입니다.이러한 데이터베이스를 수평적으로 확장하는 것과 수직적으로 확장하는 것의 차이점은 무엇입니까?
수평 확장은 리소스 풀에 더 많은 시스템을 추가하여 확장하는 것을 의미하며 수직 확장은 기존 시스템에 더 많은 전력(CPU, RAM)을 추가하여 확장하는 것을 의미합니다.
이를 쉽게 기억할 수 있는 방법은 서버 랙에 있는 시스템을 떠올리면 수평 방향으로 더 많은 시스템을 추가하고 수직 방향으로 더 많은 리소스를 시스템에 추가할 수 있습니다.
데이터베이스 세계에서 수평 스케일링은 종종 데이터의 분할(partitioning)을 기반으로 합니다. 즉, 각 노드는 데이터의 일부만을 포함하고 수직 스케일링의 경우 데이터는 단일 노드에 존재하며 스케일링은 멀티 코어(multi-core)를 통해 수행됩니다. 즉, 해당 머신의 CPU와 RAM 리소스 간에 부하를 분산시키는 것입니다.
수평 확장을 사용하면 기존 풀에 더 많은 머신을 추가하여 동적으로 확장하기가 더 쉬워집니다. 수직 확장은 종종 단일 머신의 용량으로 제한되며, 그 용량 이상으로 확장할 경우 다운타임이 수반되며 상한이 발생합니다.
수평 스케일링의 좋은 예로는 Cassandra, MongoDB, Google Cloud Spanner 등이 있으며 수직 스케일링의 좋은 예로는 MySQL - Amazon RDS(MySQL의 클라우드 버전)가 있습니다.작은 기계에서 큰 기계로 전환하여 수직으로 쉽게 확장할 수 있습니다.이 프로세스는 종종 다운타임을 수반합니다.
기가스페이스 XAP, 코히어런스 등 인메모리 데이터 그리드.단순히 디스크에 구속되지 않기 때문에 수평 및 수직 스케일링에 모두 최적화되는 경우가 많습니다.파티션 분할을 통한 수평 확장 및 멀티 코어 지원을 통한 수직 확장.
이전 게시물인 스케일 아웃 대 스케일 업 및 NOSQL 대안 뒤의 공통 원칙에서 이 주제에 대해 더 자세히 읽을 수 있습니다.
수평 스케일 조정 ===> 수천 명의 미니언이 함께 작업을 수행합니다.
세로로 스케일링하기===> 큰 헐크 하나면 모든 작업이 가능합니다.
먼저 리소스를 증가시키는 확장의 필요성부터 시작하여 시스템이 이전보다 더 많은 요청을 처리할 수 있도록 하겠습니다.
시스템 속도가 느려져서 현재 요청 수를 처리할 수 없다는 것을 알게 되면 시스템을 확장해야 합니다.
그러면 두 가지 옵션이 제공됩니다.현재 사용 중인 서버의 리소스를 늘리거나, 즉 RAM, CPU, GPU 및 기타 리소스의 양을 늘립니다.이를 수직 스케일링이라고 합니다.
수직 스케일링은 일반적으로 비용이 많이 듭니다.단일 서버로 실행되는 응용프로그램을 확장하는 경우, 해당 서버가 다운되면 시스템이 다운되는 등 시스템 장애에 장애가 발생하지 않습니다.또한 수직 스케일링에서 스레드의 양은 동일하게 유지됩니다.수직 스케일링은 프로세스가 진행될 때 시스템이 잠시 중단되어야 할 수도 있습니다.서버에서 리소스를 늘리려면 시스템을 다시 시작해야 합니다.
이 문제에 대한 또 다른 해결책은 시스템에 존재하는 서버의 양을 늘리는 것입니다.이 솔루션은 기술 산업에서 많이 사용됩니다.이렇게 하면 결국 각 서버의 초당 요청 속도가 줄어듭니다.시스템을 확장해야 할 경우 다른 서버를 추가하면 됩니다.시스템을 다시 시작할 필요가 없습니다.각 시스템의 스레드 수가 감소하여 처리량이 높아집니다.각 응용 프로그램 서버에 동일하게 요청을 분리하려면 웹 서버에 역방향 프록시 역할을 하는 로드 밸런서를 추가해야 합니다.이 전체 시스템을 하나의 클러스터라고 부를 수 있습니다.시스템에 이와 같은 클러스터가 더 많이 필요한 요청이 많을 수 있습니다.
시스템에 확장을 도입하는 개념을 모두 이해하시기 바랍니다.
언급하지 않은 추가 아키텍처도 있습니다. 즉 수동 공유의 복잡성 없이 수평적 확장이 가능한 SQL 기반 데이터베이스 서비스입니다.이러한 서비스는 백그라운드에서 샤딩을 수행하므로 기존 SQL 데이터베이스를 실행하고 MongoDB 또는 CouchDB와 같은 NoSQL 엔진처럼 스케일아웃할 수 있습니다.제가 잘 아는 두가지 서비스는 Enterprise입니다.Postgre용 DBMySQL용 SQL 및 Xeround.SQL 데이터베이스에서 스케일 아웃이 어려운 이유와 이를 다르게 수행하는 방법을 설명하는 Xeround의 심층 게시물을 보았습니다. 공급업체 게시물인 만큼 이를 좀 더 신중하게 다루십시오.Wikipedia의 Cloud Database 항목도 확인하십시오. SQL vs.에 대한 멋진 설명이 있습니다.SQL 및 서비스 없음 대 자체 호스팅, 벤더 목록 및 각 조합에 대한 확장 옵션. ;)
예, 수평으로 스케일링한다는 것은 더 많은 시스템을 추가한다는 것을 의미하지만, 이는 또한 시스템이 클러스터에서 동일하다는 것을 의미합니다.MySQL은 복제본을 사용하여 데이터 읽기 측면에서 수평으로 확장할 수 있지만, 서버 메모리/디스크 용량에 도달하면 서버 간에 데이터 공유를 시작해야 합니다.이 문제는 점점 더 복잡해집니다.복제 속도가 데이터 변경 속도를 따라가지 못하는 경우가 많기 때문에 복제본 간에 데이터 일관성을 유지하는 것이 문제가 됩니다.
또한 Couchbase는 환상적인 NoSQL 수평 스케일링 데이터베이스로, 많은 상용 고가용성 애플리케이션과 게임에 사용되며 이 범주에서 가장 높은 성능을 자랑합니다.클러스터 간에 데이터를 자동으로 파티셔닝하여 노드를 쉽게 추가할 수 있으며 상용 하드웨어, 저렴한 VM 인스턴스(예: AWS에서 High Mem 대신 Large를 사용)를 사용할 수 있습니다.멤피스(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와 같은 새로운 SQL 데이터베이스는 기존 RDBMS의 SQL/ACID 특성을 유지하면서 수평적으로 확장할 수 있도록 설계된 메모리 중심의 분산형 데이터베이스 시스템입니다.
NuoDB에 대한 자세한 내용은 기술 백서를 참조하십시오.
Oracle, db2와 같은 SQL 데이터베이스도 Shared Disk 클러스터를 통한 수평 확장을 지원합니다.예를 들어 Oracle RAC, IBM DB2 Purescale 또는 Sybase ASE Cluster 버전이 있습니다.새로운 노드를 Oracle RAC 시스템 또는 DB2 Purescale 시스템에 추가하여 수평적 확장을 달성할 수 있습니다.
그러나 데이터 공유가 수평 확장의 일부가 아니라는 점에서 mongodb, CouchDB 또는 IBM Cloudant와 같은 noSQL 데이터베이스와는 접근 방식이 다릅니다.noSQL 데이터베이스에서는 수평 스케일링 중에 데이터가 쉐이딩됩니다.
허용된 답변은 수평 스케일 대 수직 스케일의 기본 정의에 있습니다.그러나 데이터베이스의 수평 확장은 Cassandra, MongoDB 등을 통해서만 가능하다는 일반적인 통념과는 달리, 기존의 RDMS를 통해서도 수평 확장이 가능하며, 타사 솔루션을 사용하지 않아도 가능하다는 점을 덧붙이고 싶습니다.
저는 많은 회사들을 알고 있는데, 특히 SaaS 기반으로 이런 일을 하는 회사들을 알고 있습니다.이 작업은 간단한 응용프로그램 로직을 사용하여 수행됩니다.기본적으로 사용자 집합을 가져다가 여러 DB 서버에 걸쳐 분할합니다.예를 들어, 일반적으로 클라이언트, DB 서버/연결 문자열 등을 저장하는 "메타" 데이터베이스/테이블과 클라이언트/서버 매핑을 저장하는 테이블이 있습니다.
그런 다음 각 클라이언트의 요청을 매핑된 DB 서버로 직접 전송하기만 하면 됩니다.
이제 어떤 사람들은 이것이 수평 분할과 비슷하고 "진정한" 수평 확장이 아니라고 말할지도 모릅니다. 어떤 면에서는 그들이 옳을 것입니다.하지만 결국 여러 Db 서버에 걸쳐 DB 규모를 조정하게 됩니다.
수평 확장에 대한 두 접근법의 유일한 차이점은 하나의 접근법(MongoDB 등)이 DB 소프트웨어 자체에 의해 확장이 이루어진다는 것입니다.그런 의미에서 당신은 스케일링을 "구매"하는 것입니다.다른 접근 방식(RDBMS 수평 스케일링의 경우)에서, 스케일링은 애플리케이션 코드/논리에 의해 구축됩니다.
로드 밸런서를 많이 추가하면 오버헤드와 지연 시간이 추가되므로 nosql 데이터베이스에서 수평적으로 스케일아웃할 수 있다는 단점이 있습니다.RPC가 강하지 않은데 왜 RPC를 추천하지 않느냐는 질문과 같습니다.
실제 시스템에서는 sql과 nosql 데이터베이스를 모두 사용하여 오늘날의 시스템의 멀티코어 및 클라우드 컴퓨팅 기능을 모두 활용해야 한다고 생각합니다.
반면 복잡한 트랜잭션 쿼리는 오라클과 같은 sql 데이터베이스를 사용하는 경우 성능이 높습니다.공유를 통해 빅데이터와 수평적 확장성을 위해 어떤 Sql도 사용할 수 없었습니다.
회사가 있고 근로자는 1명뿐인데 신규 지원자를 채용할 때 1개의 신규 프로젝트를 받았습니다. 수평적 확장입니다.여기서 새로운 후보는 새로운 기계이고 프로젝트는 당신의 API에 대한 새로운 트래픽/calls입니다.
IIT/NIT 담당자가 당신의 api/traffic에 대한 모든 요청을 처리하는 프로젝트가 하나인 경우.api에 더 요청하면 해고하고 IQ가 높은 NIT/IIT 담당자로 대체합니다. 수직 스케일링입니다.
언급URL : https://stackoverflow.com/questions/11707879/difference-between-scaling-horizontally-and-vertically-for-databases
'source' 카테고리의 다른 글
| Google 스프레드시트에서 SUMIF 올바르게 사용 (0) | 2023.10.31 |
|---|---|
| WooCommerce 구독 "잘못된 반복 배송 방법" (0) | 2023.10.31 |
| Oracle SQL - 열 값의 "이전" 상태를 반환할 수 있습니까? (0) | 2023.10.31 |
| PHP는 테마 및 플러그인에 대한 주석/헤더를 구문 분석하는 데 어떻게 사용됩니까? (0) | 2023.10.31 |
| Android Room - simple select query - 기본 스레드에서 데이터베이스에 접근할 수 없음 (0) | 2023.10.31 |