이 블로그 게시물 시리즈에서는 관계형 배경이 있는 경우 문서 데이터베이스로 이동할 때 고려해야 할 사항을 정리해 보려고 합니다. 특히 Microsoft SQL Server와 카우치베이스 서버.
세 부분으로 나눠서 설명해 드리겠습니다:
- 데이터 모델링
- 데이터 자체(이 블로그 게시물)
- 데이터를 사용하는 애플리케이션
목표는 애플리케이션 계획 및 디자인에 적용할 수 있는 몇 가지 일반적인 가이드라인을 제시하는 것입니다.
따라 해보고 싶으신 분들을 위해 Couchbase와 SQL Server를 나란히 시연하는 애플리케이션을 만들었습니다. GitHub에서 소스 코드 받기를 클릭하고 다음 사항을 확인하세요. 카우치베이스 서버의 개발자 미리 보기 다운로드.
JSON과 SQL의 데이터 유형
카우치베이스(및 기타 여러 문서 데이터베이스)는 데이터에 JSON 객체를 사용합니다. JSON은 사람이 읽을 수 있는 강력한 데이터 저장 형식입니다. 관계형 테이블의 데이터 유형과 비교할 때 몇 가지 유사점도 있고 몇 가지 중요한 차이점도 있습니다.
모든 JSON 데이터는 문자열, 숫자, 부울, 배열, 객체, null의 6가지 유형으로 구성됩니다. 많은 SQL Server에서 사용 가능한 데이터 유형. 일종의 '문자 그대로' 번역된 표부터 시작하여 거기서부터 작업해 보겠습니다.
SQL Server | JSON |
---|---|
nvarchar, varchar, text |
문자열 |
int, float, 10진수, double |
숫자 |
bit |
부울 |
null |
null |
XML/계층ID 필드 |
배열/객체 |
JSON의 작동 방식을 이해하는 것이 중요합니다. JSON 데이터 유형과 SQL Server 데이터 유형 간의 몇 가지 개략적인 차이점을 나열해 보았습니다. SQL 데이터 유형을 이미 이해하고 있다고 가정할 때, 다음을 수행할 수 있습니다. JSON 및 JSON 데이터 유형에 대해 자세히 알아보세요..
A 문자열 는 종종 길이로 정의됩니다. nvarchar(50) 또는 nvarchar(MAX) 를 예로 들 수 있습니다. JSON에서는 길이를 정의할 필요가 없습니다. 그냥 문자열을 사용하면 됩니다.
A 숫자 는 사용 목적에 따라 크게 달라집니다. SQL Server의 숫자 유형은 정수, 십진수 또는 부동 소수점을 저장할 수 있다는 점에서 유연합니다. 특정 정밀도가 필요하거나 매우 큰 숫자를 저장해야 하는 경우와 같이 특수한 상황에서는 숫자를 문자열로 저장하는 것이 좋습니다.
A 부울 는 참/거짓입니다. SQL Server에서는 참/거짓을 나타내는 비트와 거의 동일합니다.
JSON에서 모든 값은 다음과 같을 수 있습니다. null. SQL Server에서는 필드 단위로 설정합니다. SQL Server의 필드가 "nullable"로 설정되지 않은 경우 해당 필드가 강제 적용됩니다. JSON 문서에서는 이러한 강제 적용이 없습니다.
JSON에는 날짜 데이터 유형입니다. 날짜는 보통 UNIX 타임스탬프로 저장되지만 날짜에 문자열 표현이나 다른 형식을 사용할 수도 있습니다. N1QL 쿼리 언어에는 다양한 날짜 함수를 사용할 수 있습니다.를 사용할 수 있으므로 날짜에 N1QL을 사용하려는 경우 해당 기능을 사용하여 날짜 저장소를 적절히 계획할 수 있습니다.
SQL Server에는 지리 데이터 유형입니다. 카우치베이스에서, GeoJSON 형식이 지원됩니다..
SQL Server에는 hierarchyid, xml 등 몇 가지 다른 특수 데이터 유형이 있습니다. 일반적으로 이러한 데이터 유형은 JSON 객체에서 언롤링되거나 키로 참조됩니다( 데이터 모델링에 대한 이 블로그 시리즈의 1부). 원하는 경우 여전히 문자열 내에 XML/JSON을 저장할 수 있지만, 그렇게 하면 해당 필드에서 N1QL의 모든 기능을 사용할 수 없습니다.
데이터 마이그레이션 및 번역
조직과 팀에 따라 성공적인 마이그레이션을 위해 여러 역할의 사람들을 데려와야 할 수도 있습니다. DBA가 있는 경우, 그 DBA는 SQL Server와 마찬가지로 Couchbase를 실행하고 관리하는 방법을 알고 있어야 합니다. 개발자 또는 개발자 팀이 있는 경우, 개발자 팀을 초기 단계부터 참여시켜 진행 중인 작업을 파악하고 조율하는 데 도움을 줄 수 있도록 하는 것이 중요합니다. 문서 데이터베이스로 이동 하지 않습니다 는 더 이상 DBA나 운영팀 또는 DevOps가 관여할 필요가 없다는 것을 의미합니다. 가능하면 이러한 역할도 데이터 모델링을 수행할 때 참여하여 의견을 제공하고 진행 상황을 이해할 수 있도록 해야 합니다.
다음을 사용하여 모델을 디자인한 후 1부 데이터 모델링를 클릭하면 Couchbase로 데이터 이전을 시작할 수 있습니다.
단순한 마이그레이션(1행에서 1문서로)의 경우, 관계형 데이터베이스의 테이블, 열, 값을 반복하여 해당 문서를 출력하는 매우 간단한 프로그램을 작성할 수 있습니다. 다음과 같은 도구를 사용하면 됩니다. Dapper 는 C# 내의 모든 데이터 유형 변환을 처리하여 카우치베이스 .NET SDK.
그러나 완전히 평평한 데이터는 비교적 드물기 때문에 더 복잡한 모델의 경우 이전 관계형 모델에서 새 문서 모델로 마이그레이션하는 코드를 작성해야 할 수도 있습니다.
다음은 마이그레이션 코드(모든 종류, 특히 관계형에서 비관계형으로)를 작성할 때 염두에 두어야 할 몇 가지 사항입니다:
- 계획에 충분한 시간을 할애하세요. 마이그레이션하는 동안 모델을 다시 생각해야 할 수도 있습니다. 테스트하고 조정해야 하므로 서두르다가 실수하는 것보다 여유를 가지고 하는 것이 좋습니다. 데이터 마이그레이션은 테이블을 마이그레이션하고, 작동하는지 확인하고, 조정하고, 계속 반복하는 반복적인 사이클입니다. 이 주기를 여러 번 반복해야 할 수도 있습니다.
- 실제 데이터를 사용하여 마이그레이션을 테스트하세요. 데이터는 놀라움으로 가득할 수 있습니다. NVARCHAR 필드에는 숫자의 문자열 표현만 포함된다고 생각할 수 있지만, 단어가 포함된 비정상적인 행이 있을 수도 있습니다. 실제 데이터의 복사본을 사용하여 마이그레이션을 테스트하고 검증하세요.
- 마이그레이션을 여러 번 실행할 준비를 하세요. 실패한 마이그레이션을 정리하고 다시 시작할 계획을 세우세요. 이는 간단한
버킷에서 삭제
을 사용할 수도 있고, 좀 더 세분화되고 타겟팅된 일련의 정리가 될 수도 있습니다. 처음부터 계획을 세우면 이 작업이 더 쉬워집니다. 마이그레이션을 자동화하면 이 과정이 덜 고통스럽습니다. - ETL 또는 ELT? 추출-변환-로드 또는 추출-로드-변환. 언제 변환을 할 예정인가요? Couchbase에 데이터를 넣을 때, JSON의 유연성 덕분에 제자리에서 전송할 수 있습니다. 이후 로드 중입니다.
ETL 마이그레이션 예시
C#, 엔티티 프레임워크, Couchbase .NET SDK를 사용하여 매우 간단한 마이그레이션 콘솔 앱을 작성했습니다. 이 앱은 이전 블로그 게시물의 장바구니와 소셜 미디어 예제를 모두 마이그레이션합니다. 전체 소스 코드는 GitHub에서 사용할 수 있습니다..
이 앱은 변환을 수행할 예정이므로 ETL 접근 방식입니다. 이 접근 방식은 엔티티 프레임워크를 사용하여 관계형 테이블을 C# 클래스에 매핑한 다음 문서에 삽입합니다. 이전 블로그 게시물에서 설명한 것처럼 Couchbase의 데이터 모델은 관계형 테이블보다 C# 클래스로 더 잘 표현될 수 있으므로 이 접근 방식은 마찰이 적습니다.
C#를 사용하여 마이그레이션 프로그램을 작성할 예정이지만, 중요한 것은 특정 도구가 아니라 자동화입니다. 마이그레이션이 완료된 후에는 기본적으로 "버려지는" 코드가 될 것입니다. C# 접근 방식은 일괄 처리를 수행하지 않으며 매우 많은 양의 데이터에는 적합하지 않을 수 있으므로 다음과 같은 도구를 사용하는 것이 좋습니다. Talend 및/또는 대규모/엔터프라이즈 데이터에 대한 ELT 접근 방식입니다.
나는 쇼핑 카트 마이그레이터
클래스와 소셜 미디어 마이그레이터
클래스입니다. 이 글에서는 장바구니만 다루겠습니다. 카우치베이스 버킷
및 엔티티 프레임워크 컨텍스트
를 사용하는 것이 좋습니다. (대신 NHibernate 세션
또는 일반 DbConnection
여기를 클릭하세요).
1 2 3 4 5 6 7 8 9 10 11 |
public 클래스 쇼핑 카트 마이그레이터 { 읽기 전용 IBucket _버킷; 읽기 전용 SqlToCbContext _context; public 쇼핑 카트 마이그레이터(IBucket 버킷, SqlToCbContext 컨텍스트) { _버킷 = 버킷; _context = 컨텍스트; } } |
이러한 객체를 제자리에 배치한 후 이동
메서드를 사용하여 마이그레이션을 수행하고 정리
메서드를 사용하여 마이그레이션에서 생성된 모든 문서를 삭제할 수 있습니다.
의 경우 이동
메서드를 사용하여 엔티티 프레임워크가 조인 작업을 수행하고 모든 쇼핑 카트를 반복하도록 했습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public bool 이동() { var 카트 = _context.쇼핑 카트 .포함(x => x.항목) .ToList(); foreach (var 장바구니 in 카트) { var cartDocument = new 문서<동적> { Id = 장바구니.Id.ToString(), 콘텐츠 = MapCart(장바구니) }; var 결과 = _버킷.삽입(cartDocument); 만약 (!결과.성공) { 콘솔.WriteLine($"장바구니 {cart.Id}를 마이그레이션하는 동안 오류가 발생했습니다."); 반환 false; } 콘솔.WriteLine($"장바구니 {cart.Id}를 성공적으로 마이그레이션했습니다."); } 반환 true; } |
오류가 하나라도 발생하면 마이그레이션을 중단하도록 선택했습니다. 그렇게 하고 싶지 않을 수도 있습니다. 대신 파일에 로그인하여 오류를 일으키는 모든 레코드를 한 번에 해결하고 싶을 수 있습니다.
정리를 위해 '쇼핑카트' 유형이 있는 모든 문서를 삭제하기로 선택했습니다.
1 2 3 4 5 6 7 8 9 10 |
public void 정리() { 콘솔.WriteLine("모든 장바구니 삭제..."); var 결과 = _버킷.쿼리<동적>("DELETE FROM `sqltocb` WHERE type='ShoppingCart';"); 만약 (!결과.성공) { 콘솔.WriteLine($"{result.Exception?.Message}"); 콘솔.WriteLine($"{result.Message}"); } } |
가장 간단한 방법입니다. 더 복잡한 접근 방식은 특정 문서에 임시 '지문' 마커 필드를 설정한 다음 정리할 때 특정 지문이 있는 문서를 삭제하는 것입니다. (예 DELETE FROM sqltocb WHERE fingerprint = '999cfbc3-186e-4219-ab5d-18ad130a9dc6'
). 또는 그 반대: 나중에 분석할 수 있도록 문제가 있는 데이터를 핑거프린팅하고 나머지는 삭제하세요. 마이그레이션이 성공적으로 완료되면 이러한 임시 필드를 반드시 정리하세요.
이 작업을 직접 시도할 때는 정리 작업을 확인하기 위해 콘솔 애플리케이션을 두 번 실행하는 것이 좋습니다. 두 번째 시도에서는 중복 키가 있는 문서를 만들려고 시도하기 때문에 오류가 발생합니다.
SQL Server의 다른 기능은 어떤가요?
SQL Server의 모든 항목이 Couchbase에 직접 대응하는 것은 아닙니다. 어떤 경우에는 대응하는 항목이 아예 없을 수도 있습니다. 어떤 경우에는 대략적인 대응 기능이 있을 것입니다. 일부 기능은 향후에 제공될 예정인데, Couchbase는 빠르게 진행되고 있는 활발한 오픈 소스 개발 중이며 적절한 시기에 새로운 기능이 추가되고 있기 때문입니다.
또한 문서 데이터베이스와 NoSQL 데이터베이스는 관계형 데이터베이스보다 비즈니스 로직을 더 많이 데이터베이스 밖으로 내보내는 경우가 많다는 점을 명심하세요. Couchbase Server가 태양 아래 모든 기능을 갖추고 있다면 좋겠지만, 항상 장단점이 있습니다. 일부는 본질적으로 기술적인 문제이고 일부는 제품 설계상의 결정입니다. 관계형 스타일의 기능을 추가하기 위해 절충안을 만들 수 있지만, 그 여정의 어느 시점에서 Couchbase는 빠르고 확장 가능한 데이터베이스가 아닌 "또 다른" 관계형 데이터베이스가 되기 시작합니다. 확실히 관계형 데이터베이스와 비관계형 데이터베이스 모두에서 많은 융합이 이루어지고 있으며, 매년 많은 변화가 일어나고 있습니다.
이를 염두에 두고 시리즈의 마지막 블로그 포스팅을 기대해 주세요. 여기에서는 Couchbase 사용으로 인한 애플리케이션 코딩의 변경 사항을 다룰 예정입니다:
- SQL/N1QL
- 저장된 절차
- 서비스 계층
- 트리거
- 조회수
- 직렬화
- 보안
- 동시성
- 자동 번호
- OR/Ms 및 ODM
- 거래
요약
이 블로그 게시물에서는 Couchbase Server에서 사용할 수 있는 데이터 기능을 SQL Server와 비교하고 대조했습니다. 현재 SQL Server를 사용 중이고 프로젝트에 문서 데이터베이스를 추가하거나 새 프로젝트를 시작하려는 경우 도움을 드리고자 합니다.
다음 내용을 확인하세요. 카우치베이스 개발자 포털 에서 자세한 내용을 확인하세요.
다음 주소로 문의해 주세요. matthew.groves@couchbase.com에 질문하세요. 카우치베이스 포럼를 클릭하거나 트위터 @mgroves.
[...] 데이터 자체 [...]
에 의해 제출된 [...] 2017 년 2 월 14 일 /u/mgroves [링크] [댓글] [...]를 남겨주세요.
[...] 데이터 마이그레이션 [...]
SQL Server(및 오라클 데이터베이스)에서 카우치베이스로, 또는 그 반대로 실시간 동기화를 위한 이 유용한 커넥터를 살펴볼 것을 제안합니다 ->. https://molo17.com/gluesync-connector-couchbase/