JSON 데이터베이스의 전체 기록 조회

CoreSvelte based Frontend에 기부
다음 그림에서는 이벤트를 수정하여 SirixDB의 상태 변화를 보여 줍니다.

소개


우선, 데이터베이스 시스템이 몇 메가바이트에서 몇 메가바이트까지의 작은 JSON 파일을 처리할 필요가 없을 수도 있습니다.
그러나 GBs 데이터를 관리하고 조회해야 한다면 데이터베이스 시스템을 사용해야 합니다.
그러나 데이터베이스 시스템은 일반적으로 데이터의 완전한 역사 기록을 저장하는 데 쓰이지 않는다.일반적으로 시스템은 변경 기간 동안 데이터를 덮어쓰거나 짧은 시간 동안 보존합니다.후자는 통상적으로 현재 약간 유행이 지난 데이터를 읽는 사무 때문에 일어난다.따라서 쓰레기 수집기는 모든 읽기 작업이 끝날 때까지 기다려야 한다.그리고 오래된 데이터를 삭제할 수 있습니다.
반면 SirixDB는 커다랗고 지속적인 트리를 생성하여 제출 과정에서 지속적입니다.그것은 데이터만 추가할 뿐이다.모든 수정은 인덱스되고 공유가 변하지 않는 페이지 부분을 수정합니다.Git로 생각하지만 하위 파일 레벨에 있습니다.영구 트리는 Haskell과 패키지 닫기 등 함수 언어에서도 흔히 볼 수 있다.트랜잭션 커밋은 다음 그림과 같이 페이지의 뒷면에 정렬됩니다.

일반적으로 이러한 지속적인 메모리 구조를 지속적인 장치에 비추면 전체 잎에서 뿌리까지의 경로를 조정해야 하기 때문에 쓰기 확대가 증가한다.그러나, 우리는 키 제어trie를 주 문서로 저장합니다.따라서 B-트리처럼 구조 변화가 일어나지 않는다.그 밖에 우리는 새로운 슬라이딩 스냅샷 알고리즘을 개발하여 데이터 페이지를 버전화하고 가변 크기의 페이지 부분을 저장했다.따라서 변경된 기록은 소수만 새 페이지 세션에 기록됩니다.재구성 메모리의 페이지는 무작위 위치에서 페이지의 세션을 동시에 읽는 슬라이딩 창과 관련됩니다.
빠르고 무작위적이며 세분화된 읽기에 대한 요구로 인해 바이트 주소 찾기 NVM과 같은 현대 하드웨어는 좋은 성능에 매우 중요하다.
SirixDB는 JSON 데이터를 바이너리 형식으로 저장하고 각 트랜잭션은 특정 버전으로 바인딩됩니다.현재, 하나의 자원에 있는 N개의 읽기 전용 사무는 하나의 자원에 있는 읽기 전용 사무와 공존할 수 있다(JSON 데이터를 나타낸다).
인코딩은 다음과 같다. 다만 우리는 최근에 부모 노드에서 마지막 하위 노드까지의 지침을 도입했다.

데이터 조회


