2013-07-15 1 views
2

동일한 마크 업을 2 개의 개별 문서에 저장하면 MarkLogic 6의 다른 JSON 인 XML 하나가 MarkLogic에서 자동으로 JSON과 동일한 XML로 변환하고 색인화합니다 그 점에서, 또는 둘 다 각각의 형식으로 저장되어 있습니까?MarkLogic에서 JSON으로 문서를 저장하는 경우의 성능 이점 6

MarkLogic은 관계없이 모든 문서를 XML로 저장하고 쿼리 할 때 JSON 변환을 JSON 문서에 적용합니까?

문서가 네이티브 형식으로 저장되는 경우 성능 측면에서 XML을 통해 JSON에 문서를 저장할 때 이점이 있습니까?

if($outputFormat="json") then (: result in json format :)  
    let $custom-config := 
     let $config := json:config("custom") 
     return (map:put($config, "array-element-names",(xs:QName("lp:lesson_plan"), 
                 xs:QName("lp:instructional_segment"), 
                 xs:QName("lp:strand_type"),                
                 xs:QName("lp:resource"), 
                 xs:QName("lp:level"), 
                 xs:QName("lp:discipline"), 
                 xs:QName("lp:language"), 
                 xs:QName("lp:program"), 
                 xs:QName("lp:grade"), 
                 xs:QName("res:strand_type"), 
                 xs:QName("res:resource"), 
                 xs:QName("res:ISBN"), 
                 xs:QName("res:level"), 
                 xs:QName("res:standard"), 
                 xs:QName("res:secondaryURL"), 
                 xs:QName("res:grade"), 
                 xs:QName("res:keyword"))), 
       map:put($config, "whitespace","ignore"), 
       map:put($config, "text-value","value"), 
       $config) 
    return json:transform-to-json($finalResult, $custom-config) 
else (: finalResult in xml format :)   
    $finalResult 

답변

2

디스크에서 MarkLogic은 계층 트리와 해당 인덱스를 나타내는 고도로 압축 된 C++ 데이터 구조를 저장합니다. (좋아, 그럼에도 불구하고 과도하게 단순화되었지만 그럼에도 불구하고.) 개발자로서 일반적으로 이러한 데이터 구조와 상호 작용할 수있는 두 곳이 있습니다. 1) 쿼리 및 응용 프로그램 논리 작성 2)이 내부/외부로 데이터 역 직렬화/직렬화 데이터 모델. MarkLogic은 후자의 경우 XDM (XML data model)을 사용하고 전자의 경우 XQuery, XPath 및 XSLT를 사용합니다. 우리는 여러 가지 이유 때문에이 스택을 선택했습니다. XML은 텍스트 마크 업과 데이터 구조를 모두 표현하는 데 능숙하며 XML 관련 도구는 성숙하고 널리 보급되어 있습니다.

그렇기 때문에 JSON은 AJAX의 "X"인 계층 적 데이터 구조의 대중적인 직렬화로 떠올랐다. JSON과 MarkLogic의 내부 데이터 모델 사이에는 동일한 방수 추상화가 없지만 JSON과 XML 데이터 모델간에 효율적이고 무손실로 변환 할 수있는 도구 세트를 제공합니다. 또한 REST 및 Java API를 사용하면이 변환 단계를 고려하지 않고도 JSON으로 시작된 트리 구조를 저장, 검색 및 쿼리 할 수 ​​있습니다. API는 배관에서 이것을 처리합니다.

성능면에서 보면 JSON과 XDM 표현간에 약간의 오버 헤드 변환이있을 것입니다. 그러나, 나는 그것이 대부분의 애플 리케이션에 무시할 수있을 것으로 기대합니다. XML의 진정한 이점은 데이터 작업시 XQuery, XPath 및 XSLT의 표현력에 있습니다. 오늘날 JSON 세계에는 이와 동일한 기능이 없습니다.

+0

