데이터베이스 확장성

Database scalability
참고 항목: 확장성

데이터베이스 확장성은 리소스를 추가/제거하여 변화하는 요구를 처리할 수 있는 데이터베이스의 능력이다.데이터베이스는 대처하기 위해 수많은 기법을 채택했다.[1]

역사

데이터베이스 확장성의 초기 이력은 더 작은 컴퓨터에서 서비스를 제공하는 것이었습니다.IMS와 같은 최초의 데이터베이스 관리 시스템은 메인프레임 컴퓨터에서 실행되었다.잉그레스, 인포믹스, 사이베이스, RDB, 오라클 등 2세대가 미니콤퍼터에 등장했다.dBase, 오라클(again) 등 3세대는 개인용 컴퓨터에서 달렸다.[2]

같은 기간 동안 더 많은 데이터와 더 까다로운 워크로드를 처리하는 데 관심이 쏠렸다.1980년대 후반에 있었던 한 가지 주요 소프트웨어 혁신은 업데이트 잠금 세분성을 테이블과 디스크 블록에서 개별 행으로 줄이는 것이었습니다.이는 중요한 확장성 병목 현상을 제거했는데, 이는 공동 잠금 장치가 트랜잭션에 직접 관여하지 않았음에도 불구하고 행에 대한 접근을 지연시킬 수 있기 때문이다.초기 시스템은 자원 증가에 전혀 무감각했다.[3]

일단 소프트웨어 제한이 해결되자, 관심은 하드웨어로 쏠렸다.혁신은 많은 분야에서 일어났다.첫번째는 멀티프로세서 컴퓨터를 지원하는 것이었다.여기에는 여러 프로세서가 서로 차단하지 않고 동시에 데이터베이스 요청을 처리할 수 있도록 하는 것이 포함되었다.이것은 멀티코어 프로세서에 대한 지원으로 발전했다.

훨씬 더 중요한 변화는 분산 트랜잭션이 2단계 커밋 프로토콜을 사용하여 별도의 컴퓨터에 저장된 데이터에 영향을 미치고, 공유 없음 아키텍처를 구축하는 것이었습니다.[4]

이후에도 Oracle은 모든 것을 공유하는 아키텍처를 도입하여 다중 서버 클러스터에 완전한 기능을 제공하였다.[5]

또 다른 혁신은 다수의 컴퓨터(데이터베이스 복제)에 테이블의 복사본을 저장하는 것인데, 이는 가용성과 특히 쿼리/분석을 위한 확장성을 향상시켰으며, 1차 시스템이 그 용량에 도달하면 요청이 사본으로 라우팅될 수 있다.[6]

21세기 초에 NoSQL 시스템은 일부 워크로드에 대해 관계형 데이터베이스보다 더 많은 인기를 얻었다.동기 부여에는 문서 및 기타 "비관계" 데이터 유형에 대한 더 큰 확장성과 지원이 포함되었다.종종 희생되는 것은 모든 노드가 결국 최신 데이터를 반환할 수 있도록 보장하는 궁극적인 일관성을 위해 항상 완벽한 일관성을 보장하는 엄격한 AIDS 일관성 프로토콜이었다.일부는 시스템이 충분히 많은 요청을 처리할 수 있는 한 거래가 때때로 손실되는 것을 허용하기도 했다.[7]가장 두드러진 초기 시스템은 2004년에 개발된 구글의 빅테이블/맵리듀스였다.다중 행 트랜잭션 및 결합과 같은 기능의 비용으로 여러 서버 팜에 걸쳐 거의 선형적인 확장성을 달성했다.[8]

2007년에는 최초의 NewSQL 시스템인 H-Store가 개발되었다.NewSQL 시스템은 NoSQL 확장성을 AID 트랜잭션 및 SQL 인터페이스와 결합하려고 시도한다.[9]

치수

데이터베이스 확장성에는 데이터 양, 요청 볼륨, 요청 크기 등 3가지 기본 차원이 있다.요청은 다양한 크기로 제공된다. 트랜잭션은 일반적으로 소량의 데이터에 영향을 미치지만 초당 수천 개에 근접할 수 있다. 분석 쿼리는 일반적으로 더 적지만 더 많은 데이터에 액세스할 수 있다.관련 개념은 탄력성이며, 변화하는 워크로드를 충족하기 위해 용량을 투명하게 추가하고 빼는 시스템의 기능이다.[10]

