Cosmos DB에서 그래프 API를 사용하는 것이 (documentdb) SQL API

에 비해 매우 느립니다. CosmosDB가 GraphAPI로 설정되었다는 것을 감안할 때. ~ 4k 개의 정점과 ~ 10k 에지가있는 그래프, GraphAPI와 DocumentAPI의 동일한 쿼리가 동일한 데이터베이스에 대해 상당히 다른 실행 시간을 보여줍니다. 문서가 그대로 ~ 1.8 초에 GraphAPI에 의해 반환에 대한 조회되는Cosmos DB에서 그래프 API를 사용하는 것이 (documentdb) SQL API

var Gremlin = require('gremlin'); 
var config = require("./config"); 
var documentdb = require('documentdb'); 

const docClient = new documentdb.DocumentClient(....); 
const graphClient = Gremlin.createClient(....); 


const start = new Date(); 
graphClient.execute('g.V("12345")', {}, (err, results) => { 
    const end = new Date(); 
    if (err) { 
     return console.error(err); 
    } 

    console.log(`GraphDB API Results in: ${(end.getTime() - start.getTime())/1000}`); 
}); 

var querySpec = { 
    query: 'SELECT * FROM c ' + 
      'WHERE c.id = "12345"', 

}; 
const docStart = new Date(); 
docClient.queryDocuments("dbs/graphdb/colls/sn", querySpec).toArray((err, results) => { 
    const docEnd = new Date(); 
    if (err) { 
     console.error(JSON.stringify(err, null, 2)); 
     return; 
    } 

    console.log(`DocumentDB API Results in: ${(docEnd.getTime() - docStart.getTime())/1000}`) 
});

이 코드의 출력은 하나의 문서를 보여줍니다 : 나는 다음 노드 응용 프로그램을 사용하는 API의 차이를 테스트했습니다 ~ 0.3 초 안에 documentdb api에서 반환되었습니다.

DocumentDB의 API 결과 :

[ 
    { 
    "label": "company", 
    "id": "12345", 
    "parent": [ 
     { 
     "_value": "54321", 
     "id": "de7c87f7-83db-43c2-8ddd-c5487dd5682e" 
     } 
    ], 
    "name": [ 
     { 
     "_value": "Acme Co", 
     "id": "b4316415-d5c3-4dcc-ac5f-64b1d8c8bd62" 
     } 
    ], 
    "_rid": "KPk3APUeEgFcAAAAAAAAAA==", 
    "_self": "dbs/KPk3AA==/colls/KPk3APUeEgE=/docs/KPk3APUeEgFcAAAAAAAAAA==/", 
    "_etag": "\"0000df07-0000-0000-0000-5a2b23bd0000\"", 
    "_attachments": "attachments/", 
    "_ts": 1512776637 
    } 
]

GraphDB의 API 결과 :

[ 
    { 
    "id": "12345", 
    "label": "company", 
    "type": "vertex", 
    "properties": { 
     "parent": [ 
     { 
      "id": "de7c87f7-83db-43c2-8ddd-c5487dd5682e", 
      "value": "54321" 
     } 
     ], 
     "name": [ 
     { 
      "id": "b4316415-d5c3-4dcc-ac5f-64b1d8c8bd62", 
      "value": "Acme Co" 
     } 
     ] 
    } 
    } 
]

모든 예는 10,000에 RU의 켜져있는 모든 방법과 고정 된 크기의 컬렉션입니다.

여기 뭔가 잘못 되었나요? 더 나은/더/더 적은 수의 지수를 만들어야합니까? 코스모스 (Cosmos)와 같은 클라우드 스케일 데이터베이스는 쿼리 구조에 관계없이 1 초 이내에 단일 문서를 반환 할 수 없다는 것은 당연한 것입니다.

hasLabel ('x')을 반환 할 때 5 초 이상 걸리며 간단한 순회 (gV(), hasLabel ('x'), out ('y'), hasLabel ('z' 개수는 ~ 40입니다. hasLabel ('x') 카운트가 ~ 1000이면 통과하는 데 15 초 이상 걸립니다. 이것은 나에게 아주 느린 것 같습니다.

성능 번호는 살펴 보았지만 예제를 찾지 못했습니다. 하루가 끝나면이 기술로 인해 너무 많은 것을 기대하고 있습니까?

출처

2017-12-12 Andrew Benton

gremlin 엔드 포인트 인프라 스트럭처를 호스팅 한 방식을 감안할 때 gremlin 쿼리와 직접 문서 쿼리에 약간의 오버 헤드가 있어야합니다. 그러나 숫자는 우리가 기대하는 것에 조금 떨어져 보인다. [email protected]으로 연락하십시오. 우리는 도와 드리겠습니다 !! –

MS가 문제를 파악해 주셔서 감사합니다. gremlin API 끝점에서 몇 가지 문제가있었습니다. 문제를 일으키는 데이터베이스 인스턴스에서 내 인스턴스가 다른 지역의 gremlin 끝점 (MS의 메시지를 올바르게 이해하고있는 경우)을 호출했습니다.

새로운 인프라에서 새 데이터베이스를 강제 배치하기 위해 포털에서 설정할 기능 플래그가 지정되었습니다.

이제 모든 쿼리와 순회의 응답 시간이 500ms를 넘었습니다.

출처

2017-12-20 18:07:20

Cosmos DB에서 그래프 API를 사용하는 것이 (documentdb) SQL API

답변

관련 문제