XML을 데이터 스토리지로 사용 [닫기]

XML 형식과 다음 인용문에 대해 생각하고있었습니다.

“XML은 데이터베이스가 아닙니다. 데이터베이스가되어서는 안됩니다. 결코 데이터베이스가 될 수 없습니다. 관계형 데이터베이스는 20 년 이상의 구현 경험을 보유한 입증 된 기술입니다. 견고하고 안정적이며 유용한 제품입니다. 그들은 떠나지 않을 것입니다. XML은 다른 데이터베이스간에 또는 데이터베이스와 다른 프로그램간에 데이터를 이동하는 데 매우 유용한 기술입니다. 그러나 데이터베이스 자체는 아닙니다. 하나처럼 사용하지 마십시오. "- 효과적인 XML : 50 구체적인 방법을 귀하의 XML을 개선하기 로 엘리오트 러스티 해롤드 (230 페이지, 제 4 부, 항목 (41), 두 번째 단락)

이것은 XML이 데이터 저장 용으로 사용되어서는 안되며 프로그램 간 상호 운용성에만 사용되어야한다고 강조하는 것 같습니다.

개인적으로, 나는 동의하지 않으며 app.config프로그램 설정을 저장하는 데 사용되는 .NET 파일은 XML 파일의 데이터 저장 예입니다. 그러나 구성이 아닌 데이터베이스의 경우 XML을 사용해서는 안됩니다.

내 지점을 개발하기 위해, 나는 두 가지 예를 사용합니다 :
한 레벨에있는 모든 즉 필드의 수는 전혀 어린이 한 고객이 관련되어있는 분야와 고객에 대한 A) 데이터를
응용 프로그램의 구성에 대해 데이터) B 경우 중첩 된 필드 그리고 속성은 많은 의미가 있습니다

그래서 내 질문은, 이것이 여전히 유효한 진술이며 이제 XML을 사용하여 데이터를 저장할 수 있습니까?

편집 : 나는 그 인용문의 저자에게 입력 / 추가 컨텍스트를 요청하는 이메일을 보냈습니다.

이 인용문은 일반적으로 XML을 스토리지 형식으로 사용하는 것이 아니라 (요구 사항에 따라 괜찮음) 데이터베이스 유형 스토리지에 사용됩니다.

사람들은 데이터베이스에 저장, 그들은 일반적으로 평균 스토리지 시스템에 대해 말할 때 거대한 종종 기가 바이트 나 테라 바이트 범위에서 데이터의 양. 데이터베이스는 데이터베이스를 저장하는 서버에서 사용 가능한 RAM의 양보다 훨씬 클 수 있습니다. 아무도 데이터베이스에 모든 데이터를 한 번에 필요로하지 않기 때문에 데이터베이스는 데이터의 선택적 하위 집합을 신속하게 검색 할 수 있도록 최적화되어야합니다. 이것이 바로 SELECT명령문, 관계형 데이터베이스 및 NoSQL 솔루션은 내부 스토리지 형식을 빠르게 최적화하는 것입니다. 그러한 부분 집합의 검색.

그러나 XML은 이러한 요구 사항에 실제로 맞지 않습니다. 중첩 된 태그 구조로 인해 전체 문서 트리를 걸 치지 않고 특정 값이 파일의 바이트 오프셋 측면에서 파일에 저장되는 위치를 적어도 일치시킬 때까지 확인할 수 없습니다. 관계형 데이터베이스에는 인덱스가 있으며 기본 이진 검색 구현을 사용하더라도 인덱스에서 값을 찾는 것은 단일 O (log n) 조회이며 실제 값을 얻는 것은 파일 검색에 지나지 않습니다 (예 : fseek(data_file_handle, row_index * row_size)), O (1)입니다. XML 파일에서 가장 효율적인 방법은 문서에 대해 SAX 파서를 실행하여 실제 데이터에 도달하기 전에 엄청나게 많은 읽기와 검색을 수행하는 것입니다. 인덱스를 사용하지 않는 한 O (n)보다 더 나은 결과를 얻을 수는 없지만 삽입 할 때마다 전체 인덱스를 다시 작성해야합니다 (아래 참조).

