데이터 집약적 애플리케이션 설계

4장. 인코딩과 진화

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

모든 것이 변하고 멈춰 있는 것은 없습니다.

플라톤이 《크라틸로스》에서 인용한 에페소스의 헤라클레이토스(기원전 360년)

애플리케이션은 시간이 지남에 따라 필연적으로 변화합니다. 새로운 제품이 출시되거나, 사용자 요구사항이 더 잘 이해되거나, 비즈니스 환경이 변화함에 따라 기능이 추가되거나 수정됩니다.1장에서는 변화에 쉽게 적응할 수 있는 시스템을 구축하는 것을 목표로 해야 한다는 진화 가능성의 개념을 소개했습니다( "진화 가능성: 변화를 쉽게 만들기" 참조).

대부분의 경우 애플리케이션의 기능을 변경하려면 저장하는 데이터도 변경해야 하는데, 새로운 필드나 레코드 유형을 캡처해야 하거나 기존 데이터를 새로운 방식으로 표시해야 할 수도 있습니다.

2장에서 설명한 데이터 모델은 이러한 변화에 대처하는 방식이 다릅니다. 관계형 데이터베이스는 일반적으로 데이터베이스의 모든 데이터가 하나의 스키마를 준수한다고 가정합니다. 스키마 마이그레이션(예: ALTER 문)을 통해 스키마를 변경할 수는 있지만 어느 한 시점에 정확히 하나의 스키마가 적용된다고 가정합니다. 이와 대조적으로, 스키마 온 리드("스키멀리스") 데이터베이스는 스키마를 적용하지 않으므로 데이터베이스에는 서로 다른 시기에 작성된 이전 데이터 형식과 최신 데이터 형식이 혼합되어 있을 수 있습니다( "문서 모델의 스키마 유연성" 참조).

데이터 형식이나 스키마가 변경되면 애플리케이션 코드도 그에 따라 변경되어야 하는 경우가 많습니다(예: 레코드에 새 필드를 추가하면 애플리케이션 코드가 해당 필드를 읽고 쓰기 시작). 그러나 대규모 애플리케이션에서는 코드 변경이 즉각적으로 이루어지지 않는 경우가 많습니다:

• 서버 측 애플리케이션의 경우 롤링 업그레이드( 단계적 롤아웃이라고도 함)를 수행하여 한 번에 몇 개의 노드에 새 버전을 배포하고 새 버전이 원활하게 실행되는지 확인한 다음 모든 노드에서 점진적으로 작업할 수 있습니다. 이렇게 하면 서비스 중단 시간 없이 새 버전을 배포할 수 있으므로 더 자주 배포하고 발전성을 향상시킬 수 있습니다.

• 클라이언트 측 애플리케이션을 사용하면 업데이트를 한동안 설치하지 않을 수도 있는 사용자의 마음대로 할 수 있습니다.

즉, 이전 버전과 새 버전의 코드, 이전 데이터 형식과 새 데이터 형식이 동시에 시스템에 공존할 수 있습니다. 시스템이 계속 원활하게 작동하려면 양방향으로 호환성을 유지해야 합니다:

이전 버전과의 호환성

최신 코드는 이전 코드에서 작성한 데이터를 읽을 수 있습니다.

이전 버전과의 호환성

이전 코드는 최신 코드에서 작성한 데이터를 읽을 수 있습니다.

이전 버전과의 호환성은 ...