Java에서 DOM 파서는 작은 XML 파일/스트림에는 적합하지만 큰 파일에는 적합하지 않음을 이해하는 데 문제가 있습니다.데이터 구조에서 크기가 크거나 작을 수있는 것에 대한 규칙이 있습니까?
작거나 큰 XML의 정의를 지정할 수 있습니까? 파일이 얼마나 많은 KB 또는 MB인지 또는 구조가 너무 많은지 여부에 따라 달라질 수 있습니까?
물론 구현하고 성능을 테스트하여 확인할 수 있지만이 방법이 너무 오래 걸리는 것 같습니다.
당신이 질문하는 것이 옳습니다. 실제 엔지니어는 "크고"작은 것에 대해 말하지 않고 숫자를 사용합니다. 매우 넓은 강을 연결하는 것이 매우 비싼 지 여부를 묻지 않고, 1Km 너비의 강을 연결하는 데 드는 비용이 얼마나되는지 물어보십시오.
매우 자주 메모리가있는 경우 주 메모리에 적합한 항목과 그렇지 않은 항목간에 불연속이 있습니다. 따라서 사용 가능한 메모리가 2Gb이면 2Gb를 초과하는 것은 2Gb 아래에서 다른 설계 방법을 요구할 수 있습니다. 따라서 특정 디자인 (예 : DOM)이 "작은"문서에는 적합하지만 "큰"문서에는 적합하지 않다는 진술은 이러한 불연속성의 관점에서 이해 될 수 있습니다.
덧붙여 말하자면 "DOM"이라는 용어는 때때로 W3C DOM 용으로, 때로는 메모리 내 트리 표현을위한 일반적인 용어로 사용되기도합니다. DOM 자체는 org.w3.dom의 의미에서 최고의 기술 접근 방법은 아니다. JDOM2 및 XOM과 같은 타사 트리 모델은 항상 더 좋습니다. 사람들은 대안의 무지에서 DOM을 사용하거나 "표준"이기 때문에 장점이 있다고 생각하기 때문에 DOM을 사용합니다.
본질적으로 좋거나 나쁘지 않습니다. 문서의 모든 노드를 내용과 함께 메모리에로드하기 만하면 SAX가이를 피할 수 있습니다.
물론 문서가 100MB 크기이고 메모리에 있어야하는 거대한 텍스트가있는 고유 한 루트 요소가있는 경우 DOM 대신 SAX를 사용하면 메모리 소비 측면에서 많은 변화가 없을 것입니다.
하지만 수백만 개의 요소가 있고 각 요소를 하나씩 처리하려는 경우 SAX를 사용하면 메모리 사용량을 매우 낮게 유지할 수 있지만 DOM은 그렇지 않습니다.
내 XML을 크거나 작은 것으로 정의하는 범위 (존재하는 경우)를 찾는 것이 아니라. 예를 들어, 수천 개의 레코드가있는 데이터베이스의 테이블은 여전히 작은 레코드로 계산됩니다 (물론 레코드의 크기에 따라 다르지만이 테이블의 예제에서는 '긴 텍스트'및 기타 거대한 데이터 요소가 없습니다) –
범위가 없습니다. 내 가장 큰 데이터베이스는 Google의 맥락에서 볼 때 아주 작은 것입니다. 또한 오래된 전화에서 실행되는 Android 애플리케이션에는 128GB RAM이 장착 된 16 코어 시스템에서 실행되는 서버 애플리케이션과 동일한 제약 조건이 없습니다. 측정하고, 충분히 빠르며 사용 가능한 메모리를 날려 버리지 않으면 OK입니다. –
아, 내가 추측하는 요점을 봅니다. 따라서 "작음"과 "큰"은 주로 시스템에 따라 다릅니다. –
"big"= "메모리 사용량을 알기에 충분히 큰 크기". "small"= "그보다 작습니다" – immibis
아니요, 구현에 따라 구조가 포함 된 XML 파일을 생성하고이를 언 마샬링하는 데 "너무 많은 시간"이 걸리지는 않습니다. 이 파일 시스템이나이 파일 시스템 또는이 하드웨어를 사용하여이 시스템 또는 일부 시스템의 XML 구조에 대해 좋은 프로그램을 작성한 다른 사람들의 보고서를 기반으로 추측하려고합니다. – laune
DOM을 사용하여 테스트 XML을 구현하고 테스트 케이스를 실행하며 "느린"경우 SAX를 사용하여 다시 구현하는 "너무 많은 시간"을 의미했습니다. 테스트를 다시 실행하는 것은 따기보다 훨씬 더 많은 시간입니다 적절한 첫 번째. –