NoSQL용 데이터 모델 설계의 특징

소개

“그 자리에 머물려면 최대한 빨리 달려야 해요.
그리고 어딘가에 가려면 최소한 두 배는 더 빨리 달려야 해요!”
(c) 이상한 나라의 앨리스

얼마 전 강의를 해달라고 부탁을 받았습니다. 분석가 우리 회사는 데이터 모델 설계 주제에 대해 오랫동안(때로는 몇 년 동안) 프로젝트에 참여했기 때문에 IT 기술 세계에서 우리 주변에서 무슨 일이 일어나고 있는지 놓치기 때문입니다. 우리 회사에서는(그런 일이 일어났습니다) 많은 프로젝트가 NoSQL 데이터베이스를 사용하지 않습니다(적어도 지금은). 그래서 저는 강의에서 HBase의 예를 사용하여 별도로 주의를 기울이고 자료의 프레젠테이션 방향을 그쪽으로 맞추려고 노력했습니다. 한 번도 사용해 본 적이 없는 사람은 효과가 있었습니다. 특히 몇 년 전에 읽은 예제를 사용하여 데이터 모델 설계의 일부 기능을 설명했습니다. Amandeep Khurana의 "HB ase 스키마 디자인 소개" 기사에서. 예제를 분석할 때 청중에게 주요 아이디어를 더 잘 전달하기 위해 동일한 문제를 해결하기 위한 여러 옵션을 비교했습니다.

최근에 나는 "할 일이 없어서"(격리 기간이 긴 XNUMX월 주말이 특히 도움이 됨) 스스로에게 질문했습니다. 이론적 계산이 실제와 얼마나 일치할까요? 사실 이 글의 아이디어는 이렇게 탄생했다. 며칠 동안 NoSQL을 사용해 온 개발자는 NoSQL에서 새로운 것을 배우지 못할 수도 있습니다(따라서 기사의 절반을 즉시 건너뛸 수도 있습니다). 이 아니라면 분석가아직 NoSQL을 다루지 않은 분들에게는 HBase의 데이터 모델 설계 기능에 대한 기본적인 이해를 얻는 데 도움이 될 것이라고 생각합니다.

예시 분석

제 생각에는 NoSQL 데이터베이스를 사용하기 전에 신중하게 생각하고 장단점을 따져볼 필요가 있습니다. 종종 문제는 전통적인 관계형 DBMS를 사용하여 해결될 가능성이 높습니다. 따라서 특별한 이유 없이는 NoSQL을 사용하지 않는 것이 좋습니다. 그럼에도 불구하고 NoSQL 데이터베이스를 사용하기로 결정했다면 여기에서의 설계 접근 방식이 다소 다르다는 점을 고려해야 합니다. 특히 이전에 관계형 DBMS만 다루었던 사람들에게는 그 중 일부가 특이할 수 있습니다(내 관찰에 따르면). 따라서 "관계형" 세계에서는 일반적으로 문제 영역 모델링부터 시작하고 필요한 경우 모델을 비정규화합니다. NoSQL에서는 우리는 데이터 작업에 대해 예상되는 시나리오를 즉시 고려해야 합니다. 처음에는 데이터를 비정규화합니다. 또한 아래에서 설명할 여러 가지 다른 차이점이 있습니다.

계속해서 연구할 다음과 같은 "합성" 문제를 고려해 보겠습니다.

일부 추상적인 소셜 네트워크 사용자의 친구 목록에 대한 저장 구조를 설계해야 합니다. 단순화하기 위해 우리는 모든 연결이 (Linkedin이 아닌 Instagram에서와 같이) 방향이 지정되어 있다고 가정합니다. 구조를 통해 다음을 효과적으로 수행할 수 있어야 합니다.

• 사용자 A가 사용자 B를 읽는지 여부에 대한 질문에 답하십시오(읽기 패턴).
• 사용자 B에서 사용자 A를 구독/탈퇴하는 경우 연결 추가/제거 허용(데이터 변경 템플릿)

물론 문제를 해결하기 위한 다양한 옵션이 있습니다. 일반 관계형 데이터베이스에서 우리는 단순히 관계 테이블을 만들고(예를 들어 이 "친구"를 포함하는 가족, 직장 등의 사용자 그룹을 저장해야 하는 경우 일반적으로 사용 가능) 테이블을 만들고 최적화할 것입니다. 액세스 속도는 인덱스/파티셔닝을 추가합니다. 아마도 최종 테이블은 다음과 같을 것입니다.