수직.

수직적 데이터베이스 확장이란 데이터베이스 시스템이 일반적으로 큰 메모리와 방대한 스토리지 용량을 가진 멀티프로세서를 포함하여 최대적으로 구성된 시스템을 완전히 이용할 수 있음을 의미한다.이러한 시스템은 상대적으로 관리가 간단하지만 가용성이 감소할 수 있다.그러나 어떤 단일 컴퓨터라도 최대 구성을 가지고 있다.워크로드가 그 한계를 넘어 확장되는 경우, 다른 대규모 시스템으로 마이그레이션하거나 수평적 확장성을 달성하기 위해 시스템을 재설계할 수 있다.[10]

수평

수평적 데이터베이스 확장에는 단일 워크로드에서 작업할 서버를 추가하는 작업이 포함된다.수평으로 확장 가능한 대부분의 시스템에는 기능이 손상된다.애플리케이션이 더 많은 기능을 필요로 하는 경우 수직 확장 시스템으로 마이그레이션하는 것이 더 바람직할 수 있다.[10]

기술

하드웨어

데이터베이스는 스마트워치에서 슈퍼컴퓨터, 투명하게 재구성 가능한 여러 서버 팜에 이르기까지 다양한 용량으로 개별 하드웨어에서 실행된다.[2]데이터베이스는 또한 64비트 마이크로프로세서, 멀티 코어 CPU 및 대형 SMP 멀티프로세서에서 실행되도록 수직 확장되었다.

경합

하드웨어 구성을 완전히 이용하려면 전체 데이터베이스 잠금에서 전체 테이블, 디스크 블록, 개별 테이블 행에 이르는 다양한 잠금 기술이 필요하다.적절한 잠금 세분성은 워크로드에 따라 달라진다.잠긴 오브젝트가 작을수록, 하드웨어가 공회전하는 동안 데이터베이스 요청이 서로 차단될 가능성은 줄어든다.일반적으로 행 잠금장치는 더 많은 수의 잠금을 관리하기 위한 오버헤드 처리 비용으로 대용량 트랜잭션 처리 애플리케이션을 지원하기 위해 필요하다.[3]

또한 일부 시스템은 쿼리가 검사 중인 데이터를 잠궈 업데이트가 수정되지 않도록 하여 쿼리가 데이터베이스 보기를 시간적으로 일관되게 표시하도록 보장하고, 작업을 지연시킨다.또는 일부 데이터베이스는 일관된 쿼리 결과를 제공하는 동시에 읽기 잠금을 방지(차단)하기 위해 다중 버전 읽기 일관성을 사용한다.[11]

많은 요청이 동시에 동일한 데이터에 액세스하려고 할 때 일부 시스템에서 또 다른 잠재적 병목 현상이 발생할 수 있다.예를 들어 OLTP 시스템에서는 많은 트랜잭션이 동일한 테이블에 동시에 데이터를 삽입하려고 시도할 수 있다.공유되지 않는 시스템에서는, 어느 순간에도, 그러한 모든 삽입물은 테이블의 파티션(샤드)을 관리하는 단일 서버에 의해 처리되어, 아마도 그것을 압도하는 반면, 시스템의 나머지 부분은 거의 할 일이 없다.그러한 많은 테이블은 새로 삽입된 각 행에 대해 증가하는 기본 키로 시퀀스 번호를 사용한다.또한 해당 키에 대한 인덱스는 삽입물을 처리할 때 경합(과열)을 경험할 수 있다.이를 위한 한 가지 해결책은 기본 키의 숫자를 반대로 하는 것이다.이렇게 하면 삽입물이 테이블과 키 둘 다로 데이터베이스의 여러 부분에 걸쳐 퍼진다.[12]

파티셔닝

기본 기법은 키 필드의 값 범위를 기준으로 큰 테이블을 여러 개의 파티션으로 분할하는 것이다.예를 들어, 각 연도의 데이터는 별도의 디스크 드라이브 또는 별도의 컴퓨터에 보관될 수 있다.분할은 단일 테이블의 크기에 대한 제한을 없앤다.

복제

복제된 데이터베이스는 여러 대의 컴퓨터에 있는 테이블이나 데이터베이스의 복사본을 유지 관리한다.이 스케일링 기법은 특히 거래 내역이나 세금표와 같이 드물거나 업데이트되지 않은 데이터에 편리하다.[6]

