전역 변수는 데이터 저장을 위한 보물 같은 검입니다. 나무. 2 부

시작하기 - 1부 참조

3. 전역 사용 시 구조의 변형

정렬된 트리와 같은 구조에는 다양한 특수 사례가 있습니다. 전역으로 작업할 때 실용적인 가치가 있는 것들을 고려해 보겠습니다.

3.1 특별한 경우 1. 가지가 없는 하나의 노드

전역 변수는 배열처럼 사용될 수 있을 뿐만 아니라 일반 변수처럼 사용될 수도 있습니다. 예를 들어, 카운터로서:

Set ^counter = 0  ; установка счётчика
Set id=$Increment(^counter) ;  атомарное инкрементирование

이 경우 전역은 그 의미 외에도 분기를 가질 수도 있습니다. 하나는 다른 하나를 배제하지 않습니다.

3.2 특별한 경우 2. 하나의 꼭지점과 많은 가지

일반적으로 이는 전형적인 키-값 기반입니다. 그리고 값의 튜플을 값으로 저장하면 기본 키가 있는 매우 일반적인 테이블을 얻게 됩니다.

전역에 테이블을 구현하려면 열 값에서 직접 행을 생성한 다음 기본 키를 사용하여 전역에 저장해야 합니다. 읽을 때 문자열을 다시 열로 나눌 수 있게 하려면 다음을 사용하면 됩니다.

1. 구분 문자.

   Set ^t(id1) = "col11/col21/col31"
   Set ^t(id2) = "col12/col22/col32"

2. 각 필드가 미리 결정된 바이트 수를 차지하는 엄격한 방식입니다. 관계형 데이터베이스에서도 마찬가지입니다.
3. 값의 문자열을 생성하는 특수 함수 $LB(캐시에서 사용 가능).

   Set ^t(id1) = $LB("col11", "col21", "col31")
   Set ^t(id2) = $LB("col12", "col22", "col32")

흥미롭게도 관계형 데이터베이스의 보조 인덱스와 유사한 작업을 수행하기 위해 전역을 사용하는 것은 어렵지 않습니다. 이러한 구조를 인덱스 전역이라고 부르자. 인덱스 글로벌은 기본 글로벌의 기본 키의 일부가 아닌 필드를 빠르게 검색하기 위한 보조 트리입니다. 이를 작성하고 사용하려면 추가 코드를 작성해야 합니다.

첫 번째 열에 전역 인덱스를 만들어 보겠습니다.

Set ^i("col11", id1) = 1
Set ^i("col12", id2) = 1

이제 첫 번째 열의 정보를 빠르게 검색하려면 전역을 살펴봐야 합니다. ^i 첫 번째 열의 원하는 값에 해당하는 기본 키(id)를 찾습니다.

값을 삽입하면 필수 필드에 대한 값과 인덱스 전역을 즉시 생성할 수 있습니다. 그리고 신뢰성을 위해 모든 것을 트랜잭션으로 마무리하겠습니다.

TSTART
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^i("col11", id1) = 1
TCOMMIT

M에서 수행하는 방법에 대한 세부 정보 전역 테이블, 보조 인덱스 에뮬레이션.

행 삽입/업데이트/삭제 기능이 COS/M에 작성되고 컴파일되면 이러한 테이블은 기존 데이터베이스만큼 빠르게 작동합니다(또는 훨씬 더 빠르게).TSTART 및 TCOMMIT 명령(트랜잭션) 사용을 포함하여 하나의 XNUMX열 테이블에 대한 대량 INSERT 및 SELECT 테스트를 통해 이 명령문을 확인했습니다.

동시 액세스 및 병렬 트랜잭션이 포함된 더 복잡한 시나리오는 테스트하지 않았습니다.

트랜잭션을 사용하지 않은 경우 삽입 비율은 백만 값당 초당 778개의 삽입입니다.
300억 개의 값 - 초당 422개의 삽입.

트랜잭션을 사용하는 경우 - 572M 삽입의 경우 초당 082 삽입입니다. 모든 작업은 컴파일된 M 코드에서 수행되었습니다.
하드디스크는 SSD가 아닌 일반 하드입니다. 다시 쓰기 기능이 있는 RAID5. 페놈 II 1100T 프로세서.