삽입이 더 나쁩니다. 관계형 데이터베이스는 행 순서를 보장하지 않으므로 새 행을 추가하거나 '삭제됨'으로 표시된 행을 덮어 쓸 수 있습니다. DB는 단지 쓰기 가능한 위치의 풀을 유지할 수 있습니다. 풀이 비어 있지 않으면 풀에서 항목을 가져 오는 것은 O (1)입니다. 최악의 경우, 풀이 비어 있고 새 페이지를 작성해야하지만이 역시 O (1)입니다. 반대로 XML 기반 데이터베이스는 공간을 확보하기 위해 삽입 지점 이후의 모든 항목을 이동해야합니다. 이것은 O (n)입니다. 인덱스가 활성화되면 상황이 더욱 흥미로워집니다. 일반적인 관계형 데이터베이스 인덱스는 비교적 낮은 복잡도로 업데이트 될 수 있습니다 (O (log n)). 그러나 XML 파일을 색인화하려면 삽입 할 때마다 문서의 모든 값에 대한 디스크상의 위치가 변경 될 수 있으므로전체 인덱스를 다시 작성하십시오 . 예를 들어 요소의 텍스트 내용을 업데이트하면 크기가 변경 될 수 있기 때문에 업데이트가 필요합니다. 이는 연속적인 XML이 바뀌어야한다는 것을 의미합니다. 색인화되지 않은 열을 업데이트하는 경우 관계형 데이터베이스는 색인을 전혀 만질 필요가 없습니다. XML 데이터베이스는 업데이트 된 XML 노드의 크기를 변경하는 각 업데이트마다 전체 인덱스를 다시 작성해야합니다.

이것들은 가장 중요한 단점이지만 더 있습니다. XML은 매우 장황하며 안전성을 추가하기 때문에 서버 간 통신에 좋습니다. (수신 서버는 XML에 대해 모든 종류의 무결성 검사를 수행 할 수 있으며, 전송에 문제가 있으면 문서의 유효성을 검사 할 수 없습니다. ). 그러나 대용량 스토리지의 경우 이것은 죽이는 것입니다. XML 데이터에 대해 100 % 이상의 오버 헤드가있는 것은 드문 일이 아니며 (SOAP 메시지와 같은 경우 1000 % 범위에서 오버 헤드 비율을 보는 것은 드문 일이 아닙니다) 전형적인 관계형 DB 스토리지 스키마에는 테이블 메타 데이터에 대한 일정한 오버 헤드와 행당 작은 비트 만 있습니다. 관계형 데이터베이스의 오버 헤드는 대부분 고정 된 열 너비에서 비롯됩니다. 테라 바이트 단위의 데이터가있는 경우 여러 가지 이유로 500 %의 오버 헤드가 허용되지 않습니다.

XML은 데이터 저장 공간이 넓습니다. 첫째, 매우 장황합니다. XML 파일에 저장된 데이터는 합리적인 데이터베이스 시스템에 저장된 동일한 데이터보다 훨씬 더 많은 디스크 공간을 차지합니다. XML 레코드에서 특정 필드의 이름은 데이터의 문자열 표현과 함께 두 번 저장됩니다. 예를 들어, "foobar"라는 필드에 단일 정수를 저장하려면이 19 바이트 문자열이됩니다.

<foobar>42</foobar>

반면에 실제 데이터베이스는이를 4 바이트의 단일 정수 값으로 저장합니다. 데이터베이스가 작 으면 큰 의미는 없지만 10,000 개의 레코드가 있으면 문제가됩니다.

둘째, 파일을 읽을 때마다 텍스트에서 XML을 구문 분석해야합니다. 위의 필드에서 실제 데이터베이스는 단순히 "foobar"필드가 저장된 것을 알고있는 오프셋에서 이진 데이터를 메모리로 읽어들입니다. 파일이 XML로 저장된 경우 "foobar"필드를 읽어야합니다. 필드가 무엇인지 확인한 다음 문자열 "42"를 구문 분석하고 이진 42로 변환하십시오.