클러스터된 시스템

단일 컴퓨터의 한계를 넘어 확장하기 위해 다양한 접근 방식이 사용된다.HP Enterprise의 NonStop SQL은 데이터나 메모리가 서버 경계에 걸쳐 공유되지 않는 공유 무(無) 아키텍처를 사용한다.코디네이터는 데이터베이스 요청을 올바른 서버로 라우트한다.이 아키텍처는 거의 선형에 가까운 확장성을 제공한다.

널리 지원되는 X/Open XA 표준은 글로벌 트랜잭션 모니터를 채택하여 반자율 XA 인증 트랜잭션 자원 간의 분산 트랜잭션을 조정한다.

오라클 RAC는 "공유된 모든 것" 아키텍처를 기반으로 확장성을 달성하기 위해 다른 모델을 사용한다.이 접근방식은 여러 컴퓨터가 클러스터의 모든 디스크에 액세스할 수 있도록 하는 공유 디스크 접근방식을 통합한다.NAS(Network Attached Storage)와 SAN(Storage Area Network)이 로컬 영역 네트워크와 파이버 채널 기술과 결합되어 이러한 구성이 가능하다.이 접근방식은 서버의 메모리에 캐시된 데이터를 디스크에서 데이터를 다시 읽을 필요 없이 다른 서버가 사용할 수 있도록 하는 "공유된" 논리적 캐시를 포함한다.각 페이지는 요청을 만족시키기 위해 서버에서 서버로 이동한다.일반적으로 업데이트는 매우 빠르게 이루어지므로 "대중" 페이지는 지연 없이 여러 트랜잭션에 의해 업데이트될 수 있다.이 접근방식은 최대 100대의 서버를 포함하는 클러스터를 지원한다고 주장한다.[13]

일부 연구자들은 관계형 데이터베이스 관리 시스템의 본질적인 한계에 의문을 제기한다.예를 들어 GigaSpaces는 성능과 확장성을 달성하기 위해 공간 기반 아키텍처가 필요하다고 주장한다.Base One은 주류 관계형 데이터베이스 기술 내에서 최고의 확장성을 입증한다.[14]

참고 항목

참조

  1. ^ Bondi, André B. (2000). Characteristics of scalability and their impact on performance. Proceedings of the second international workshop on Software and performance – WOSP '00. p. 195. doi:10.1145/350391.350432. ISBN 158113195X.
  2. ^ a b Chopra, Rajiv (2010). Database Management System (DBMS)A Practical Approach. S. Chand Publishing. p. 33. ISBN 9788121932455.
  3. ^ a b "Row locks vs table locks in Oracle". www.dba-oracle.com. Retrieved 2019-04-11.
  4. ^ "The Advantages of a Shared Nothing Architecture for Truly Non-Disruptive Upgrades". solidfire.com. 2014-09-17. Archived from the original on 2015-04-24. Retrieved 2015-04-21.
  5. ^ "Real Application Clusters Administration and Deployment Guide". docs.oracle.com. Retrieved 2019-04-11.
  6. ^ a b "A Primer on Database Replication". www.brianstorti.com. Retrieved 2019-04-11.
  7. ^ Martin Zapletal (2015-06-11). "Large volume data analysis on the Typesafe Reactive Platform". {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  8. ^ "Overview of Cloud Bigtable Cloud Bigtable Documentation". Google Cloud. Retrieved 2019-04-11.
  9. ^ Aslett, Matthew (2011). "How Will The Database Incumbents Respond To NoSQL And NewSQL?" (PDF). 451 Group (published 2011-04-04). Retrieved 2012-07-06.
  10. ^ a b c Branson, Tony (2016-12-06). "Two main approaches to database scalability". Infosecurity Magazine. Retrieved 2019-04-11.
  11. ^ "Clojure - Refs and Transactions". clojure.org. Retrieved 2019-04-12.
  12. ^ "Introduction To Reverse Key Indexes: Part I". Richard Foote's Oracle Blog. 2008-01-14. Retrieved 2019-04-13.
  13. ^ "clustering" (PDF). Oracle.com. Retrieved 2012-11-07.
  14. ^ Base One (2007). "Database Scalability - Dispelling myths about the limits of database-centric architecture". Retrieved May 23, 2007.

외부 링크