SQL에서 다음으로 마이그레이션 NoSQL Databases
관계형 데이터베이스에서 데이터를 마이그레이션하는 단계 NoSQL
.NET 애플리케이션에서 관계형 데이터베이스를 사용하는 것은 기존 하드웨어를 교체(확장)하지 않고 더 많은 로드를 처리할 수 없고 엄격한 데이터 모델(예: 행 및 열)을 업데이트할 수 없는 것과 같은 몇 가지 제한 사항이 있습니다. 이러한 문제에 직면하고 있다면 이미 데이터베이스를 다음으로 전환하기로 결정했을 수 있습니다. NoSQL. 그래도 확신이 서지 않는다면 다음을 읽어보십시오. NoSQL?
데이터베이스 계층을 확장할 수 있는 옵션이 없고 데이터를 이동하기로 선택한 경우를 고려하십시오. NoSQL, 어려운 마이그레이션 작업으로 인해 이러한 도약을 방해할 수 있습니다.
마이그레이션은 큰 작업이지만 단계별로 나누면 매우 체계적으로 접근할 수 있어 생활이 편해집니다. 이 백서는 6개의 논리적 단계로 마이그레이션 프로세스를 구성하는 데 도움이 됩니다.
이러한 간단한 단계를 따르면 마이그레이션 프로세스에 도움이 될 것입니다. 이 문서는 당신이 이미 기능에 대한 기본 사항을 알고 있다고 생각합니다. NosDB, .NET NoSQL 문서 데이터베이스. 그렇지 않은 경우 다음으로 이동하십시오. 웹 사이트. 아래에서는 앞서 언급한 프로세스에 대한 세부 정보를 제공합니다.
1단계: 범위 식별
첫 번째이자 가장 중요한 단계는 비즈니스 모델과 데이터베이스 스키마를 이해하는 것입니다. 또한 애플리케이션이 이 데이터에 액세스하는 방법과 데이터베이스 간 데이터 흐름을 완전히 이해해야 합니다. 이는 두 가지 주요 정보를 식별하는 데 도움이 됩니다.
- 가장 많이 액세스되는 데이터베이스 스키마 부분(읽기, 쓰기 또는 둘 다)
- 함께 그룹화되는 데이터, 즉 읽기 및 쓰기를 위해 항상 함께 액세스되는 데이터.
이 정보가 있으면 나머지 단계에서 주요 결정을 식별하는 데 도움이 됩니다. 따라서 이것은 또한 가장 중요한 단계입니다.
2 단계 : 식별 NoSQL 설치 요구 사항
비즈니스 모델과 데이터 흐름에 대한 이해가 완료되면 배포 방법에 대한 몇 가지 대략적인 결정을 내릴 수 있습니다. NoSQL 비즈니스 요구 사항에 따라 클러스터합니다. 예를 들어 현재 실행 중인 애플리케이션 수, 사용자 수 및 액세스 비율을 기록하는 것은 몇 가지 중요한 메트릭입니다. 데이터의 어떤 부분이 매우 민감한지, 즉 어떤 대가를 치르더라도 백업이 필요한지 확인하면 복제본 노드의 배포 전략을 결정하는 데 도움이 됩니다.
이후 NoSQL database 은(는) 분산 데이터베이스이므로 분산 특성을 유리하게 활용하고 비즈니스 요구 사항에 따라 배포할 수 있습니다. 확장성 외에도 얻을 수 있는 가장 큰 이점은 NosDB 서로 다른 GEO 위치에 걸쳐 샤드를 클러스터링합니다. 이를 통해 애플리케이션의 지리적 위치 근처에 샤드를 배포하고 비용이 많이 드는 네트워크 이동을 피할 수 있습니다. 그리고 앱 성능을 향상시킵니다.
여기서 우리가 하는 일은 요구 사항을 스케치하는 것뿐이라는 점을 기억하십시오. 컬렉션을 식별, 생성 및 최적화한 후 이러한 설정을 확실히 다시 방문할 것입니다.
3단계: JSON 컬렉션 변환 및 최적화
이제 배포 클러스터의 기본 요구 사항이 있으므로 '스케치'가 최적화 전략을 지시합니다.
테이블을 컬렉션으로 변환
먼저 관계형 데이터베이스의 테이블을 컬렉션으로 변환하고 열을 특성으로 변환하기만 하면 됩니다. 이것이 정규화 관계형 데이터베이스에서 오는 데이터.
문서를 포함하여 데이터 비정규화
다음으로 비정규화 분리된 테이블, 즉 다른 테이블과 연관되지 않는 한 아무 의미가 없는 테이블입니다. 관계적 측면에서 격리된 테이블은 접합 테이블. 예를 들어, 주문내역 Northwind 데이터베이스에서 Order와 관련하여 언급될 때 더 의미가 있습니다. 따라서 올바른 선택은 OrderDetails를 주문번호 문서.
관계 변환
이제 남은 것은 각각의 문서가 포함된 컬렉션입니다. 접합 테이블 그들 안에 내장. 그러나 다대다, 일대다 및 기타 관계는 어떻습니까? 여기에서 자연적으로 그룹화된 데이터 및 함께 액세스된 데이터에 대한 지식이 유용합니다.
. NorthWind 데이터베이스 마이그레이션 예Walk Through California 프로그램, 빠른 와 주문번호 테이블은 관련되어 있지만 항상 함께 액세스되는 것은 아닙니다. 따라서 삽입하는 것은 의미가 없습니다. 고객 개체 내부 주문 문서. 또한, 고객 문서 불필요하게 데이터를 복제하므로 가능한 한 피하고 싶습니다. 그렇지 않으면 고객 프로필을 한 번만 변경하면 응용 프로그램이 모든 프로필을 변경해야 합니다. 주문.고객 서류. 불필요한 계산 비용.
반면 카테고리는 제품을 가져올 때마다 애플리케이션에 항상 필요합니다. 따라서 이것은 임베딩을 위한 좋은 후보입니다. 또한 JSON 문서의 장점은 객체를 풍부하게 하기 위해 배열과 JSON 문서 배열도 지원할 수 있다는 점입니다.
하이브리드 모델 - 최고의 정규화 및 비정규화
이후 NoSQL 스키마는 애플리케이션의 데이터 흐름을 기반으로 합니다. 컬렉션에 포함 및 비포함 모두를 유지하는 이점이 있는 경우 하이브리드 모델을 채택합니다.
이전 페이지에서 참조한 샘플 Northwind 데이터베이스에서 이 현상은 다음에서 볼 수 있습니다. 범주 와 프로덕트 테이블. 시나리오는 프로덕트 액세스되면 응용 프로그램은 자신의 범주. 그러나 응용 프로그램도 알아내야 합니다. 제품 by 범주.
경우 범주 별도의 테이블에 보관되면 단일 제품 가져오기는 두 개의 데이터베이스 호출을 의미하며 하나는 프로덕트 다른 하나는 각각을 가져옵니다. 범주, 따라서 추가 네트워크 비용. 경우에만 범주 포함된 다음 모든 범주를 찾으려면 다음 SQL 문을 실행해야 합니다.
SELECT DISTINCT product.Category.CategoryName FROM Products;간단한 SQL 쿼리이지만 매우 효율적이지 않습니까? 따라서 답은 유지하는 것입니다. 범주 별도의 컬렉션에 문서화하지만 제품에 반드시 필요한 부분만 포함합니다. 이것은 하이브리드 모델.
예를 들어, 애플리케이션이 제품 문서를 가져오는 시나리오에서는 범주 이름과 범주 설명. 따라서 내장하는 것은 완전히 불필요합니다. 범주 모든 제품 문서의 그림. 실제로 복제하면 불필요한 저장 공간이 많이 필요하고 문서 크기가 커져 비용이 많이 드는 네트워크 이동이 발생합니다.
이것은 하이브리드 모델의 완벽한 사용 사례이므로 컬렉션은 다음과 같이 형성됩니다.
"Product" {
"name": "string",
"category": {
"name": "string",
"description": "string",
}
}및 저장 범주 별도로:
"Category" {
"name": "string",
"description": "string",
"picture": byte[]
}
}배포 전략 결정
다음으로 결정해야 할 것은 컬렉션의 가능한 배포 전략입니다. 설정 요구 사항의 초기 스케치는 여기에 직접적인 영향을 미칩니다.
배포 전략에는 세 가지 옵션이 있습니다.
- 범위 기반 분포: 이 전략을 사용하면 각 샤드에 지정된 범위에 따라 데이터가 노드 간에 분산되는 방식을 정의할 수 있습니다. 예를 들어, NosDB 클러스터는 뉴욕에 있는 하나의 샤드와 런던에 있는 다른 샤드와 함께 GEO로 분산되어 있으므로 뉴욕에 있는 애플리케이션에서 생성되고 필요한 데이터는 동일한 GEO 위치에 있어야 하므로 네트워크 비용이 최적화됩니다. 이 전략은 주로 GEO 분산 클러스터에서 사용되지만 다른 사용 사례도 있습니다.
- 해시 기반 배포: 해싱을 사용하면 샤드 간에 데이터를 균일하게 분산할 수 있으므로 로드도 균일하게 분산됩니다. 이 전략은 GEO 분산 클러스터에 대한 최선의 선택은 아니지만 NosDB 단일 데이터 센터 내의 클러스터.
- 단일 샤드 컬렉션(배포 비활성화): 이렇게 하면 컬렉션에 대한 배포가 완전히 비활성화됩니다. 데이터 세트가 작거나 특히 단일 머신에 있으려면 이 옵션을 사용하십시오.
배포 전략을 결정한 후 컬렉션 최적화 및 배포 전략을 다시 방문하여 추가로 최적화할 수 있는지 확인할 수 있습니다. 일반적으로 몇 번의 반복으로 결정을 내리기에 충분합니다.
4단계: 데이터 마이그레이션
마지막으로 몇 가지 집중적인 브레인스토밍 후에 상대적으로 쉬운 부분이 나옵니다. 즉, 관계형 데이터베이스에서 NoSQL database.
먼저 컬렉션과 JSON 문서를 나타내는 .NET 개체를 만듭니다. 예! .NET API가 자동으로 .NET 개체를 JSON 문서로 변환하므로 데이터를 삽입하는 데 ORM이 필요하지 않습니다. (참고로, 함께 제공되는 ADO.NET 통합을 사용하도록 선택할 수도 있습니다. NosDB).
다음으로 관계형 데이터베이스에 액세스하고 이러한 .NET 개체를 채우고 NoSQL database. 에서 제공하는 CLR 트리거 및 CLR UDF를 사용할 수도 있습니다. NosDB 마이그레이션을 지원합니다.
데이터를 마이그레이션했으면 이제 애플리케이션을 마이그레이션하여 컬렉션 및 문서 측면에서 데이터를 채택할 때입니다. 없이 NosDB ADO.NET 또는 CLR 트리거 및 UDF를 사용할 수 있는 옵션이 없지만 API는 계속 사용할 수 있습니다.
5단계: 애플리케이션 마이그레이션
작업 중인 .NET 애플리케이션을 다음으로 마이그레이션하는 방법에는 여러 가지가 있습니다. NosDB. NosDB SELECT, INSERT, UPDATE 및 DELETE와 같은 SQL 작업을 지원합니다. SQL 작업을 사용하면 응용 프로그램을 마이그레이션하기 위한 학습 곡선이 크게 줄어듭니다. 즉, 익숙한 구문을 사용할 수 있습니다. 다음에서 데이터베이스 클러스터를 관리할 수도 있습니다. NosDB SQL을 사용하여.
NosDB 다음과 같이 데이터베이스에 액세스할 수 있는 여러 가지 방법으로 SQL을 지원합니다.
- .NET API
- ADO.NET
- 링크
- 자바 API
- REST API
또한 서버 측 API를 사용하여 MapReduce와 같은 프레임워크를 사용하여 배포 기능을 활용하여 애플리케이션 성능을 개선할 수 있습니다. 사용하지 않는 경우 NosDB API를 직접 호출하는 옵션만 있습니다. SQL 및 ADO.NET은 NosDB.
6단계: 마이그레이션 검증
마이그레이션 후 유효성 검사는 전체 프로세스의 마지막 단계입니다. 모든 테스트를 확인하고 마이그레이션된 데이터와 애플리케이션의 유효성을 검사합니다. 이 단계는 전적으로 귀하와 귀하의 비즈니스 프로세스에 달려 있습니다. 새롭게 편입된 벤치 NoSQL database. 현재 클러스터 구성의 한계를 확인하고(원할 때마다 확장할 수 있음) 다음과 같은 올바른 도구를 갖추십시오. NosDB Management Studio는 단일 위치에서 전체 클러스터를 관리하고 모니터링합니다.
그게 다야! 이 단계를 따르면 관계형 데이터베이스에서 다음으로의 마이그레이션을 구성할 수 있습니다. NoSQL database 논리적인 6단계 프로세스에서.