그래프 데이터베이스를 사용하면 데이터 항목 및 항목 간의 관계를 모델링하여 유용한 정보를 발견할 수 있습니다. JanusGraph는 대용량 데이터를 다룰 수 있는 그래프 데이터베이스입니다. 이 튜토리얼에서는 Google Kubernetes Engine을 조정 플랫폼으로, Bigtable을 스토리지 백엔드로 사용하여 Google Cloud에서 JanusGraph를 실행하는 방법을 보여줍니다. 이 튜토리얼은 관리형 데이터베이스를 스토리지 백엔드로 사용하여 Google Cloud에서 JanusGraph 그래프 데이터베이스를 실행하는 데 관심이 있는 시스템 설계자, 데이터베이스 관리자, DevOps 전문가를 대상으로 합니다. 여기서는 사용자가 Google Kubernetes Engine(GKE), Kubernetes 포드, Helm 차트, Bigtable, Elasticsearch에 익숙하다고 가정합니다. Apache TinkerPop 그래프 컴퓨팅 프레임워크 및 Gremlin 그래프 순회 머신 및 언어에 대한 지식은 필요하지 않지만 이 튜토리얼에 제공된 예시 외에 Janusgraph를 사용하기 위한 지식이 필요합니다.
개요
그래프 관련 용어에서는 항목을 노드 또는 꼭짓점이라고 하고, 관계를 에지라고 합니다. JanusGraph에서 꼭지점과 에지에는 속성을 통해 제공되는 추가 관련 데이터가 있을 수 있습니다.
위의 이미지는 속성 그래프의 예시입니다.
그래프 데이터베이스를 사용하면 다양한 분야와 활동을 모델링할 수 있습니다.
- 소셜 네트워크
- 금융 거래(사기 분석용)
- 물리적 또는 가상 시스템 네트워크
그래프 데이터베이스를 만들 때는 경우에 따라 꼭지점과 에지 수가 수백만 내지 수십억에 이르기도 합니다. JanusGraph와 Bigtable을 내부 스토리지 계층으로 함께 사용하면 필요한 크기 및 처리량에 따라 독립적으로 빠른 쿼리(그래프 순회라고 부름)를 실행하고 스토리지 레이어를 확장할 수 있습니다. JanusGraph는 또한 플러그인 가능한 색인 생성 백엔드를 사용해서 꼭지점 및 에지 속성에 대한 전체 텍스트 색인 생성을 제공합니다. 이 튜토리얼에서는 GKE에서 확장 가능한 JanusGraph 인프라를 배포합니다. Elasticsearch를 StatefulSet의 포드에서 실행되는 색인 생성 백엔드로 사용하고 Bigtable을 스토리지 백엔드로 사용합니다. 완료되면 그래프 데이터에 존재하는 관계를 순회할 수 있습니다. 다음 다이어그램은 이러한 요소들이 어떻게 연결되는지 보여줍니다.
위의 다이어그램은 Elasticsearch 및 Bigtable을 사용하는 GKE의 JanusGraph 배포를 보여줍니다.
Bigtable의 JanusGraph 데이터
그래프 데이터는 JanusGraph에서 인접 목록으로 저장됩니다. 각 행은 꼭짓점, 인접한 꼭짓점(에지), 꼭짓점 및 에지의 속성 메타데이터를 나타냅니다. row key는 꼭짓점의 고유 식별자입니다. 꼭짓점과 다른 꼭짓점 및 관계를 추가로 정의하는 모든 속성의 각 관계는 에지 또는 에지 속성 열로 저장됩니다. 커스텀 한정자 및 열 값 모두 Bigtable 권장사항에 따라 에지를 정의하는 데이터가 저장됩니다. 각 꼭지점 속성은 개별 열로 저장되고, column qualifier 및 열 값을 사용해서 속성을 정의합니다.
다음 다이어그램은 스토리지 구조를 보여줍니다.
이 다이어그램은 두 꼭짓점 행에 대한 논리적 세부정보가 있는 작은 그래프 조각의 논리적 스토리지 구조를 보여줍니다. 다이어그램에서 두 예시 행은 두 개의 꼭짓점을 나타냅니다. 첫 번째 꼭짓점은 단일 꼭짓점 속성으로 라벨이 지정되며 별도의 에지 두 개로 다른 두 꼭짓점과 연결됩니다. 두 번째 꼭짓점에는 두 속성과 하나의 에지가 포함된 열이 있습니다.
다음 꼭짓점 에지 논리 데이터 모델의 이미지는 에지 또는 에지 속성 열의 column qualifier와 값에 대한 세부정보를 제공합니다.
각 인접한 꼭지점에 대해 열에 해당 에지에 대한 메타데이터가 저장됩니다. column qualifier에는 에지 관계 및 에지 방향에 대한 메타데이터와 인접한 꼭지점에 대한 포인터가 포함됩니다. 열 값에는 에지 라벨 및 모든 추가 에지 속성이 포함됩니다. 순회는 어느 방향으로든 진행될 수 있으므로, 에지 관계의 각 끝단에서 한 번씩 에지가 두 번 저장됩니다. 양방향 에지 스토리지는 순회 성능을 크게 늘려주지만 추가적인 저장공간의 중복성 및 비원자적 에지 변형으로 인해 몇 가지 단점이 수반됩니다.
다음 다이어그램은 꼭지점 속성 열의 논리적 데이터 모델입니다.
이전 그림은 column qualifier의 세부정보 및 에지 열의 값을 보여줍니다.
각 꼭지점 속성은 개별 열로 저장됩니다. column qualifier는 속성 키에 대한 고유 식별자입니다. 열 값에는 속성의 식별자와 속성의 값이 모두 포함됩니다.
또한 JanusGraph에서 Bigtable의 사전식 행 순서 및 column qualifier를 사용하여 쿼리 성능을 향상시킵니다.
목표
- Bigtable 인스턴스를 만듭니다.
- GKE 클러스터를 만듭니다.
- Helm을 설치합니다.
- Helm 차트를 사용하여 JanusGraph 및 Elasticsearch를 배포합니다.
- Gremlin 콘솔을 사용해서 JanusGraph에 연결합니다.
- 샘플 데이터를 로드한 후 쿼리합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Google Kubernetes Engine (GKE)
- Compute Engine VMs are provisioned by GKE
- Bigtable
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
기본 요건
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Enable the Bigtable, Compute Engine, and GKE APIs.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Enable the Bigtable, Compute Engine, and GKE APIs.
개발 환경 준비
이 가이드에서는 Cloud Shell을 사용하여 명령어를 입력합니다. Cloud Shell은 Google Cloud Console의 명령줄에 대한 액세스 권한을 제공하고 Google Cloud CLII 및 Google Cloud 개발에 필요한 기타 도구를 포함합니다. Cloud Shell은 Google Cloud console 하단에 창으로 표시됩니다. 초기화되는 데 몇 분 정도 걸릴 수 있지만 창은 즉시 표시됩니다.
-
In the Google Cloud console, activate Cloud Shell.
Cloud Shell에서 Bigtable 클러스터, GKE 클러스터와 GKE 클러스터의 이름, 노드 유형, 버전을 생성할 Compute Engine 영역의 환경 변수를 설정합니다.
export PROJECT_ID=PROJECT_ID export GCP_ZONE=REGION export GKE_CLUSTER_NAME=GKE_CLUSTER_NAME export GKE_NODE_TYPE=n1-standard-4 export GKE_VERSION=1.20
다음을 바꿉니다.
PROJECT_ID를 프로젝트 식별자로 바꿉니다.REGION을 Bigtable 클러스터 및 GKE 클러스터를 만들 영역으로 바꿉니다.GKE_CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다.
명령어가 다음 예시와 비슷하게 표시됩니다.
export PROJECT_ID=bt-janusgraph-project-id export GCP_ZONE=us-central1-f export GKE_CLUSTER_NAME=janusgraph-gke export GKE_NODE_TYPE=n1-standard-4 export GKE_VERSION=1.20
JanusGraph를 배포할 GKE 클러스터를 만듭니다.
gcloud container clusters create ${GKE_CLUSTER_NAME} \ --zone=${GCP_ZONE} \ --cluster-version=${GKE_VERSION} \ --machine-type ${GKE_NODE_TYPE} \ --scopes "https://www.googleapis.com/auth/cloud-platform"
Bigtable 인스턴스를 만듭니다.
이 가이드에서는 JanusGraph 스토리지 백엔드로 요구사항에 맞게 빠르게 확장될 수 Bigtable을 사용합니다. 이 튜토리얼에서 사용하는 단일 노드 클러스터는 경제적이며 이 튜토리얼을 진행하는 데 충분한 성능을 제공합니다. 소규모 클러스터에서 프로젝트를 시작한 후 프로덕션 데이터로 작업할 준비가 되었을 때 대규모 클러스터로 이동하면 됩니다. Bigtable 문서에는 작업에 맞춰 클러스터 크기를 선택할 수 있게 해주는 성능 및 확장 관련 정보가 포함되어 있습니다.
Cloud Shell에서 Bigtable 인스턴스 식별자의 환경 변수를 설정합니다.
export BIGTABLE_INSTANCE_ID=BIGTABLE_INSTANCE_ID
BIGTABLE_INSTANCE_ID를 Bigtable 인스턴스의 식별자로 바꿉니다.Bigtable 인스턴스를 만듭니다.
gcloud bigtable instances create ${BIGTABLE_INSTANCE_ID} \ --cluster-config=id=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE},zone=${GCP_ZONE},nodes=1 \ --display-name=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE}
Helm 설치 및 구성
Helm을 사용하여 Kubernetes 클러스터에 애플리케이션을 배포합니다. 이 튜토리얼에서는 Helm을 사용하여 GKE 클러스터에 JanusGraph 및 Elasticsearch 서비스를 배포합니다.
Cloud Shell에서 Helm을 설치합니다.
curl -fsSL -o get_helm.sh \ https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 chmod 700 get_helm.sh DESIRED_VERSION=v3.5.0 ./get_helm.shJanusGraph 차트 배포 중에 Elasticsearch 차트 종속 항목을 찾을 수 있도록
elastic차트 저장소를 추가합니다.helm repo add elastic https://helm.elastic.co
이 차트 저장소는 Elasticsearch의 제작자인 Elastic에서 호스팅됩니다.
Helm을 사용하여 JanusGraph 및 Elasticsearch 설치
이 섹션에서는 Helm 차트를 사용하여 Kubernetes 클러스터에 JanusGraph 및 Elasticsearch를 배포합니다.
GitHub에서 Helm 차트를 가져옵니다. Helm 차트 저장소에 포함된 배포는 내부 애플리케이션 부하 분산기를 시작하는 서비스 뒤에 JanusGraph 포드 세 개가 포함된 집합을 배포합니다. 포드가 실행되면 시작 및 활성 프로브가 각 포드의 JanusGraph 서버에서 상태 점검을 수행하기 위해 HTTP 요청을 수행합니다. 또한 차트에는 StatefulSet에 Elasticsearch 포드 세 개를 배포하는 Elastic에서 제공하는 종속 항목 차트가 포함되어 있습니다.
Cloud Shell에서 Helm 및 JanusGraph 이름에 대해 환경 변수를 설정합니다.
export HELM_REPO=bigtable-janusgraph-helm export JANUSGRAPH_VERSION=0.5.3 export HELM_CHART_RELEASE_VERSION=1 export HELM_CHART_RELEASE_TAG=${JANUSGRAPH_VERSION}-${HELM_CHART_RELEASE_VERSION} export HELM_CHART_RELEASE_TAG_HASH=f8b271a4854d4a553dd5e9ba014d077fb098d9ab export HELM_CHART_NAME=janusgraph-bigtableGitHub에서 Helm 차트를 가져옵니다.
git clone https://github.com/GoogleCloudPlatform/${HELM_REPO} \ --branch ${HELM_CHART_RELEASE_TAG}Helm 차트 디렉터리로 이동합니다.
cd ${HELM_REPO}보안을 위해 커밋 해시를 사용하여 확인합니다.
HEAD_COMMIT_HASH=$(git rev-parse --verify HEAD) if [ _${HEAD_COMMIT_HASH} == _${HELM_CHART_RELEASE_TAG_HASH} ] then echo "Commit hash verified" fi출력이 다음과 유사하지 않으면 클론된 태그의 무결성이 확인되지 않은 것이므로 진행하지 마세요.
Commit hash verified
차트 종속 항목을 업데이트합니다.
helm dep update
상위 디렉터리로 이동합니다.
cd ..
Helm 및 JanusGraph 항목의 이름에 대해 환경 변수를 설정합니다.
export HELM_RELEASE_NAME=janusgraph-bigtable-elastic export ELASTICSEARCH_CLUSTER_NAME=${HELM_RELEASE_NAME}-elasticsearch export BIGTABLE_JANUSGRAPH_TABLE=janusgraph-tableJanusGraph 차트를 배포할 때 사용할 구성 속성을 Helm에 제공하는
values.yaml파일을 만듭니다.cat > values.yaml << EOF image: repository: docker.io/janusgraph/janusgraph tag: 0.5.3 pullPolicy: IfNotPresent replicaCount: 3 service: type: LoadBalancer port: 8182 serviceAnnotations: networking.gke.io/load-balancer-type: "Internal" elasticsearch: deploy: true clusterName: ${ELASTICSEARCH_CLUSTER_NAME} properties: storage.backend: hbase storage.directory: null storage.hbase.ext.google.bigtable.instance.id: ${BIGTABLE_INSTANCE_ID} storage.hbase.ext.google.bigtable.project.id: ${PROJECT_ID} storage.hbase.ext.hbase.client.connection.impl: com.google.cloud.bigtable.hbase2_x.BigtableConnection storage.hbase.short-cf-names: true storage.hbase.table: ${BIGTABLE_JANUSGRAPH_TABLE} index.search.backend: elasticsearch index.search.hostname: ${ELASTICSEARCH_CLUSTER_NAME}-master index.search.directory: null index.search.elasticsearch.health-request-timeout: 90s cache.db-cache: true cache.db-cache-clean-wait: 20 cache.db-cache-time: 180000 cache.db-cache-size: 0.5 cluster.max-partitions: 1024 graph.replace-instance-if-exists: true persistence: enabled: false debugLevel: INFO EOF생성한
values.yaml파일을 사용하여 JanusGraph Helm 차트를 배포합니다.helm upgrade --install \ --wait \ --timeout 600s \ ${HELM_RELEASE_NAME} \ ./${HELM_REPO} \ -f values.yaml모든 리소스가 준비된 후에야 설치 프로세스가 완료됩니다. 이 프로세스에는 몇 분이 걸릴 수 있습니다.
JanusGraph 배포 확인
Helm 설치 프로세스가 완료되면 작업을 시작하는 방법을 설명하는 NOTES 섹션이 표시됩니다. NOTES 섹션에 설명된 단계에 따라 JanusGraph 환경이 정상적으로 작동하는지 확인하면 됩니다.
Cloud Shell에서 GKE에 배포된 Helm 차트 구성요소를 확인합니다.
JanusGraph 배포를 확인합니다.
kubectl get deployments
배포를 성공하면 다음과 같이 출력됩니다.
NAME READY UP-TO-DATE AVAILABLE AGE janusgraph-bigtable-elastic 3/3 3 3 3m28s
Elasticsearch StatefulSet를 확인합니다.
kubectl get statefulsets
모든 항목이 제대로 작동한다면 다음과 같이 출력됩니다.
NAME READY AGE janusgraph-bigtable-elastic-elasticsearch-master 3/3 4m13s
환경 변수를 JanusGraph Gremlin 서버를 실행하는 Kubernetes 포드의 이름으로 설정합니다. Gremlin 서버를 실행하는 포드의
app라벨은Chart.yaml파일에 정의된 Helm 차트 이름에서 파생됩니다.export APP_LABEL_FROM_CHART_NAME=${HELM_CHART_NAME} export POD_NAME=$(kubectl get pods \ --namespace default \ -l "app=${APP_LABEL_FROM_CHART_NAME}, \ release=${HELM_RELEASE_NAME}" \ -o jsonpath="{.items[0].metadata.name}")포드에 연결하고 REPL(read-eval-print-loop) 셸인 Gremlin 콘솔을 실행합니다. 컨테이너의 이름도
Chart.yaml의 Helm 차트 이름에서 파생됩니다.export GREMLIN_CONTAINER=${HELM_CHART_NAME} kubectl exec \ -c ${GREMLIN_CONTAINER} \ -it $POD_NAME \ -- /opt/janusgraph/bin/gremlin.shGremlin 콘솔에서 Apache TinkerPop 서버에 연결합니다.
세션을 시작합니다.
:remote connect tinkerpop.server conf/remote.yaml session
결과는 다음과 유사합니다.
==>Configured localhost/127.0.0.1:8182-[b08972f2-a2aa-4312-8018-bcd11bc9812c]
서버에 연결합니다.
:remote console
결과는 다음과 유사합니다.
==>All scripts will now be sent to Gremlin Server - [localhost/127.0.0.1:8182]-[b08972f2-a2aa-4312-8018-bcd11bc9812c] - type ':remote console' to return to local mode>
Gremlin 콘솔에서 그래프 인스턴스를 나타내는
graph변수를 검사하여 Gremlin 서버가 올바르게 실행되고 있는지 확인합니다.graph
이 출력에서는 JanusGraph 서버가 HBase 호환 데이터베이스(이 경우 Bigtable)에서 스토리지 백엔드로 실행 중임을 나타냅니다.
==>standardjanusgraph[hbase:[127.0.0.1]]
Gremlin에서 두 개의 꼭짓점을 만듭니다.
v1 = graph.addVertex(label, 'hello') v2 = graph.addVertex(label, 'world')
콘솔 출력이 다음과 비슷하면 두 꼭짓점이 추가된 것입니다.
==>v[4344] ==>v[4152]
두 꼭지점을 연결하는 에지를 만듭니다.
v1.addEdge('followedBy', v2)콘솔 출력이 다음과 유사하면 두 꼭짓점 사이의 에지가 추가되었음을 나타냅니다.
==>e[17j-3co-4fmd-oe054][4344-followedBy->4152]
트랜잭션을 커밋합니다.
graph.tx().commit()
콘솔 출력이
null이면 작업이 커밋되었다는 의미입니다.==>null
다음 다이어그램은 명령어로 생성된 그래프를 보여줍니다.
hello라벨이 지정된 꼭짓점은followedBy라벨이 지정된 방향성 에지를 통해world라는 꼭짓점에 연결됩니다.다음 Gremlin 쿼리를 실행하여 라벨이
hello인 꼭짓점에서followedBy에지를 따라가면 나오는 꼭짓점의 라벨을 확인합니다.g.V().has(label, 'hello').out('followedBy').label()쿼리 구문은 다음 섹션에서 설명합니다. 지금은 쿼리 출력으로
world라는 단어가 표시됩니다.==>world
샘플 데이터 세트 로드 및 쿼리
이제 JanusGraph가 배포되었고 Gremlin을 통해 연결이 가능하므로 자체 데이터를 로드하고 쿼리할 수 있습니다. 이 과정을 설명하고자 JanusGraph에 함께 포함된 샘플 데이터 세트인 Graph of the Gods를 로드합니다. 이 그래프는 로마 신화 속의 신들과 장소 속성을 묘사합니다.
Gremlin에서 이전에 만든 그래프를 로드합니다.
GraphOfTheGodsFactory.load(graph)
출력은 다음과 같습니다.
==>null
Jupiter의 형제를 모두 찾는 그래프 순회 쿼리를 실행합니다.
g.V().has('name', 'jupiter').out('brother').values('name')다음 표에서는 쿼리가 순회되는 단계를 설명합니다.
출력은 다음과 같습니다.순회 탐색 단계 설명 g.V()꼭지점 컬렉션에서 시작합니다. has('name', 'jupiter')name속성의 값이jupiter인 항목을 찾습니다.out('brother')여기에서 출발하여 라벨이 brother인 에지를 모두 따라갑니다.values('name')해당 에지를 따라가면 나오는 꼭지점의 name속성을 가져옵니다.==>neptune ==>pluto
이 신들의 그래프 데이터세트에서 실행 가능한 순회 탐색 쿼리에 더 익숙해지고 싶다면 JanusGraph 문서의 다른 샘플 쿼리를 사용해 보세요.
Bigtable에 저장된 데이터 확인
이제 JanusGraph 클러스터에서 일부 샘플 데이터를 만들었으므로, Bigtable이 스토리지 백엔드로 사용되었는지 확인할 수 있습니다.
Gremlin 콘솔을 닫습니다.
:q
Cloud Shell에서 Bigtable의
janusgraph테이블에 데이터가 유지되었는지 확인합니다.cbt -project=${PROJECT_ID} \ -instance=${BIGTABLE_INSTANCE_ID} \ count ${BIGTABLE_JANUSGRAPH_TABLE}출력은 다음과 비슷합니다.
2021/03/02 02:32:19 -creds flag unset, will use gcloud credential 101
출력에서
101값은janusgraph table의 행 수를 나타내며, 경우에 따라 다를 수 있습니다.
Elasticsearch의 검색 색인 생성 확인
Cloud Shell에서 Elasticsearch 포드 색인 및 이름의 변수를 설정합니다.
export ELASTICSEARCH_POD_ORDINAL=0 export ELASTICSEARCH_POD_NAME_ROOT=${ELASTICSEARCH_CLUSTER_NAME}-master export ELASTICSEARCH_POD=${ELASTICSEARCH_POD_NAME_ROOT}-0Elasticsearch 포드의 이름은 Elasticsearch Helm 종속 항목으로 정의됩니다. 포드 이름은 사용자가 만든
values.yaml파일에 제공된 클러스터 이름, 단어master, 0 색인 서수로 구성되며 모두 하이픈으로 구분됩니다. 이 단계에서는 0으로 표시되는 첫 번째 포드를 선택합니다.Elasticsearch 별칭 REST API를 사용해서 색인을 조사합니다.
kubectl exec \ -c elasticsearch \ -it ${ELASTICSEARCH_POD} \ -- \ curl -XGET "127.0.0.1:9200/_aliases?pretty=true";꼭짓점 및 에지 속성을 사용하여 효율적인 조회를 제공하기 위해 JanusGraph에서 생성된 2개의 색인,
janusgraph_vertices및janusgraph_edges가 출력에 표시됩니다.{ "janusgraph_vertices" : { "aliases" : { "janusgraph" : { } } }, "janusgraph_edges" : { "aliases" : { "janusgraph" : { } } } }Elasticsearch 검색 REST API를 사용하여 색인 중 하나에서 값을 쿼리합니다.
kubectl exec \ -c elasticsearch \ -it ${ELASTICSEARCH_POD} \ -- \ curl -XGET "127.0.0.1:9200/janusgraph_edges/_search?pretty=true&q=*";검색결과에서 JanusGraph가 만든 색인에 항목이 있음을 보여줍니다.
janusgraph_edges색인에 항목이 있음을 나타내는 다음과 같이 잘린 결과와 유사한 출력이 표시됩니다.{ "took" : 94, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 6, "relation" : "eq" }, "max_score" : 1.0, "hits" : [ { "_index" : "janusgraph_edges", "_type" : "_doc", "_id" : "6bvp-5ovc-b2t-2yko", "_score" : 1.0, "_source" : { "reason" : "loves waves" } }, { …
프로젝트 삭제
이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트는 유지하되 개별 리소스를 삭제하세요.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
다음 단계
- JanusGraph 및 그래프 데이터베이스 자세히 알아보기
- Apache TinkerPop 그래프 컴퓨팅 프레임워크에 대해 자세히 알아보기 및 Gremlin 그래프 순회 언어 탐색하기
- JanusGraph에서 Bigtable에 데이터를 저장하는 방법 자세히 알아보기
- JanusGraph 예시 애플리케이션을 배포하여 그래프 사용 사례 자세히 알아보기