감사합니다. XML로 문서를 저장 한 다음 XQuery를 사용하여 문서를 JSON으로 변환 할 때 상당한 성능 오버 헤드가 발생했습니다. 변환에 따라 약 2 초가 걸리던 요청이 12 초로 증가하는 경우도 있습니다. 나는 곧 코드 샘플을 제공 하겠지만, 그 동안 데이터 구조, 응답의 크기 등과 같은 변환 프로세스를 명시 적으로 느리게 할 것이 무엇입니까? –

+0

예, 여기에 일부 코드를 게시하거나 지원 부서에 문제를 제기하십시오. 귀하의 유스 케이스를 이해하는 데 매우 관심이 있습니다. –

+0

안녕하세요 저스틴, 저의 원래 게시물을 편집하여 작은 코드 스 니펫을 포함 시켰습니다. –

4

MarkLogic는 XML-기본이고 데이터베이스에 저장하기 위해 XML을 JSON 변환 할 필요 않습니다

다음은 예제 코드 조각입니다. 변환을 수행하기위한 상위 레벨 JSON 라이브러리가 있습니다. 주요 기능은 json:transform-to-jsonjson:transform-from-json이며 올바르게 구성하면 무손실 변환을 제공해야합니다.

여러분의 예제와의 가장 큰 차이점은 자신의 프로세스를 사용하여 XML로 변환 할 것인지 또는 MarkLogic의 툴킷을 사용할 것인지입니다. 자세한 내용

참조 MarkLogic의 문서 : http://docs.marklogic.com/guide/app-dev/json

2

한 각주 : (나머지 API 주위 따라서 자바 API 래퍼) 나머지 API XML로 JSON 변환을위한 외관을 제공하는 - 즉 , API는 XML 로의 변환을 수행합니다.

일반적으로 변환 된 요소에 범위 및 지형 공간 인덱스를 만드는 경우를 제외하고는 변환에 대해 생각할 필요가 없습니다.

클라이언트에서 JSON 문서를 지원해야하는 경우 외관이 편리합니다.

반면에 JSON으로 구조를 표현하는 것은 데이터베이스 작업 및 일부 제한 사항에 이점이 없습니다. 예를 들어, XML에는 표준 기반, 구운 원자 데이터 유형, 스키마 유효성 검사 및 XQuery 또는 XSLT를 사용한 서버 처리가 있습니다. 따라서 데이터 구조를 완전히 제어 할 수있는 경우 서버에 데이터를 기록 할 수 있습니다. XML.

1

MarkLogic 8 (2015 년 2 월) 현재 JSON은 XML과 마찬가지로 기본 데이터 형식입니다. 따라서 JSON에서 독점적으로 작업하려는 응용 프로그램의 변환 레이어가 필요하지 않습니다. 또한 데이터베이스의 첫 번째 언어로 JavaScript을 추가했습니다 (Google의 V8 엔진 사용). 즉, 스토어드 프로 시저, 트리거 및 데이터베이스에 가까운 데이터베이스에서 실행되는 JavaScript로 전체 HTTP 응용 프로그램까지 작성할 수 있습니다.

+0

xml 형식과 비교하여 json에서 데이터를 저장하는 장단점은 무엇입니까? 나는 데이터베이스 XML이 json보다 더 잘할 것이라고 믿는다. 아니면 둘 다 똑같이 똑같은 일을 할 것입니까? 그렇다면 JSON은 저장소가 적어지고 성능이 향상됩니다. – rxlky

+0

MarkLogic은 JSON과 XML을 모두 내부적으로 매우 최적화 된 트리로 관리합니다. 따라서'<'와'{'는 파싱과 직렬화에만 관련이있다. JSON과 XML을 결정할 때 데이터가 어떻게 사용될 것이며 개발자가 사용할 도구/기술을 생각해야합니다. 저장/성능 차이는 이것과 비교하여 무시해도 좋습니다. –

+0

흠, 내 의견에 감사드립니다. – rxlky

관련 문제