USER_ID
친구 아이디

Vasya
페티

Vasya
Оля

이하에서는 이해를 돕기 위해 아이디 대신 이름을 표기하겠습니다.

HBase의 경우 다음을 알고 있습니다.

• Full Table Scan이 아닌 효율적인 검색이 가능 키로만 독점적으로
  • 사실, 이것이 바로 많은 사람들에게 친숙한 SQL 쿼리를 그러한 데이터베이스에 작성하는 것이 나쁜 생각인 이유입니다. 물론 기술적으로는 동일한 Impala에서 조인 및 기타 로직이 포함된 SQL 쿼리를 HBase로 보낼 수 있지만 얼마나 효과적일까요?

따라서 사용자 ID를 키로 사용해야 합니다. 그리고 "친구 ID를 어디에 어떻게 저장해야 할까요?"라는 주제에 대한 첫 번째 생각은 다음과 같습니다. 어쩌면 열에 저장하는 아이디어일 수도 있습니다. 가장 분명하고 "순진한" 옵션은 다음과 같습니다. 옵션 1(기본값)추가 참조용):

RowKey
연사

Vasya
1: 페트야
2: 올리야
3: 다샤

페티
1: 마샤
2: 바샤

여기서 각 라인은 한 명의 네트워크 사용자에 해당합니다. 열에는 이름이 있습니다: 1, 2, ... - 친구 수에 따라 친구의 ID가 열에 저장됩니다. 각 행에는 서로 다른 열 수가 있다는 점에 유의하는 것이 중요합니다. 위 그림의 예에서 한 행에는 1개의 열(2, 3, 1)이 있고 두 번째 행에는 2개의 열(XNUMX과 XNUMX)만 있습니다. 여기서 우리는 관계형 데이터베이스에 없는 두 개의 HBase 속성을 사용했습니다.

• 열 구성을 동적으로 변경하는 기능(친구 추가 -> 열 추가, 친구 제거 -> 열 삭제)
• 행마다 열 구성이 다를 수 있습니다.

작업 요구 사항을 준수하는지 구조를 확인해 보겠습니다.

• 데이터 읽기: Vasya가 Olya를 구독하는지 확인하려면 다음을 빼야 합니다. 전체 라인 RowKey = "Vasya" 키를 사용하여 Olya를 "만날" 때까지 열 값을 정렬합니다. 또는 Olya를 "충족하지 않음"으로 모든 열의 값을 반복하고 False를 반환합니다.
• 데이터 편집: 친구 추가: 비슷한 작업의 경우 빼기도 필요합니다. 전체 라인 RowKey = "Vasya" 키를 사용하여 친구의 총 수를 계산합니다. 새 친구의 ID를 적어야 하는 열의 수를 결정하려면 이 총 친구 수가 필요합니다.
• 데이터 변경: 친구 삭제:
  • 빼야함 전체 라인 RowKey = "Vasya" 키를 사용하여 삭제할 친구가 기록된 열을 찾기 위해 열을 정렬합니다.
  • 다음으로 친구를 삭제한 후 번호 매기기에 "간격"이 생기지 않도록 모든 데이터를 하나의 열로 "이동"해야 합니다.

이제 "조건부 적용" 측면에서 구현해야 하는 이러한 알고리즘이 얼마나 생산적인지 평가해 보겠습니다. O-상징. 가상의 소셜 네트워크의 크기를 n으로 표시해 보겠습니다. 그러면 한 사용자가 가질 수 있는 최대 친구 수는 (n-1)입니다. O 기호 사용의 틀 내에서는 중요하지 않기 때문에 우리의 목적에 따라 이 (-1)을 무시할 수 있습니다.

• 데이터 읽기: 전체 줄을 빼고 한도 내에서 모든 열을 반복해야 합니다. 이는 비용의 상한 추정치가 대략 O(n)이 됨을 의미합니다.
• 데이터 편집: 친구 추가: 친구 수를 결정하려면 행의 모든 ​​열을 반복한 다음 새 열을 삽입해야 합니다. => O(n)
• 데이터 변경: 친구 삭제:
  • 추가와 유사 - 제한의 모든 열을 통과해야 함 => O(n)
  • 열을 제거한 후에는 "이동"해야 합니다. 이 "정면"을 구현하는 경우 한도 내에서 최대 (n-1)개의 작업이 필요합니다. 그러나 여기와 실제 부분에서는 고정된 수의 작업에 대해 "의사 시프트"를 구현하는 다른 접근 방식을 사용할 것입니다. 즉, n에 관계없이 일정한 시간이 소요됩니다. 이 상수 시간(정확히는 O(2))은 O(n)에 비해 무시될 수 있습니다. 접근 방식은 아래 그림에 설명되어 있습니다. "마지막" 열의 데이터를 삭제하려는 열에 복사한 다음 마지막 열을 삭제하기만 하면 됩니다.
    

