Document
document는 ArangoDB에서 JSON object이다. 예시 형태는 아래와 같다.{
"_id" : "myusers/3456789",
"_key" : "3456789",
"_rev" : "14253647",
"firstName" : "John",
"lastName" : "Doe",
"address" : {
"street" : "Road To Nowhere 1",
"city" : "Gotham"
},
"hobbies" : [
{name: "swimming", howFavorite: 10},
{name: "biking", howFavorite: 6},
{name: "programming", howFavorite: 4}
]
}- _id : document의 고유 id로 collection이름과 _key값의 조합값이다.
- _key : primary key. 이 값은 document 생성시 사용자가 지정할 수 있다. ArangoDB의 primary index에 의해 자동으로 index된다. 이 값은, Collection내에서 유일한 값이어야 한다. database나 전체에서 유일한 값은 아니다.(no guarantee)
- _rev : revision. ArangoDB에 의해 관리된다.
Document Revision
ArangoDB는 MVCC(Multiple Version Concurrency Control)를 지원한다. 하나의 document는 여러 revision을 가질 수 있다. revision은 숫자가 포함된 문자열 값이며, 한 document에 대해 고유한 값이다. ArangoDB 3.1이상에서는 _rev 값은 timestamp이다. 이 timestamp는 ArangoDB서버의 local시간이며 millisec 단위이다. 정확히는 "Hybrid Logical Clock"이 사용된다. 만약 동시에 write된다하더라도, 하나의 shard 내에서 한 document의 서로 다른 revision은 서로 다른 _rev값을 갖는 것이 보장된다. 그러나 cluster내 서버 간의 시간 차가 있을 수 있고, 서로 다른 shard나 collection간에 timestamp에 대한 고유값 보장이 불가능하다.
Hybrid Logical Clock에서는 이러한 특징에 대해 다음과 같이 언급했다. :
cluster 내 서버 A -> 서버 B로 메세지가 전송될 때, message 출발과 도착에 약간의 시간이 소요되기때문에 보낸 시간보다 받은시간이 timestamp값이 크다. 해결책 중 하나는 실제 시간보다 미래의 시간의 timestamp 값을 취하는 것인데 시간차가 크지 않다면 상대적으로 정확하지만 그래도 시간차는 생길 수 있다.
ArangoDB는 Revision 값을 위해 내부적으로 64bit unsigned integer를 사용한다. client로 document revision이 반환될 때, big integer를 지원하지 않는 client에 의해 값이 잘리지 않게 하기 위해 revision값을 string으로 넣는다. client는 revision을 다루거나 저장할 때 ArangoDB에 의해 문자열로 return 된 값으로 다루어야 한다.
EmoticonEmoticon