비슷한 방식으로 SQL 데이터베이스를 테스트하려면 루프에서 삽입을 수행하는 저장 프로시저를 작성해야 합니다. MySQL 5.5(InnoDB 스토리지)를 테스트할 때 이 방법을 사용하면 초당 11K 이하의 삽입을 수신했습니다.
예, 전역 테이블 구현은 관계형 데이터베이스보다 더 복잡해 보입니다. 따라서 전 세계의 산업 데이터베이스에는 표 형식 데이터 작업을 단순화하기 위한 SQL 액세스 권한이 있습니다.

일반적으로 데이터 스키마가 자주 변경되지 않고 삽입 속도가 중요하지 않으며 전체 데이터베이스가 정규화된 테이블 형식으로 쉽게 표현될 수 있다면 더 높은 수준의 추상화를 제공하므로 SQL 작업이 더 쉽습니다. .

이 특별한 경우에 나는 다음을 보여주고 싶었습니다. 전역은 다른 데이터베이스를 생성하기 위한 생성자 역할을 할 수 있습니다.. 다른 언어를 작성할 수 있는 어셈블러와 같습니다. 다음은 전역에서 아날로그를 만드는 방법에 대한 예입니다. 키-값, 목록, 세트, ​​테이블 형식, 문서 지향 데이터베이스.

최소한의 노력으로 일종의 비표준 데이터베이스를 생성해야 한다면 전역을 고려해야 합니다.

3.3 특별한 경우 3. XNUMX레벨 트리, 두 번째 레벨의 각 노드는 고정된 수의 가지를 가짐

아마도 짐작하셨을 것입니다. 이것은 전역 테이블의 대체 구현입니다. 이 구현을 이전 구현과 비교해 보겠습니다.

XNUMX단계 트리의 테이블과 단일 레벨 트리에서.

죄수 팀은
프로

1. 노드 수를 열 수와 동일하게 설정해야 하므로 삽입 속도가 느려집니다.
2. 더 많은 디스크 공간을 소비합니다. 열 이름이 있는 글로벌 인덱스(배열 인덱스로 이해됨)는 디스크 공간을 차지하고 각 행에 대해 복제되기 때문입니다.

1. 문자열을 구문 분석할 필요가 없으므로 개별 열의 값에 더 빠르게 액세스할 수 있습니다. 내 테스트에 따르면 11,5개 열에서는 2% 더 빠르며 더 많은 수의 열에서는 더 빠릅니다.
2. 데이터 스키마 변경이 더 쉬워짐
3. 더욱 명확한 코드

결론 : 모든 사람을 위한 것은 아닙니다. 속도는 전역의 가장 중요한 이점 중 하나이기 때문에 이 구현을 사용하는 데는 거의 의미가 없습니다. 왜냐하면 관계형 데이터베이스의 테이블보다 더 빠르게 수행되지 않을 가능성이 높기 때문입니다.

3.4 일반적인 경우. 나무와 정렬된 나무

트리로 표현될 수 있는 모든 데이터 구조는 전역에 완벽하게 맞습니다.

3.4.1 하위 객체가 있는 객체

이것은 글로벌의 전통적인 사용 영역입니다. 의료분야에는 수많은 질병, 약물, 증상, 치료방법이 존재합니다. 각 환자에 대해 백만 개의 필드가 있는 테이블을 만드는 것은 비합리적입니다. 또한 필드의 99%가 비어 있습니다.

"환자" ~ 100개 필드, "의학" - 000개 필드, "치료" - 100개 필드, "합병증" - 000개 필드 등의 테이블로 구성된 SQL 데이터베이스를 상상해 보세요. 등등. 또는 특정 유형의 환자에 대한 수천 개의 테이블(겹칠 수 있음!), 치료, 약물 및 이러한 테이블 간의 연결을 위한 수천 개의 추가 테이블로 구성된 데이터베이스를 생성할 수 있습니다.

Globals는 빈 열에 추가 디스크 공간을 낭비하지 않고 각 환자의 병력, 다양한 치료법 및 약물 작용에 대한 정확한 설명을 나무 형태로 생성할 수 있으므로 의학에 이상적입니다. 관계형 경우에 해당합니다.

글로벌을 사용하면 사람에 대한 데이터로 데이터베이스를 만드는 것이 편리합니다., 고객에 대한 다양한 정보를 최대한 축적하고 체계화하는 것이 중요한 경우. 이는 의학, 은행, 마케팅, 보관 및 기타 분야에서 수요가 많습니다.