전체적으로 모든 시나리오에서 우리는 O(n)의 점근적 계산 복잡성을 받았습니다.
아마도 우리는 거의 항상 데이터베이스에서 전체 행을 읽어야 하며, XNUMX개 중 XNUMX개의 경우에는 모든 열을 살펴보고 총 친구 수를 계산해야 한다는 것을 이미 알고 계실 것입니다. 따라서 최적화를 시도하기 위해 각 네트워크 사용자의 총 친구 수를 저장하는 "count" 열을 추가할 수 있습니다. 이 경우, 총 친구 수를 계산하기 위해 전체 행을 읽을 수는 없지만 "count" 열은 하나만 읽을 수 있습니다. 가장 중요한 것은 데이터를 조작할 때 "카운트"를 업데이트하는 것을 잊지 않는 것입니다. 저것. 우리는 향상된다 옵션 2(개수):

RowKey
연사

Vasya
1: 페트야
2: 올리야
3: 다샤
카운트: 3

페티
1: 마샤
2: 바샤

카운트: 2

첫 번째 옵션과 비교하면 다음과 같습니다.

• 데이터 읽기: "Vasya가 Olya를 읽나요?"라는 질문에 대한 답변을 얻으려면 아무것도 변하지 않았습니다 => O(n)
• 데이터 편집: 친구 추가: 이제 전체 행을 읽고 해당 열을 반복할 필요가 없고 "count" 열의 값만 가져올 수 있으므로 새 친구 삽입을 단순화했습니다. 새 친구를 삽입할 열 번호를 즉시 결정하세요. 이로 인해 계산 복잡성이 O(1)로 감소됩니다.
• 데이터 변경: 친구 삭제: 친구를 삭제할 때 이 열을 사용하여 데이터를 한 셀 왼쪽으로 "이동"할 때 I/O 작업 수를 줄일 수도 있습니다. 그러나 삭제해야 할 열을 찾기 위해 열을 반복해야 하는 필요성은 여전히 ​​남아 있으므로 => ​​O(n)
• 반면에 이제 데이터를 업데이트할 때마다 "count" 열을 업데이트해야 하지만 이는 일정한 시간이 걸리므로 O 기호 프레임워크 내에서는 무시될 수 있습니다.

일반적으로 옵션 2가 조금 더 최적으로 보이지만 “혁명보다는 진화”에 가깝습니다. "혁명"을 이루기 위해서는 우리가 필요로 할 것이다 옵션 3(열).
모든 것을 "거꾸로"돌리자: 우리는 지정하겠습니다 열 이름 사용자 ID! 열 자체에 기록될 내용은 더 이상 중요하지 않습니다. 숫자 1로 두십시오(일반적으로 "가족/친구/기타" 그룹과 같이 유용한 항목이 여기에 저장될 수 있습니다). 이 접근 방식은 이전에 NoSQL 데이터베이스 작업 경험이 없는 준비되지 않은 "일반인"을 놀라게 할 수 있지만, 이 작업에서 HBase의 잠재력을 훨씬 더 효과적으로 사용할 수 있는 것은 바로 이 접근 방식입니다.

RowKey
연사

Vasya
페티아: 1
올리야: 1
다샤: 1

페티
마샤 : 1
바샤: 1

여기서 우리는 한 번에 여러 가지 이점을 얻습니다. 이를 이해하기 위해 새로운 구조를 분석하고 계산 복잡성을 추정해 보겠습니다.

• 데이터 읽기: Vasya가 Olya를 구독하는지 여부에 대한 질문에 답하려면 "Olya" 열 하나를 읽는 것으로 충분합니다. 해당 열이 있으면 대답은 True이고, 그렇지 않으면 – False => O(1)입니다.
• 데이터 편집: 친구 추가: 친구 추가: "친구 ID" 열을 새로 추가하면 됩니다 => O(1)
• 데이터 변경: 친구 삭제: 친구 ID 열만 삭제 => O(1)

보시다시피 이 스토리지 모델의 중요한 장점은 필요한 모든 시나리오에서 하나의 열만 사용하여 데이터베이스에서 전체 행을 읽지 않고 이 행의 모든 ​​열을 열거하지 않는다는 것입니다. 여기서 멈출 수도 있지만...