따라서 XML 사용에 대한 성능 불이익이 엄청납니다. XML의 장점은 사람이 읽을 수 있고 완전히 별개의 시스템간에 데이터를 쉽게 전송할 수 있다는 것입니다. 이러한 장점 중 어느 것도 로컬 데이터베이스에 적용되지 않습니다.

한 가지 예외는 구성 파일입니다. 구성 파일은 일반적으로 작으며 일반적으로 사람이 편집 할 수 있어야합니다.

XML 데이터베이스는 합리적인 SQL 시스템보다 절대적으로 더 크고 느립니다. 사람의 가독성이나 상호 운용성에서 균형 잡힌 이점을 찾을 수 없다면 데이터 저장에 사용할 점은 없습니다.

XML은 상황에 따라 실행 가능합니다. 데이터가 상당히 정적이고 많이 변경되지 않으면 (예 : 샘플 데이터) 예 XML이 좋습니다.

구성 설정, 샘플 데이터 (수백만 행이지만 거의 변경되지 않음)는 모두 XML을 잘 사용합니다.

하드 디스크 읽기 / 쓰기는 Oracle / Sql 스택에서 데이터에 액세스하는 것보다 비쌉니다.

이것은 XML이 데이터 저장 용으로 사용되어서는 안되며 프로그램 간 상호 운용성에만 사용되어야한다고 강조하는 것 같습니다.

전제에 결함이 있습니다.

인용 한 단락은 실제로 XML이 데이터베이스를 대체 하는 것이 아니라 데이터 저장을 위해 사용되어서는 안된다는 것 입니다.

설정 파일은 데이터베이스와 동일하지 않으므로 다른 기술을 사용할 수 있습니다.

내가 틀렸다면 정정하되 데이터베이스보다 마크 업 언어에 더 많은 경험이있는 것 같습니다. 데이터베이스에 대해 약간의 경험이 있다면 두 가지 기술이 적합한 도메인을 알 수 있습니다.

이것은 정말 주관적입니다. 그 인용은 누군가의 의견과 같습니다.

솔직히 XML은 저렴한 오버 헤드를 포함하여 RDMS에 비해 RDMS에 비해 여러 가지 장점이 있기 때문에 (특히 데이터베이스를 별도로 청구하는 호스팅 서비스를 사용하는 경우) XML이 데이터베이스의 실행 가능한 대안이라고 생각합니다.

dasBlog 및 BlogEngine을 살펴보십시오 . 이 두 응용 프로그램 모두 기본적으로 저장을 위해 xml을 사용합니다.

그렇습니다. RDMS가 아니며 데이터에 변동성이 높거나 (많은 업데이트, 삽입 또는 삭제) 고 가용성이 필요한 경우 데이터베이스를 사용하십시오. XML은 구성 데이터 및 낮은 변동성 데이터와 같은 작은 항목을 저장하는 데 적합합니다.

내 질문은, 이것이 여전히 유효한 진술이며 이제 XML을 사용하여 데이터를 저장할 수 있습니까?

.NET 구성 파일에 대한 예제를 보았습니다. 그러나 다른 파일 형식이 사용되었을 수 있습니다. 사실 예전에는 이러한 설정을 INI 파일이라는 일반 텍스트 파일에 저장했습니다.

데이터베이스를 소프트웨어 시스템으로 정의하면 회색으로 표시된 설명 이 유효하고 정확 하다는 것을 알았습니다 .

XML- 정의에서 XML의 정의 는 "(XML)은 사람이 읽을 수 있고 기계가 읽을 수있는 형식으로 문서를 인코딩하기위한 규칙 세트를 정의하는 마크 업 언어"라고 말합니다.

이 정의는 데이터 관리 메커니즘 보다는 가독성과 언어에 중점을 둡니다 .

