데이터 시스템의 기초

04장: 부호화와 발전

만물은 변한다 그대로 있는 것은 아무것도 없다 - 헤라클레이토스

시스템이 계속 원활하게 실행되게 하려면 양방향 호환성을 유지해야 된다

• 하위호환성 (backwards compatibility) 새로운 코드는 예전 코드가 기록한 데이터를 읽을수 있어야 된다
• 상위호환성 (forward compatibility) 예전 코드는 새로운 코드가 기록한 데이터를 읽을수 있어야 된다

데이터 부호화 형식

프로그램은 보통 두가지 형태로 표현된 데이터를 사용
- 메모리에 자료구조
- 파일에 쓰거나 바이트 형태

마샬링 언마샬링

• 언어별 형식

  • 부호화는 보통 특정 프로그램밍 언어와 묶여 있어 다른 언어에서 데이터를 읽기는 매우 어렵다
  • 동일한 객체 유형의 데이터를 복원하려면 복호화 과정이 임의의 클래스를 인스턴스화할 수 있어야 한다
  • 테이터 버전 관리는 보통 부호화 라이브러리에서 나중에 생각하게 된다
  • 효율성도 나중에 생각하게 된다

• JSON과 XML, 이진 변형

  • 문제?
    • JSON과 XML은 텍스트 형식이라서 사람이 읽을수 있고 기계가 읽을수 있어서 인기가 많다
    • JSON과 XML은 표준 라이브러리가 있어서 다른 언어에서도 읽고 쓸수 있다
    • JSON과 XML은 텍스트 형식이라서 크기가 크고 이진 형식보다 느리다
    • JSON과 XML은 모두 스키마를 지원한다
    • CSV는 스키마가 없으므로 각 로우와 칼럼의 의미를 정의하는 작업은 애플리케이션이 해야 한다
  • 이진 부호화
    • 좀더 간편하고 파싱이 빠른 형식

• 스리프트와 프로토콜 버퍼

  • 이진 부호화 라이브러리
  • 프로토 버퍼는 구글
  • 스리프트는 페이스북
  • 필드태그와 스키마 발전
    • 스키마 발전
    • 테그번호로 상위호환 하위호환을 유지
  • 데이터타입과 스키마 발전
    • 불가능하진 않지만 값이 정확하지 않거나 짤릴 위험이 있다

• 아브로

  • 하둡의 하위호환 프로젝트
  • 스키마를 사용
  • 스키마는 JSON으로 정의
  • 쓰기 스키마 - 데이터를 쓸때 사용
  • 읽기 스키마 - 데이터를 읽을때 사용
  • 두개의 스키마가 동일하지 않아도 되며 호환가능하면 된다
  • 스키마 발전 규칙
    • 호환성을 유지하기 위해서 기본값이 있는 필드만 추가하거나 삭제할수 있다
    • 필드에서 널을 허용하려면 유니온 타입을 사용해야 된다
  • 동적 생성 스키마
  • 코드 생성과 동적 타입언어

• 스키마의 장점

  • 유효성 검사를 지원
  • 문서화
  • 코드 생성
  • 데이터베이스 스키마를 유지하면 스키마 변경이 적용되지 전에 상위 호환성과 하위 호환성을 확인할 수 있다

데이터플로 모드

• 데이터베이스를 통한 데이터플로
  • 다양한 시점에 기록된 다양한 값
    • 데이터가 코드보다 더 오래 산다
    • 마이그레이션은 값비싼 작업이다
  • 보관 저장서
    • 데이터베이스 스냅샷
• 서비스를 통한 데이터플로: REST와 RPC
  • 서비스 지향 설계
  • 마이크로서이스 설계
  • 웹서비스
    • REST
      • HTTP 프로토콜
    • SOAP
      • XML, WSDL, XSD
  • RCP 문제
    • 서비스가 다운되면 클라이언트도 다운된다
    • 서비스가 다운되면 클라이언트가 다운되지 않더라도 서비스를 사용할수 없다
  • RCP의 현재 방향
    • 서비스 디스커버리
  • 데이터 부호화와 RPC의 발전
    • 클라인언트와 서버를 독립적으로 변경하고 배포할수 있어야 된다
    • 요청은 하위호환성만 필요
    • 응답은 상위 호환성만 필요
• 메시지 전달 데이터플로
  • 비동기 메시지 전달 시스템
    • 메시지 브로커
      • 상용에서 오픈소스로 바뀜
    • 메시지 큐
  • 분산 액터 프레임워크
    • 엑터 모델
      • 엑터 모델은 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델이다
      • 스레드를 직접 처리하는 대신 액터에 캡슐화 된다
      • 보통 하나의 액터는 하나의 클라이언트나 엔티티를 나타낸다
      • 액터는 로컬 상태를 가질수 있도 비동기 메시지의 송수신으로 다른 액터와 통신한다
      • 액터는 메시지 전달을 보장하지 않는다
      • 각 액터 프로세스는 한 번에 하나의 메시지만 처리하기 때문에 스레드에 대해 걱정할 필요가 없고 각 액터는 프레임워클와 독립적으로 실행할 수 있다

정리

데이터 구조를 네트워크나 디스크 상의 바이트열로 변환하는 다양한 방법을 살펴봤다

순회식 업그레이드 하위호환성 상위 호환성

참조

---

• 데이터 중심 애플리케이션 설계