데이터베이스에 액세스할 때 성능을 최적화하고 I/O 작업을 줄이는 경로를 따라 조금 더 나아갈 수 있습니다. 전체 관계 정보를 row key 자체에 직접 저장하면 어떻게 될까요? 즉, userID.friendID와 같은 키 합성을 만드시겠습니까? 이 경우에는 줄의 열을 전혀 읽을 필요조차 없습니다(옵션 4(행)):

RowKey
연사

바샤.페트야
페티아: 1

바샤.올리야
올리야: 1

바샤.다샤
다샤: 1

페트야.마샤
마샤 : 1

페트야.바샤
바샤: 1

분명히 이전 버전에서와 같이 이러한 구조에서 모든 데이터 조작 시나리오의 평가는 O(1)이 될 것입니다. 옵션 3과의 차이점은 데이터베이스의 I/O 작업 효율성에만 있습니다.

글쎄, 마지막 "활". 옵션 4에서는 행 키의 길이가 가변적이어서 성능에 영향을 미칠 수 있다는 점을 쉽게 알 수 있습니다(여기서 HBase는 데이터를 바이트 집합으로 저장하고 테이블의 행은 키별로 정렬된다는 점을 기억합니다). 또한 일부 시나리오에서는 처리해야 할 수 있는 구분 기호도 있습니다. 이러한 영향을 제거하기 위해 userID 및 friendID의 해시를 사용할 수 있으며, 두 해시 모두 일정한 길이를 가지므로 구분 기호 없이 간단히 연결하면 됩니다. 그러면 테이블의 데이터는 다음과 같습니다(옵션 5(해시)):

RowKey
연사

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
페티아: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
올리야: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
다샤: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
마샤 : 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
바샤: 1

분명히 우리가 고려하고 있는 시나리오에서 이러한 구조로 작업하는 알고리즘의 복잡성은 옵션 4, 즉 O(1)과 ​​동일할 것입니다.
전체적으로 계산 복잡성에 대한 모든 추정치를 하나의 표에 요약해 보겠습니다.

친구 추가
친구 확인 중
친구 삭제

옵션 1(기본값)
O (N)
O (N)
O (N)

옵션 2(개수)
O (1)
O (N)
O (N)

옵션 3(열)
O (1)
O (1)
O (1)

옵션 4(행)
O (1)
O (1)
O (1)

옵션 5(해시)
O (1)
O (1)
O (1)

보시다시피 옵션 3-5가 가장 선호되는 것으로 보이며 이론적으로 필요한 모든 데이터 조작 시나리오를 일정한 시간에 실행하도록 보장합니다. 우리 작업 조건에서는 모든 사용자의 친구 목록을 얻어야 한다는 명시적인 요구 사항이 없지만 실제 프로젝트 활동에서는 훌륭한 분석가로서 그러한 작업이 발생할 수 있다고 "예측"하는 것이 좋습니다. “빨대를 펴세요.” 따라서 저는 옵션 3에 공감합니다. 그러나 실제 프로젝트에서 이 요청은 이미 다른 방법으로 해결되었을 가능성이 높으므로 전체 문제에 대한 일반적인 비전이 없으면 만들지 않는 것이 좋습니다. 최종 결론.

실험 준비

나는 위의 이론적 주장을 실제로 테스트하고 싶습니다. 이것이 긴 주말 동안 발생한 아이디어의 목표였습니다. 이를 위해서는 데이터베이스 사용에 대해 설명된 모든 시나리오에서 "조건부 애플리케이션"의 작동 속도와 소셜 네트워크 규모(n)의 증가에 따른 시간 증가를 평가해야 합니다. 우리가 관심을 갖고 실험 중에 측정할 대상 매개변수는 하나의 "비즈니스 작업"을 수행하기 위해 "조건부 적용"이 소비한 시간입니다. "사업 거래"란 다음 중 하나를 의미합니다.

• 새 친구 한명 추가
• 사용자 A가 사용자 B의 친구인지 확인
• 친구 XNUMX명 삭제

따라서 초기 설명에 설명된 요구 사항을 고려하면 검증 시나리오는 다음과 같이 나타납니다.