RDBMS와 비교하여 XML은 XML 파일에서 행을 무작위로 삽입하고 삭제하는 수단을 제공하지 않습니다. 예를 들어, 1000000 개의 행이 있고 단일 사용자 환경에서도 무작위로 행을 삭제하려는 경우 XML 기반 파일은 데이터베이스에 적합하지 않습니다. 또한 XML은 데이터 잠금을위한 기본 메커니즘을 제공하지 않습니다. 실제로 XML은 소프트웨어가 아니기 때문에 공유 환경에서 데이터베이스 트랜잭션을 안정적으로 처리 할 수 ​​있도록하는 모든 ACID (원 자성, 일관성, 격리, 내구성) 속성을 개발자가 빌드 할 수 있습니다 (내구성 제외). XML은 다른 서버 (예 : 고객 XML 파일 및 주문 XML 파일-무결성을 강제하는 FK 없음)는 물론 XML 파일의 데이터 무결성을 처리하기위한 강력한 사양이 없습니다.

위의 내용은 XML이 부족한 것에 대한 열거가 아니라 XML이 데이터베이스 소프트웨어 가 아니라는 진술을 신속하게 정당화 할 수있다 .

XML은 데이터베이스가되거나 대체하려는 것이 아닙니다.

XML은 주로 웹 문서에 대해 정의되지만 allows for the creation of customized tags for individual information fields.관계형 중앙 집중식 데이터 관리를 수행 할 수는 없습니다.

왜 실제로 데이터 를 저장 하기 위해 XML을 사용하고 싶 습니까? 결국 그것은 언어입니다 ...

유연하고 이해하기 쉬운 형식이라고 주장 할 수 있지만 파일을 수동으로 편집해야 할 때만 적용됩니다. 공통 인터페이스 (요구 사항 Y 및 Z를 충족하는 데이터 X 가져 오기, 데이터 X 저장 / 업데이트 ...)를 사용하여 데이터베이스 와 실제로 상호 작용할 때 이러한 이점은 무효가됩니다.

짧은 대답 : 그것은 달려 있습니다.

긴 대답 : 내 관점에서 이것은 저장하려는 데이터의 양에 크게 의존합니다. 예를 들어 런타임 동안 응용 프로그램에 몇 개의 객체가 있고 도구를 실행 한 후 저장하려는 경우 XML 파일이 완벽합니다. 그러나 웹숍에 5000 개의 고객이 있고 더 많은 주문이 있으면 데이터베이스가 더 적합한 데이터 저장 공간이됩니다.

또한 app.config와 같은 파일이 아닌 데이터베이스에 설정을 저장하는 것이 대부분의 경우 유용하지 않다고 생각하지만이 예제가 따옴표가 잘못되었다고 생각하지 않습니다.

XML은 구성 설정에 탁월한 선택입니다. IDE에서 XML 파일을 구문 분석 / 강조 표시하기 쉬울뿐만 아니라 프로그래머가 아닌 사람도 쉽게 편집 할 수 있습니다. 디자이너와 콘텐츠 관리자가 유지 관리 작업을 수행하는 웹 개발 시나리오에서 매우 유용합니다.

XML은 일반적으로 사소한 응용 프로그램의 기본 데이터 소스로 사용되어서는 안됩니다. 직렬화 / 역 직렬화 오버 헤드만으로 다른 솔루션을 구걸 할 수 있습니다.

데이터베이스 라는 용어 는 원시 데이터 만 또는 데이터베이스 관리 시스템을 의미 할 수 있습니다. 이 정의는 전체 논쟁에서 큰 차이를 만듭니다.

RDBMS 정의를 사용하면 XML의 의미가 거의 없습니다. ACID 보증 측면에서는 거의 얻지 못합니다 (이를 달성하려면 자체 코드를 작성해야합니다). 그것들이 필요하다면 (그리고 대부분의 트랜잭션 시스템이 필요하다면) 이미 큰 어려움에 처해 있습니다. RDBMS에서 부여 된 수백 가지 기능 목록을 제공 할 수 있습니다.이 기능은 다시 개발하고 다시 구현해야합니다. 보안 모델, 복제, 백업을 몇 가지 기본 이름으로 생각하십시오.