이 시스템은 XML과 JSON 데이터를 처리하기 위해 XQuery 3.0 프로세서를 사용하고 확장합니다.
다음과 같은 방법으로 특정 디렉토리에서 JSON 파일을 가져올 수 있습니다.
jn:load('mycol.jn', (), io:ls('/home/johannes/json-data', '\\.json$'))
그것은 mycol.jn라는 데이터베이스와 몇 개의 자원을 만들 것이다.
데이터베이스(mycol.jn)의 여러 리소스에 JSON 문자열 세트를 저장할 수도 있습니다.
jn:store('mycol.jn',(),('["bla", "blubb"]','{"foo": true}'))
JSON 문자열이 나타나면 truefalsetrue()false(), nulljn:null() 로 교체해야 합니다.
그런 다음 데이터베이스 컬렉션을 조회할 수 있습니다.
for $doc in jn:collection('mydocs.col') return $doc
또는 데이터베이스에 있는 특정 리소스를 열려면 다음과 같이 하십시오.
jn:doc('mydocs.col', 'myresource1')
그 밖에 우리는 자원을 갱신할 수 있다.다음과 같은 작은 JSON 파일이 있다고 가정합니다.
{
  "foo": [
    "bar",
    null,
    2.33
  ],
  "bar": {
    "hello": "world",
    "helloo": true
  },
  "baz": "hello",
  "tada": [
    {
      "foo": "bar"
    },
    {
      "baz": false
    },
    "boo",
    [],
    {}
  ]
}
JSON 객체를 삽입할 수 있습니다.
insert json { "name": "keyword" } into jn:doc('mydocs.col', 'myresource1')=>tada=>foo
우리는 => 연산자를 사용하여 인용 대상 필드의 이름을 취소합니다.그것은 심지어 수조에 깊이 들어가 필드 이름의 값을 찾을 수 있다.
업데이트 작업은 필드 이름과 부가가치를 사용하여 새 개정을 작성합니다.예:
jn:doc('mydocs.col', 'myresource1')=>tada[[0]]
필드 이름tada의 그룹 값에서 첫 번째 객체를 선택합니다.
{
  "foo": "bar",
  "name": "keyword"
}
우리는 수정판 2를 은밀하게 조회한다.쿼리 수정 버전 1로 변경된 경우에도 이전 JSON 객체를 검색합니다.
jn:doc('mydocs.col', 'myresource1', 1)=>tada[[0]]
주의, 우리는 함수로서의 세 번째 매개 변수를 지정했다.출력:
{
  "foo": "bar"
}
또한 타임스탬프를 통해 세 번째 매개변수에 대한 수치가 아닌 특정 버전을 열 수 있습니다 (이곳: 2018년 4월 특정 리소스의 모양 확인).
jn:open('mydocs.col', 'myresource1', xs:dateTime(\"2018-04-01T05:00:00-00:00\"))
open revisions 기능을 사용하면 두 시간 사이에 자원의 모든 수정을 불러올 수 있습니다.
jn:open('mydocs.col', 'myresource1', xs:dateTime(\"2018-04-01T05:00:00-00:00\", xs:dateTime(\"2019-04-01T05:00:00-00:00\"))
다음 질의는 참조된 배열 값 =>foo 에 두 번째 항목으로 객체를 삽입합니다.
insert json { "name": "keyword" } into jn:doc('mydocs.col', 'myresource1')=>foo at position 1
활용단어참조
jn:doc('mydocs.col', 'myresource1')=>foo 
우리는 출력을 얻었다.
[
  "bar",
  {
    "foo": "bar"
  },
  null,
  2.33
]
마찬가지로 JSON 값을
replace json value of jn:doc('mydocs.col', 'myresource1')=>tada[[0]] with "yes"
또는 값을 삭제합니다.
delete json jn:doc('mydocs.col', 'myresource1')=>tada[[0]]
REST-API를 통해 질의를 제출하려면 먼저 승인을 받아야 합니다.따라서 Git에서 개정은 작성자의 이름과 UUID를 저장합니다.
특정 개정을 제출한 작성자의 이름을 가져오려면:
jn:author-name(jn:doc(...))
UUID 가져오기
jn:author-uuid(jn:doc(...))
필드를 투영할 수도 있습니다.
jn:doc('mydocs.col', 'myresource1')=>bar{hello} 
다음과 같이 출력됩니다.
{
  "hello": "world"
}

시간 여행 기능


그 밖에 우리는 일련의 시간 여행 조회를 사용할 수 있다.다음 함수는 JSON 항목의 다른 버전을 읽어들입니다.
jn:future($item as json-item(), $includeSelf as xs:boolean) as json-item()*
함수는 장래 또는 장래 또는 자신의 json 항목을 선택하는 데 사용됩니다.첫 번째 매개변수는 컨텍스트 항목입니다.두 번째 매개변수는 현재 항목이 결과에 포함되어야 하는지 여부를 나타냅니다.
jn:past($item as json-item(), $includeSelf as xs:boolean) as json-item()*
함수는 과거나 과거나 자신의 json 항목을 선택하는 데 사용됩니다.첫 번째 매개변수는 컨텍스트 항목입니다.두 번째 매개변수는 현재 항목이 결과에 포함되어야 하는지 여부를 나타냅니다.
jn:all-times($item as json-item()) as json-item()+
모든 수정에서 json 항목을 선택하는 함수입니다.
jn:first($item as json-item()) as json-item()?
첫 번째 버전에서 json 항목을 선택하는 함수입니다.
jn:last($item as json-item()) as json-item()?
이전/최신 버전의 json 항목을 선택하는 함수입니다.
jn:previous($item as json-item()) as json-item()?
함수는 이전 버전의 json 항목을 선택하는 데 사용됩니다.
jn:next($item as json-item()) as json-item()?
다음 버전에서 json 항목을 선택하는 함수입니다.
모든 개정에서 변경되거나 삽입된 항목을 가져오려면 다음과 같이 하십시오.
jn:history($item as json-item()) as json-item()?

퍼지다


물론 차이점도 검색할 수 있습니다.
jn:diff('mydocs.col', 'myresource2', 1, 3)
이 함수는 myresource2라는 자원의 수정 버전 1과 수정 버전 3을 비교합니다.
출력 형식은 JSON 문자열입니다.
{
  "database": "json-path1",
  "resource": "shredded",
  "old-revision": 1,
  "new-revision": 3,
  "diffs": [
    {
      "insert": {
        "nodeKey": 26,
        "insertPositionNodeKey": 1,
        "insertPosition": "asFirstChild",
        "deweyID": "1.17.9",
        "depth": 2,
        "type": "jsonFragment",
        "data": "{\"tadaaa\":\"todooo\"}"
      }
    },
    {
      "delete": {
        "nodeKey": 13,
        "deweyID": "1.17.49",
        "depth": 2
      }
    },
    {
      "update": {
        "nodeKey": 15,
        "deweyID": "1.17.65",
        "depth": 2,
        "name": "tadaa"
      }
    }
  ]
}
예를 들어 우리GUI도 이런 형식을 사용하는데 우리가 현재 개발한 것은 Svelte 기반이다.
이는 SirixDB가 버전 1과 3을 비교했음을 나타냅니다.그 밖에 서로 다른 차이 유형은 insert, delete, update and replace (후자는 표시되지 않음) 이다.insertPositionNodeKey는 상하문 노드이고 삽입은 그 중에서 발생한다. insertPosition는 그것이 첫 번째 하위 노드로 삽입된 것인지, 오른쪽 동포 노드로 삽입된 것인지, 왼쪽 동포 노드로 삽입된 것인지를 나타낸다.
우리는 또한 하위 트리를 구분하고 두 개의 추가 매개 변수를 지정할 수 있다.비교할 root nodedepth:
jn:diff('mydocs.col', 'myresource2', 1, 3, 7453, 2)
이것은 myresource2 데이터베이스에 있는 mydocs.col 자원의 제1판과 제3판을 비교했다.그러나 이번에는 diff가 노드에서 시작하여 유일한 nodeKey 7453으로 표시됩니다.그 밖에 확산은 자체를 뛰어넘어야 하며, 자체의 깊이는 2급을 넘어야 한다.
특정 항목nodeKey을 얻기 위해 다음과 같이 사용할 수 있습니다.
sdb:nodekey(...)

결론


SirixDB는 데이터의 전체 기록을 조회할 수 있는 강력한 방법을 제공합니다.
우리는 색인 구조의 생성을 생략했지만, XQuery를 사용하여 2급 색인 구조를 만들 수도 있고, 2급 색인 구조도 자동으로 버전 제어를 할 수 있습니다.
다음 문서를 고려하십시오(SirixDB 리소스 정렬 두 개정).
{
  "sirix": [{
    "revisionNumber": 1,
    "revision": {
      "foo": ["bar", null, 2.33],
      "bar": {
        "hello": "world",
        "helloo": true
      },
      "baz": "hello",
      "tada": [{
        "foo": "bar"
      }, {
        "baz": false
      }, "boo", {},
        []
      ]
    }
  }, {
    "revisionNumber": 2,
    "revision": {
      "tadaaa": "todooo",
      "foo": ["bar", null, 2.33],
      "bar": {
        "hello": "world",
        "helloo": true
      },
      "baz": "hello",
      "tada": [{
        "foo": "bar"
      }, {
        "baz": false
      }, "boo", {},
        []
      ]
    }
  }]
}
다음과 같이 CAS(Content and Fabrics) 색인을 만들 수 있습니다.
let $doc := jn:doc('mycol.jn','mydoc.jn')
let $stats := jn:create-cas-index($doc, 'xs:string', '/sirix/[]/revision/tada//[]/foo/[]/baz') return {"revision": sdb:commit($doc)}
이 질문에 대답하기 위해서.
let $result := jn:doc('mycol.jn','mydoc.jn')=>sirix[[2]]=>revision=>tada[.=>foo=>baz >= 'baa' and .=>foo=>baz <= 'brr'] return $result

또한 XQuery의 기반인 Flower 표현식은 언급하지 않았습니다.암시적 연결을 포함하는 간단한 예:
for $i in jn:doc('mycol.jn','mydoc.jn')=>paths=>"/consolidated_screening_list/search"=>get
let $j := $i=>parameters=>name
return for $k in $j
       where $k eq 'keyword'
       return { "result": $i, "nodekey": sdb:nodekey($i) }

좋은 웹페이지 즐겨찾기