• 데이터 기록. 크기 n의 초기 네트워크를 무작위로 생성합니다. "현실 세계"에 더 가까워지기 위해 각 사용자가 가지고 있는 친구의 수도 임의 변수입니다. "조건부 애플리케이션"이 생성된 모든 데이터를 HBase에 쓰는 시간을 측정합니다. 그런 다음 결과 시간을 추가된 총 친구 수로 나눕니다. 이것이 하나의 "비즈니스 운영"에 대한 평균 시간을 구하는 방법입니다.
• 데이터 읽기. 각 사용자에 대해 사용자가 구독하는지 여부에 대한 답변을 얻어야 하는 "성격" 목록을 만듭니다. 목록의 길이는 대략 사용자의 친구 수이며, 체크된 친구 중 절반은 "예"로 대답하고 나머지 절반은 "아니요"로 대답해야 합니다. 확인은 "예"와 "아니요"가 번갈아 나타나는 순서로 수행됩니다(즉, 두 번째 경우마다 옵션 1과 2에 대한 줄의 모든 열을 통과해야 합니다). 그런 다음 총 상영 시간을 테스트된 친구 수로 나누어 과목당 평균 상영 시간을 얻습니다.
• 데이터 삭제. 사용자에게서 모든 친구를 제거합니다. 게다가 삭제 순서는 무작위입니다. 즉, 데이터를 기록하는 데 사용된 원래 목록을 "섞습니다". 그런 다음 총 확인 시간을 제거된 친구 수로 나누어 확인당 평균 시간을 구합니다.

5가지 데이터 모델 옵션 각각과 소셜 네트워크의 다양한 크기에 대해 시나리오를 실행하여 시간이 성장함에 따라 어떻게 변화하는지 확인해야 합니다. 물론 하나의 n 내에서 네트워크 연결과 확인할 사용자 목록은 5가지 옵션 모두에서 동일해야 합니다.
더 나은 이해를 위해 다음은 n= 5에 대해 생성된 데이터의 예입니다. 작성된 "생성기"는 세 개의 ID 사전을 출력으로 생성합니다.

• 첫 번째는 삽입용입니다.
• 두 번째는 확인을 위한 것입니다.
• 세 번째 – 삭제용

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

보시다시피, 확인을 위해 사전에 있는 10보다 큰 모든 ID는 확실히 False라는 대답을 제공하는 ID입니다. '친구' 추가, 확인, 삭제는 사전에 명시된 순서대로 정확하게 수행됩니다.

실험은 Windows 10을 실행하는 노트북에서 수행되었습니다. 여기서 HBase는 하나의 Docker 컨테이너에서 실행되고 Python과 Jupyter Notebook은 다른 컨테이너에서 실행되었습니다. Docker에는 2개의 CPU 코어와 2GB의 RAM이 할당되었습니다. 테스트 데이터 생성 및 시간 측정을 위한 "조건부 애플리케이션" 및 "파이핑" 에뮬레이션과 같은 모든 로직은 Python으로 작성되었습니다. 라이브러리는 HBase 작업에 사용되었습니다. 해피베이스, 옵션 5에 대한 해시(MD5) 계산 - hashlib

특정 노트북의 컴퓨팅 성능을 고려하여 n = 10, 30, …에 대한 출시가 실험적으로 선택되었습니다. 170 - 전체 테스트 주기(모든 n에 대한 모든 옵션에 대한 모든 시나리오)의 총 작동 시간이 훨씬 더 합리적이고 한 번의 다과회 동안 적합했던 경우(평균 15분).

여기서는 이 실험에서 절대적인 성능 수치를 주로 평가하는 것이 아니라는 점을 언급할 필요가 있습니다. 서로 다른 두 가지 옵션을 상대적으로 비교하는 것조차 완전히 정확하지 않을 수 있습니다. 이제 우리는 n에 따른 시간 변화의 성격에 관심이 있습니다. 위의 "테스트 스탠드" 구성을 고려하면 무작위 및 기타 요인의 영향이 "제거된" 시간 추정치를 얻는 것이 매우 어렵습니다( 그러한 작업은 설정되지 않았습니다).

실험결과

첫 번째 테스트는 친구 목록을 작성하는 데 소요되는 시간이 어떻게 변하는가입니다. 그 결과는 아래 그래프에 나와 있습니다.