위의 의미에서 아니요, XML은 데이터베이스가 아니므로 XML을 데이터베이스로 사용해서는 안됩니다.

"원시 데이터"정의를 사용하면 XML이 훨씬 나아지지만 여전히 그렇게 크지는 않습니다. 다른 사람들이 지적했듯이 일반적으로 이진 인코딩이 부족하고 중복 태그가있는 등 일반적으로 장황합니다. XML은 사람이 읽을 수 있도록 만들어졌습니다. 기본적으로 효율성은이 요구 사항의 적입니다 . 또한 XML은 레코드를 지속적으로 삽입하는 가장 간단한 상황에도 적합하지 않습니다. XML 파일이 유효하다고 가정하면 단일 닫는 태그가 필요합니다. 즉, 레코드를 추가하면 끝에 태그를 위로 이동해야합니다. 이것은 매우 비쌉니다 (태그가 시작되는 위치를 어떻게 알 수 있습니까? 여러 개의 "테이블"이 있으면 어떻게합니까? 전체 파일을 위로 이동합니까?)

XML이 적절한 상황이 있습니다. 구성 파일은 일반적으로 작고 사람이 읽을 수있는 뛰어난 기능이기 때문에 좋은 예입니다. 구성 파일만을위한 데이터베이스를 갖는 것은 과잉 일 수 있습니다.

반면에 데이터베이스는 수천 (또는 수백만 / 십억)의 레코드가 있고 많은 사용자가 동시에 업데이트 할 때 우수합니다. 그렇습니다. XML은 데이터베이스가 아니므로 XML처럼 사용해서는 안됩니다. 귀하의 예는 처음에는 DB가 필요하지 않은 상황 중 하나이며 XML이 더 적합합니다.

내가 보는 방식은 다음과 같습니다. XML을 DB로 사용하는 경우 (예 : 트랜잭션 시스템의 백업 저장소) RDBMS를 다시 작성하고 다시 작성하게 됩니다. 그것은 당신의 시간과 에너지를 소비하는 정말 가난한 방법입니다. 나는 이것이 그 인용문이 말한 것이라고 생각합니다.

나는 그것이 관계형 데이터베이스가 아니라는 것에 동의합니다. 저자는 단순히 인용문에서 인용문을 사용하지 말라고 말합니다.

비록 당신이 그것을 필요로 할 수도 있고 필요하지 않을 수도 있다고 말했습니다. 데이터에 대해 많은 쿼리를 수행 할 필요가없고 데이터를 저장 한 다음 제한된 쿼리 기준에 따라 나중에 가져 오려는 경우 관계형 데이터베이스가 아닌 XML 문서 저장 및 검색이 필요합니다.

나중에 검색하기 위해 데이터가 포함 된 문서를 저장하기 만하면되는 많은 응용 프로그램이 있습니다. 이 경우 SQL 기반 스키마를 작성하고 XML을 구문 분석 한 후 나중에 데이터베이스를 직렬화하여 나중에 반대의 작업을 수행하는 것은 쓸모가 없습니다. 이를 수행하는 데 잠재적으로 많은 코드 오버 헤드가 있습니다. 당신이 올바르게하면 덜 있습니다.

간단한 CRU 작업 만 처리하는 서비스를 구축하는 데 필요한 거의 모든 코드를 자동 생성하기 위해 Hibernate와 같은 ORM 도구와 Apache Axis와 같은 도구를 사용할 수 있습니다. 물론 인증 과정에서 랩핑해야하며 사용자, 액세스 수준 등에 따라 데이터를 분리해야 할 수도 있습니다. SOAP 서비스를 통해 지정된 사용자가 수행 할 수있는 작업을 제한 할 수도 있습니다 예.

이런 의미에서 당신은 다른 것보다 더 많은 컨텐츠 관리를하고 있습니다.