.
물론 SQL에서는 몇 개의 테이블만으로 트리를 에뮬레이트할 수도 있습니다(에브, 1,2,3,4,5,6,7,8,9,10) 그러나 이는 훨씬 더 복잡하고 속도가 느려집니다. 기본적으로 테이블에서 작동하는 전역을 작성하고 추상화 계층 아래 테이블과 관련된 모든 작업을 숨겨야 합니다. 상위 수준 기술(SQL)을 사용하여 하위 수준 기술(전역)을 에뮬레이트하는 것은 잘못된 것입니다. 부적절합니다.

거대한 테이블(ALTER TABLE)에서 데이터 스키마를 변경하는 데 상당한 시간이 걸릴 수 있다는 것은 비밀이 아닙니다. 예를 들어 MySQL은 이전 테이블의 정보를 새 테이블로 완전히 복사하여 ALTER TABLE ADD|DROP COLUMN을 수행합니다(테스트된 MyISAM, InnoDB 엔진). 몇 주가 아니더라도 며칠 동안 수십억 개의 레코드가 포함된 작업 데이터베이스가 중단될 수 있습니다.

전역을 사용하는 경우 데이터 구조를 변경하면 비용이 전혀 들지 않습니다. 언제든지 계층 구조의 모든 수준에서 개체에 필요한 새 속성을 추가할 수 있습니다. 분기 이름 바꾸기와 관련된 변경 사항은 실행 중인 데이터베이스에서 백그라운드로 실행될 수 있습니다.


따라서 수많은 선택적 속성이 포함된 개체를 저장하는 경우 전역 변수가 탁월한 선택입니다.

또한 전역에서 모든 경로는 B-트리이므로 모든 속성에 대한 액세스는 즉각적이라는 점을 상기시켜 드리겠습니다.

일반적으로 글로벌 데이터베이스는 계층적 정보를 저장할 수 있는 기능을 갖춘 문서 중심 데이터베이스 유형입니다. 따라서 문서 중심 데이터베이스는 의료 기록 저장 분야에서 글로벌 기업과 경쟁할 수 있습니다. 하지만 여전히 완전히 똑같지는 않아요비교를 위해 MongoDB를 살펴보겠습니다. 이 도메인에서는 다음과 같은 이유로 전역에 패배합니다.

1. 문서 크기. 저장 단위는 최대 용량이 약 16MB인 JSON(보다 정확하게는 BSON) 형식의 텍스트입니다. 거대한 JSON 문서가 JSON 데이터베이스에 저장된 후 필드에서 액세스되는 경우 JSON 데이터베이스가 구문 분석 중에 느려지지 않도록 특별히 제한이 적용되었습니다. 이 문서에는 환자에 대한 모든 정보가 포함되어야 합니다. 우리 모두는 환자 기록이 얼마나 두꺼운지 알고 있습니다. 16MB의 최대 카드 크기로 인해 MRI 파일, X-ray 스캔 및 기타 연구가 포함된 질병 카드를 가진 환자의 경우 즉시 종료됩니다. 글로벌의 한 지점에서는 기가바이트 및 테라바이트의 정보를 얻을 수 있습니다. 원칙적으로는 이를 끝낼 수 있지만 계속하겠습니다.
2. 환자 차트의 새로운 속성이 의식/변경/삭제된 시간입니다. 이러한 데이터베이스는 전체 맵을 메모리로 읽고(이것은 많은 양입니다!) BSON을 구문 분석하고, 새 노드를 추가/변경/삭제하고, 인덱스를 업데이트하고, BSON으로 압축하고, 디스크에 저장해야 합니다. 전역은 특정 속성에 액세스하고 이를 조작하기만 하면 됩니다.
3. 개별 속성에 빠르게 액세스할 수 있습니다. 문서의 속성이 많고 다단계 구조가 있으면 전역의 각 경로가 B-트리이므로 개별 속성에 대한 액세스가 더 빨라집니다. BSON에서는 원하는 속성을 찾기 위해 문서를 선형적으로 구문 분석해야 합니다.

3.3.2 연관배열

연관 배열(중첩 배열 포함)은 전역에 완벽하게 맞습니다. 예를 들어, PHP의 배열은 첫 번째 그림 3.3.1에 표시됩니다.

