NoSQL과 SQL 데이터베이스에 대한 토론에서 회사가 스키마없는 새로운 NoSQL 데이터베이스를 선호하는 경우가 있습니다. 스키마를 새 버전으로 마이그레이션하는 데 문제가 있기 때문입니다. 그러나 업그레이드를 할 때 정말 큰 문제입니까? 관계형 데이터베이스는 이러한 작업에 좋지 않습니까?
MongoDB 블로그에서이 블로그 게시물을 읽었습니다. 왜 스키마가 없습니까?
NoSQL과 SQL 데이터베이스에 대한 토론에서 회사가 스키마없는 새로운 NoSQL 데이터베이스를 선호하는 경우가 있습니다. 스키마를 새 버전으로 마이그레이션하는 데 문제가 있기 때문입니다. 그러나 업그레이드를 할 때 정말 큰 문제입니까? 관계형 데이터베이스는 이러한 작업에 좋지 않습니까?
MongoDB 블로그에서이 블로그 게시물을 읽었습니다. 왜 스키마가 없습니까?
답변:
NoSql 데이터베이스에 전통적인 의미의 스키마가 없다고해서 변경 될 때 처리해야하는 논리 스키마가 없다는 의미는 아닙니다. MongoDb를 사용하는 일반적인 앱의 경우 코드에서 json 객체의 특정 필드가 특정 방식으로 동작 할 것으로 예상합니다. 동작을 변경하면 데이터베이스의 기존 데이터를 업데이트 할 수 있습니다. 이제는 전통적인 RDBMS에서는 크게 해결 된 문제였습니다. 기본 테이블을 변경해야했습니다. 그러나 이러한 새로운 NoSQL 데이터베이스를 사용하면 결정을 내릴 수 있습니다. 모든 객체를 변경하고 업데이트하기위한 스크립트를 작성합니까? 아니면 즉시 버전 간 변환 코드를 추가합니까? 그렇다면 v1 개체를 얼마나 오래 지원합니까? 영원히? v3까지?
MongoDb 블로그 게시물에 사용 된 예제는 RDBMS가 무엇이든간에 적절한 업데이트 프로세스를 보유한 경우 처리하기에 약간 단순하고 매우 쉬운 사례라고 덧붙입니다. 필드를 추가하면 거의 아프지 않습니다. 당신이 당신의 분할하기로 결정 때입니다 Name으로 필드 FirstName와 LastName그 상황이 흥미로운 얻을.
그러나 업그레이드를 할 때 정말 큰 문제입니까?
그것은 될 수 있습니다.
일부 조직은 조직이 잘 구성되어 있지 않으며 스키마 마이그레이션 작업이 매우 잘못되었습니다.
"이주 주말". 서버를 중지하십시오. 모든 데이터를 백업하고 내 보냅니다. 기존 스키마를 수정하여 새 스키마를 빌드하십시오. 데이터를 다시로드하거나 제자리에 재구성을 시도하십시오.
"연속 조정". SQL이 허용하는 범위 내에서 테이블을 변경하십시오. 수행 된 ALTER의 순서를 추적하지 않고. 이전 스키마 버전으로 돌아갈 방법이 없습니다. 필요한 경우 기존 테이블에서 새 테이블을 작성하고 새 테이블을 사용하도록 모든 애플리케이션을 조정하십시오. 그러나 양질의 QA가 부족한 경우 기존 테이블을 '경우에 따라'그대로 둡니다.
"풀 패닉". 스키마 수정을 막기 만하면됩니다. 크게 악취를 낸다. 위험이 너무 높다고 주장하십시오. 이 방향으로 모든 노력을 차단하십시오. 보다 합리적인 접근 방식을 강요받을 때까지 스키마 인질을 확보하십시오.
관계형 데이터베이스는 이러한 작업에 좋지 않습니까?
모든 스키마는 마이그레이션하기가 어렵습니다.
가장 큰 문제는 기술적 인 것이 아닙니다.
의미 론적입니다.
스키마 변경의 한 가지 주요 이유는 이전 스키마가 문제 도메인과 잘 일치하지 않기 때문입니다. 의미가 변경되었으므로 데이터베이스 (및 응용 프로그램)를 변경해야합니다. 때때로 이들은 응용 프로그램이 데이터를 처리하는 방식을 재고해야하는 중대한 변경 사항입니다.
데이터베이스의 의미를 수정하는 것은 매우 어려울 수 있습니다.
스키마 변경 대신 사람들이하는 일은 물리적 스키마를 잘못 사용하는 것입니다. 기존 필드에 잘못된 데이터를로드하기 시작합니다. "코멘트"필드는 중요한 고객 관리 정보와 "//", 실제 코멘트가 갑자기 나타나기 시작합니다. "field 1-field 2 // comment"데이터 조각이 필요하다. "실제"응용 프로그램 소프트웨어는 IT 부서에서 변경을 거부하기 때문에 변경하기 어려운 스키마를 가지고 있기 때문에 사용자는 주석 필드에서이 추가 데이터를 추출하는 스프레드 시트를 가지고 있습니다.
때에 따라 다르지.
첫째, 여러 머신에 걸쳐 매우 큰 데이터베이스가 있다면 데이터베이스 업데이트뿐만 아니라 모든 것이 고통 스러울 것입니다. (당신이 미리 계획 한 금액에 관계없이).
둘째, 데이터베이스 업데이트는 데이터베이스가 아니라 DB가 속한 더 큰 시스템에 달려 있습니다. 여기에는 데이터베이스 배포 (많은 데이터베이스 서버, 여러 데이터 센터, 마스터-슬레이브 설정 등)도 포함됩니다.
시스템 구성 요소를 구성하여 DB 스키마 변경 이벤트에 대한 일종의 '인식'을 갖도록함으로써 고통을 완화 할 수 있습니다. 이는 전체 시스템이 스키마 변경을 허용해야하며 '정상적인'방식으로 응답 할 수 있음을 의미합니다.
MySQL 스키마 업데이트를 처리하기 위해 Facebook 에서 개발 한 유틸리티를 확인할 수 있습니다 .
또한 읽기 전용 마스터 설정, 슬레이브 변경 또는 개발 사본 등의 모범 사례가 있습니다.
어쨌든 전체 백업 및 광범위한 테스트 스위트를 갖추는 것이 필수적입니다. 그래야만 자신있게 안전하게 변경할 수 있습니다.