예상대로 옵션 3-5는 네트워크 크기의 증가와 구별할 수 없는 성능 차이에 의존하지 않는 거의 일정한 "비즈니스 트랜잭션" 시간을 보여줍니다.
옵션 2도 일정하지만 약간 더 나쁜 성능을 보여줍니다. 옵션 2-3에 비해 거의 정확히 5배입니다. 그리고 이는 이론과 관련이 있기 때문에 기뻐할 수밖에 없습니다. 이 버전에서는 HBase와의 I/O 작업 수가 정확히 2배 더 많습니다. 이는 원칙적으로 테스트 벤치가 우수한 정확성을 제공한다는 간접적인 증거가 될 수 있습니다.
또한 예상한 대로 옵션 1은 가장 느린 것으로 밝혀졌으며 네트워크 크기에 서로를 추가하는 데 소요되는 시간이 선형적으로 증가하는 것을 보여줍니다.
이제 두 번째 테스트 결과를 살펴보겠습니다.

옵션 3-5는 다시 예상대로 작동합니다. 즉, 네트워크 크기에 관계없이 일정한 시간입니다. 옵션 1과 2는 네트워크 크기가 증가함에 따라 시간이 선형적으로 증가하고 유사한 성능을 보여줍니다. 더욱이, 옵션 2는 조금 더 느린 것으로 나타났습니다. 이는 분명히 추가 "카운트" 열을 교정하고 처리해야 하기 때문이며, 이는 n이 성장함에 따라 더욱 눈에 띄게 됩니다. 하지만 이 비교의 정확성은 상대적으로 낮기 때문에 결론을 내리지는 않겠습니다. 또한 이러한 비율(옵션 1 또는 2가 더 빠름)은 실행마다 변경되었습니다(의존성 및 "상대방"의 특성을 유지하면서).

자, 마지막 그래프는 제거 테스트 결과입니다.

이번에도 놀랄 일이 아닙니다. 옵션 3~5는 일정한 시간에 제거를 수행합니다.
더욱이 흥미롭게도 옵션 4와 5는 이전 시나리오와 달리 옵션 3에 비해 눈에 띄게 약간 나쁜 성능을 보여줍니다. 분명히 행 삭제 작업은 일반적으로 논리적인 열 삭제 작업보다 비용이 더 많이 듭니다.

예상대로 옵션 1과 2는 시간이 선형적으로 증가하는 것을 보여줍니다. 동시에 옵션 2는 카운트 열을 "유지"하기 위한 추가 I/O 작업으로 인해 옵션 1보다 지속적으로 느립니다.

실험의 일반적인 결론:

• 옵션 3-5는 HBase를 활용하므로 더 높은 효율성을 보여줍니다. 또한 성능은 상수에 따라 서로 다르며 네트워크 크기에 의존하지 않습니다.
• 옵션 4와 5의 차이는 기록되지 않았습니다. 하지만 이것이 옵션 5를 사용해서는 안 된다는 의미는 아닙니다. 테스트 벤치의 성능 특성을 고려하여 사용된 실험 시나리오에서는 이를 감지할 수 없었을 가능성이 높습니다.
• 데이터를 사용하여 "비즈니스 운영"을 수행하는 데 필요한 시간 증가의 특성은 일반적으로 모든 옵션에 대해 이전에 얻은 이론적 계산을 확인했습니다.

커튼콜

수행된 대략적인 실험을 절대적인 진실로 받아들여서는 안 됩니다. 고려되지 않고 결과를 왜곡하는 요인이 많이 있습니다(이러한 변동은 특히 네트워크 크기가 작은 그래프에서 볼 수 있습니다). 예를 들어, happybase에서 사용하는 절약의 속도, 내가 Python으로 작성한 논리를 구현하는 양과 방법(코드가 최적으로 작성되었고 모든 구성 요소의 기능을 효과적으로 사용했다고는 말할 수 없습니다), 아마도 HBase 캐싱 기능, 내 노트북에서 Windows 10의 백그라운드 활동 등 일반적으로 우리는 모든 이론적 계산이 실험적으로 그 타당성을 입증했다고 가정할 수 있습니다. 글쎄, 아니면 적어도 그러한 "정면 공격"으로 그들을 반박하는 것은 불가능했습니다.

결론적으로, HBase에서 데이터 모델을 설계하기 시작한 모든 사람을 위한 권장 사항은 이전의 관계형 데이터베이스 작업 경험을 요약하고 "계명"을 기억하는 것입니다.

• 설계할 때 우리는 도메인 모델이 아닌 데이터 조작의 작업과 패턴을 바탕으로 진행합니다.
• 효율적인 액세스(전체 테이블 스캔 없음) – 키로만 가능
• 비정규화
• 서로 다른 행에는 서로 다른 열이 포함될 수 있습니다.
• 스피커의 동적 구성

출처 : habr.com