노 디자인의 주요 차이점 및 설계 원칙 SQL

Amazon Keyspace와 같은 SQL 데이터베이스 시스템은 키-값 쌍이나 문서 스토리지와 같은 데이터 관리를 위한 대체 모델을 사용하지 않습니다. 관계형 데이터베이스 관리 시스템에서 Amazon Keyspaces와 같은 SQL 데이터베이스 없음 시스템으로 전환할 때는 주요 차이점과 구체적인 설계 접근 방식을 이해하는 것이 중요합니다.

관계형 데이터 설계와 아니오 간의 차이점 SQL

관계형 데이터베이스 시스템 (RDBMS) 과 SQL 데이터베이스 없음 (No) 은 서로 다른 강점과 약점을 가지고 있습니다.

• RDBMS에서는 데이터를 유연하게 쿼리할 수 있지만 쿼리 비용이 비교적 많이 들고 트래픽이 많은 상황에서는 제대로 확장되지 않습니다 (참조). 데이터 모델링 모범 사례: 데이터 모델 설계를 위한 권장 사항

• Amazon Keyspaces와 같은 No SQL 데이터베이스에서는 제한된 수의 방법으로 데이터를 효율적으로 쿼리할 수 있지만, 그 외에는 쿼리 비용이 많이 들고 속도가 느릴 수 있습니다.

이런 차이가 두 시스템의 데이터베이스 설계를 다르게 만듭니다.

• RDBMS에서는 구현 세부 사항이나 성능에 대한 걱정 없이 유연성을 고려하여 설계합니다. 일반적으로 쿼리 최적화가 스키마 설계에 영향을 미치지 않지만, 정규화가 중요합니다.

• Amazon Keyspaces의 경우, 가장 중요하고 범용적인 쿼리를 가능한 빠르고 저렴하게 수행할 수 있도록 스키마를 설계합니다. 사용자의 데이터 구조는 사용자 비즈니스 사용 사례의 특정 요구 사항에 적합하도록 만듭니다.

디자인 SQL 없음의 두 가지 주요 개념

SQL디자인과는 다른 사고방식이 필요한 RDBMS 디자인은 없습니다. 따라서 액세스 패턴을 고려하지 않고도 정규화된 데이터 모델을 만들 수 있습니다. RDBMS 그런 후 나중에 새로운 질문과 쿼리에 대한 요구 사항이 생길 때 이를 확장할 수 있습니다. 각 데이터 유형을 고유의 테이블에 구성할 수 있습니다.

방법: No SQL Design은 다릅니다.

• 대조적으로 Amazon Keyspaces의 경우 대답해야 할 질문을 모르기 전까지는 스키마 설계를 시작할 수 없습니다. 사전에 비즈니스 문제와 애플리케이션 사용 사례를 이해해야 합니다.

• Amazon Keyspaces 애플리케이션에서는 가능한 적은 수의 테이블을 유지해야 합니다. 테이블 수가 적을수록 확장성이 향상되고 권한 관리가 줄어들며 Amazon Keyspaces 애플리케이션의 오버헤드가 감소합니다. 백업 비용도 전반적으로 낮게 유지할 수 있습니다.

접근: 디자인 없음 SQL

Amazon Keyspaces 애플리케이션 설계의 첫 번째 단계는 시스템이 충족해야 하는 특정 쿼리 패턴을 파악하는 것입니다.

특히 시작을 하기 앞서 애플리케이션 액세스 패턴에서 3가지 기본적인 속성을 이해하는 것이 중요합니다.

• 데이터 크기: 저장해야 할 데이터의 양과 한 번에 요청할 데이터의 양을 알면 가장 효과적으로 데이터를 파티션(분할)하는 방법을 결정할 수 있습니다.

• 데이터 셰이프: No SQL 데이터베이스는 쿼리가 처리될 때 (RDBMS시스템처럼) 데이터를 재구성하는 대신 데이터베이스의 모양이 쿼리될 내용과 일치하도록 데이터를 구성합니다. 이는 속도와 확장성 향상에 중요한 요소입니다.

• 데이터 속도: Amazon Keyspaces는 프로세스 쿼리에 사용할 수 있는 물리적 파티션의 수를 늘리고, 해당 파티션에 효율적으로 데이터를 배포해 조정합니다. 사전에 피크 쿼리 로드를 알면 I/O 용량을 가장 효과적으로 사용할 수 있는 데이터 파티션(분할) 방법을 결정하는 데 도움이 될 수 있습니다.

특정 쿼리 요구 사항을 파악한 후, 성능을 결정하는 일반 원칙에 따라 데이터를 구성할 수 있습니다.

• 관련 데이터를 함께 유지합니다.    20년 전의 라우팅 테이블 최적화 연구에 따르면, 응답 시간 향상에 가장 중요한 한 가지 요소는 관련 데이터를 한 장소에 유지하는 "Locality of reference"입니다. 이는 관련 데이터를 가까운 곳에 보관하면 비용 및 성능에 큰 영향을 미치는 오늘날의 No SQL 시스템에서도 마찬가지입니다. 관련 데이터 항목을 여러 테이블에 분산하는 대신 No SQL 시스템의 관련 항목을 최대한 가깝게 유지해야 합니다.

  대체로 Amazon Keyspaces 애플리케이션에서는 가능한 적은 수의 테이블을 유지해야 합니다.

  단, 볼륨이 많은 시계열 데이터가 관여된 경우나 액세스 패턴이 아주 다른 데이터 세트는 해당되지 않습니다. 통상 반전된 인덱스의 단일 테이블로 간단한 쿼리를 활성화시켜 사용자의 애플리케이션에 필요한 복잡한 계층적 데이터 구조를 생성 및 검색할 수 있습니다.

• 정렬 순서를 사용합니다.    핵심 설계가 함께 정렬할 것을 요구하는 경우, 관련 항목을 그룹으로 묶어 효율적으로 쿼리할 수 있습니다. 이는 중요한 No SQL Design 전략입니다.

• 쿼리를 분산합니다.    많은 볼륨의 쿼리를 데이터베이스의 특정 부분에 집중시키지 않는 것이 중요합니다. I/O 용량을 초과할 수 있기 때문입니다. 대신 트래픽을 가능한 여러 파티션으로 분산시켜 '핫 스팟'이 방지되도록 데이터 키를 설계해야 합니다.

이런 일반 원칙은 Amazon Keyspaces에서 데이터를 효율적으로 모델링하기 위해 사용할 수 있는 범용 설계 패턴 가운데 일부로 전환됩니다.