스토리지 최적화 : JSON 대 구분 기호가있는 문자열

아래 JSON 파일의 저장 비용은 163 바이트입니다. 값은 구분 기호 문자열 ','및 '_'로 조립하는 경우 스토리지 최적화 : JSON 대 구분 기호가있는 문자열

{ 
    "locations": [ 
    { 
     "station": 6, 
     "category": 1034, 
     "type": 5 
    }, 
    { 
     "station": 3, 
     "category": 1171, 
     "type": 7 
    }, 
    ] 
}

하지만, 6_1034_5,3_1171_7는 17 바이트의 요금으로 제공됩니다.

이 접근 방식의 문제점은 무엇입니까?

감사합니다.

출처

2017-11-17 Distraction Arrestor

일반적으로 CSV로 알려진이 방법은 문서 형식이 문서화되어있는 한 JSON보다 자체 문서화가 훨씬 적기 때문에 문제가 없습니다. – Touffy

분리자를 포함 할 수있는 문자열을 저장하지 않았기 때문에 여러분의 경우에는 선을 분해하고 배열 인덱스로 작업하거나 오버 헤드를 사용하는 것이 가장 좋은 방법이라면 상관 없습니다 응용 프로그램 언어에 따라 다릅니다. 나는 websocket 통신에서 바이트를 저장하는 것과 비슷한 것을했는데 bw 사용을 사용 사례에서 25 % 정도 줄였습니다. –

이런 종류의 접근법에서 보았던 문제는 주로 유지 관리 가능성을 중심으로합니다.

구분 된 접근 방식을 사용하면 위치 항목의 속성이 서수로 식별됩니다. 숫자가 모두 있기 때문에 첫 번째 세그먼트가 방송국, 카테고리 또는 유형인지 여부는 알 수 없습니다. 그 사실을 미리 알아야합니다. 코드베이스에 익숙하지 않은 사용자도 버그를 알 수 있습니다.

지금은 모든 데이터가 정수이며, 인코딩 및 디코딩이 비교적 쉽고 구분 기호와 충돌 할 위험이 없습니다. 그러나 사용자 제공 텍스트를 추가해야하는 경우 구분 기호가 포함 된 텍스트가 표시 될 위험이 있습니다. 이 경우 분리 문자를 안정적으로 감지 할 수 있도록 이스케이프/인코딩 메커니즘을 만들어야합니다. 이것은 단순 해 보일 수도 있지만, 의심되는 것보다 어렵습니다. 나는 그것이 여러 번 잘못 행해진 것을 보았습니다.

XML 또는 JSON과 같이 잘 알려진 구조화 된 텍스트 형식을 사용하면 모든 유형의 텍스트를 처리하기위한 규칙을 완전히 개발 및 테스트하고이를 읽고 읽고 쓸 수있는 완전히 개발되고 테스트 된 라이브러리가 있다는 이점이 있습니다.

상황에 따라 스토리지 양에 대한 이러한 우려는 마이크로 최적화가 될 수 있습니다. 용량 계산 (예 : X 항목에 실제 저장 용량이 얼마나 필요한지)을 시도하고 예상되는 항목 수와 사용 가능한 예상 저장 용량을 비교해 볼 수 있습니다.

출처

2017-11-17 20:51:56

스토리지 최적화 : JSON 대 구분 기호가있는 문자열

답변

관련 문제