$a = array(
  "name" => "Vince Medvedev",
  "city" => "Moscow",
  "threatments" => array(
    "surgeries" => array("apedicectomy", "biopsy"),
    "radiation" => array("gamma", "x-rays"),
    "physiotherapy" => array("knee", "shoulder")
  )
);

3.3.3 계층적 문서: XML, JSON

또한 전역에 쉽게 저장됩니다. 다양한 방법으로 배치하여 보관할 수 있습니다.

XML
XML을 전역으로 분해하는 가장 쉬운 방법은 태그 속성을 노드에 저장하는 것입니다. 그리고 태그 속성에 대한 빠른 액세스가 필요한 경우 해당 속성을 별도의 분기로 이동할 수 있습니다.

<note id=5>
<to>Вася</to>
<from>Света</from>
<heading>Напоминание</heading>
<body>Позвони мне завтра!</body>
</note>

COS에서는 다음 코드에 해당합니다.

Set ^xml("note")="id=5"
Set ^xml("note","to")="Саша"
Set ^xml("note","from")="Света"
Set ^xml("note","heading")="Напоминание"
Set ^xml("note","body")="Позвони мне завтра!"

참고 : XML, JSON, 연관 배열의 경우 전역에 표시하는 다양한 방법을 생각해 낼 수 있습니다. 이 경우 노트 태그에 하위 태그의 순서를 반영하지 못했습니다. 전 세계적으로 ^xml 하위 태그는 알파벳 순서로 표시됩니다. 순서를 엄격하게 반영하려면 예를 들어 다음 표시를 사용할 수 있습니다.

JSON.JSON
섹션 3.3.1의 첫 번째 그림은 이 JSON 문서를 반영한 ​​것입니다.

var document = {
  "name": "Vince Medvedev",
  "city": "Moscow",
  "threatments": {
    "surgeries": ["apedicectomy", "biopsy"],
    "radiation": ["gamma", "x-rays"],
    "physiotherapy": ["knee", "shoulder"]
  },
};

3.3.4 계층적 관계로 연결된 동일한 구조

예: 영업 사무소 구조, MLM 구조에 있는 사람들의 위치, 체스 오프닝 데이터베이스.

데이터베이스를 데뷔합니다. 스트로크 힘 추정값을 전역 노드의 인덱스 값으로 사용할 수 있습니다. 그런 다음 가장 강력한 움직임을 선택하려면 가장 큰 가중치를 갖는 지점을 선택하면 충분합니다. 글로벌에서는 각 레벨의 모든 분기가 이동 강도에 따라 정렬됩니다.

영업 사무소의 구조, MLM의 사람들의 구조. 노드는 전체 하위 트리의 특성을 반영하는 특정 캐싱 값을 저장할 수 있습니다. 예를 들어 특정 하위 트리의 판매량입니다. 언제든지 우리는 각 분야의 성과를 반영하는 수치를 얻을 수 있습니다.

4. 전역 변수를 사용하는 것이 어떤 경우에 가장 유익합니까?

첫 번째 열은 전역을 사용하여 상당한 속도 향상을 얻을 수 있는 사례를 제시하고, 두 번째 열은 디자인이나 데이터 모델이 단순화되는 경우를 보여줍니다.

속도
데이터 처리/표현의 용이성

1. 삽입 [레벨별 자동정렬], [마스터키별 인덱싱]
2. 하위 트리 제거
3. 개별 액세스가 필요한 중첩된 속성이 많은 객체
4. 존재하지 않는 분기라도 모든 분기에서 하위 분기를 우회할 수 있는 기능을 갖춘 계층적 구조
5. 하위 트리의 깊이 우선 순회

1. 수많은 선택적 [및/또는 중첩된] 속성/엔티티가 있는 객체/엔티티
2. 스키마 없는 데이터. 새로운 속성이 자주 나타나고 오래된 속성은 사라질 수 있습니다.
3. 사용자 정의 데이터베이스를 생성해야 합니다.
4. 경로 기반 및 의사결정 트리. 경로를 트리로 표현하는 것이 편리한 경우.
5. 재귀를 사용하지 않고 계층 구조 제거

확장 “글로벌은 데이터 저장을 위한 보물검입니다. 희소 배열. 3부".

책임 부인: 이 기사와 이에 대한 내 의견은 내 의견이며 InterSystems Corporation의 공식 입장과 관련이 없습니다.

출처 : habr.com