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

소개

“당신은 그 자리에 머물기 위해 가능한 한 빨리 달려야 합니다.
그리고 어딘가에 도착하려면 적어도 두 배는 빨리 달려야 해요!"
(c) 이상한 나라의 앨리스

얼마 전 강의를 해달라는 요청을 받았습니다. 분석가들 저희 회사에서는 데이터 모델 설계라는 주제에 대해 이야기했습니다. 오랜 시간 (때로는 몇 년씩) 프로젝트에 몰두하다 보면 IT 기술 세계에서 어떤 일이 벌어지고 있는지 제대로 파악하지 못하기 때문입니다. 저희 회사에서는 (마침내 그렇게 되었네요) 많은 프로젝트에서 NoSQL 데이터베이스를 사용하지 않습니다 (적어도 아직은). 그래서 저는 강의에서 HBase를 예로 들어 NoSQL 데이터베이스에 특히 집중했고, NoSQL을 사용해 본 적이 없는 분들을 위해 강의 내용을 집중적으로 전달하려고 노력했습니다. 특히 몇 년 전에 읽었던 사례를 활용하여 데이터 모델 설계의 몇 가지 특징을 설명했습니다. Amandeep Khurana의 "HB ase 스키마 설계 소개" 기사에서예를 분석할 때, 저는 같은 문제에 대한 여러 가지 해결책을 비교하여 청중에게 주요 아이디어를 더 잘 전달하고자 했습니다.

최근 "지루해서" (5월의 긴 격리 기간이 특히나 이런 상황에 도움이 됩니다) 스스로에게 물었습니다. 이론적 계산이 실제 상황에 얼마나 부합할 수 있을까요? 사실, 이 글의 아이디어는 바로 이렇게 탄생했습니다. 오랫동안 NoSQL을 사용해 온 개발자라면 NoSQL에서 새로운 것을 배우지 못할 수도 있습니다(따라서 글의 절반은 바로 건너뛸 수도 있습니다). 하지만 분석가아직 NoSQL을 긴밀하게 다루어 본 적이 없는 사람들에게는 HBase를 위한 데이터 모델을 설계하는 데 필요한 기본적인 사항을 이해하는 데 유용할 것이라고 생각합니다.

예시 분석

제 생각에는 NoSQL 데이터베이스를 사용하기 전에 장단점을 신중하게 고려해야 합니다. 대부분의 경우 기존 관계형 DBMS를 사용하여 문제를 해결할 수 있습니다. 따라서 특별한 이유가 없다면 NoSQL을 사용하지 않는 것이 좋습니다. 그래도 NoSQL 데이터베이스를 사용하기로 결정했다면, NoSQL의 설계 방식이 다소 다르다는 점을 고려해야 합니다. 특히 이전에 관계형 DBMS만 사용해 본 사람들에게는 일부 방식이 생소하게 느껴질 수 있습니다(제 경험에 따르면). 따라서 "관계형" 환경에서는 일반적으로 주제 영역을 모델링하는 것부터 시작하여, 필요한 경우에만 모델을 비정규화합니다. NoSQL에서는 데이터 작업에 대한 예상 시나리오를 즉시 고려해야 합니다. 그리고 처음에는 데이터를 비정규화합니다. 이 외에도 여러 가지 차이점이 있으며, 아래에서 설명하겠습니다.

우리가 계속해서 연구할 다음의 "합성" 문제를 고려해 보겠습니다.

어떤 추상적인 소셜 네트워크 사용자의 친구 목록을 저장하는 구조를 설계해야 합니다. 단순화를 위해 모든 연결이 (링크드인이 아닌 인스타그램처럼) 직접 연결된다고 가정하겠습니다. 이 구조는 효율적인 다음을 허용해야 합니다.

• 사용자 A가 사용자 B를 읽고 있는지(읽기 패턴)에 대한 질문에 답하세요.
• 사용자 A가 사용자 B를 구독/구독 취소할 때 링크 추가/제거 허용(데이터 변경 템플릿)

물론, 이 문제를 해결하는 데에는 여러 가지 옵션이 있습니다. 일반적인 관계형 DB에서는 링크 테이블(예를 들어, 이 "친구"를 포함하는 가족, 직장 등의 사용자 그룹을 저장해야 하는 경우 타이핑 가능)을 만들고, 액세스 속도를 최적화하기 위해 인덱스/파티셔닝을 추가할 가능성이 높습니다. 결과 테이블은 다음과 같을 것입니다.

USER_ID
친구_아이디

Vasya
페티

Vasya
Оля

명확성과 더 나은 이해를 위해 여기와 더 나아가 ID 대신 이름을 표시하겠습니다.

HBase의 경우 다음 사항을 알 수 있습니다.

• 전체 테이블 스캔으로 이어지지 않는 효율적인 검색이 가능합니다. 키로만 독점적으로
  • 사실, 많은 사람이 익숙한 그런 데이터베이스에 SQL 쿼리를 작성하는 것은 나쁜 생각입니다. 기술적으로는 같은 Impala에서 HBase로 조인 및 기타 논리를 포함한 SQL 쿼리를 보낼 수 있지만 얼마나 효과적일까요...

따라서 사용자 ID를 키로 사용해야 합니다. "친구 ID를 어디에 어떻게 저장할 것인가?"라는 주제에서 가장 먼저 떠오르는 생각은 열에 저장하는 것입니다. 이 가장 명확하고 "순진한" 옵션은 다음과 같습니다(이름을 다음과 같이 지정하겠습니다). 옵션 1(기본값), 추후 참고용으로):

로우키
연사

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

페티
1: 마샤
2: 바샤

여기서 각 행은 네트워크의 한 사용자에 해당합니다. 열에는 친구 수에 따라 1, 2, …라는 이름이 지정되고, 각 열에는 친구의 ID가 저장됩니다. 각 행의 열 개수는 서로 다르다는 점에 유의해야 합니다. 위 그림의 예에서 한 행에는 세 개의 열(1, 2, 3)이 있고, 두 번째 행에는 두 개의 열(1과 2)만 있습니다. 여기서는 관계형 데이터베이스에 없는 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)의 점근적 계산 복잡도를 얻었습니다.
데이터베이스에서 거의 항상 전체 줄을 읽어야 하고, 세 가지 경우 중 두 가지는 모든 열을 검토하여 총 친구 수를 세는 데만 사용된다는 것을 이미 알고 계실 것입니다. 따라서 최적화를 위해 각 네트워크 사용자의 총 친구 수를 저장하는 "count" 열을 추가할 수 있습니다. 이 경우, 총 친구 수를 세는 데 전체 줄을 읽을 필요가 없고, "count" 열 하나만 읽으면 됩니다. 중요한 것은 데이터를 조작할 때 "count" 열을 업데이트하는 것을 잊지 않는 것입니다. 이렇게 하면 개선된 결과를 얻을 수 있습니다. 옵션 2(개수):

로우키
연사

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의 잠재력을 이 작업에서 훨씬 더 효과적으로 활용할 수 있게 해 줍니다.

로우키
연사

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

페티
마샤: 1
바샤: 1

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

• 데이터 읽기: Vasya가 Olya에 가입했는지 여부에 대한 질문에 답하려면 "Olya" 열 하나만 읽으면 됩니다. 가입했다면 답은 True이고, 가입하지 않았다면 False입니다 => O(1)
• 세부 정보 편집: 친구 추가: 친구 추가: 새로운 열 "친구 ID"를 추가하기만 하면 됩니다 => O(1)
• 변경 사항: 친구 삭제: "친구 ID" 열만 제거하면 됩니다 => O(1)

보시다시피, 이러한 저장 모델의 중요한 장점은 필요한 모든 시나리오에서 단 하나의 열만 사용하여 작업할 수 있다는 것입니다. 즉, 데이터베이스에서 전체 행을 읽지 않아도 되고, 더 나아가 해당 행의 모든 ​​열을 검토하지 않아도 됩니다. 여기서 멈출 수도 있지만...

이 부분을 고민해 보면 데이터베이스 접근 시 성능을 최적화하고 I/O 작업을 줄이는 방향으로 한 걸음 더 나아갈 수 있습니다. 연결에 대한 전체 정보를 행 키에 직접 저장하면 어떨까요? 즉, 키를 userID.friendID처럼 복합 키로 만드는 것입니다. 이 경우 행 열을 읽을 필요도 없습니다(옵션 4(행)):

로우키
연사

바샤.페티아
페티야: 1

바샤.올야
올리야: 1

바샤.다샤
다샤: 1

페티아.마샤
마샤: 1

페티야.바샤
바샤: 1

이러한 구조에서 모든 데이터 조작 시나리오의 평가는 이전 변형과 마찬가지로 O(1)이 될 것입니다. 변형 3과의 차이점은 데이터베이스의 입출력 작업 효율성에만 있습니다.

자, 마지막 "나비넥타이"입니다. 옵션 4에서 행 키의 길이가 가변적이어서 성능에 영향을 미칠 수 있다는 것을 쉽게 알 수 있습니다(HBase는 데이터를 바이트 집합으로 저장하고 테이블의 행은 키 기준으로 정렬된다는 점을 기억하세요). 또한, 구분 기호가 있는데, 경우에 따라 처리해야 할 수도 있습니다. 이러한 영향을 없애려면 userID와 friendID의 해시를 사용할 수 있습니다. 두 해시 모두 길이가 고정되어 있으므로 구분 기호 없이 간단히 연결할 수 있습니다. 그러면 테이블의 데이터는 다음과 같습니다(옵션 5(해시)):

로우키
연사

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의 친구인지 확인하세요
• 친구 한 명 삭제

따라서 초기 명세서에 명시된 요구 사항을 고려할 때 검증 시나리오는 다음과 같습니다.

• 데이터 기록크기가 n인 무작위 초기 네트워크를 생성합니다. "실제 세계"에 더 가깝게 만들기 위해 각 사용자의 친구 수 또한 확률 변수로 지정합니다. "조건부 애플리케이션"이 생성된 모든 데이터를 HBase에 쓰는 데 걸리는 시간을 측정합니다. 그런 다음 결과 시간을 추가된 친구 수로 나눕니다. 이렇게 하면 한 "비즈니스 작업"에 걸리는 평균 시간을 구할 수 있습니다.
• 데이터 읽기각 사용자에 대해, 사용자가 구독하는지 여부에 관계없이 답변을 얻어야 하는 "성격" 목록을 작성하십시오. 목록의 길이는 대략 사용자의 친구 수와 같으며, 선택된 친구의 절반은 "예", 나머지 절반은 "아니요"로 답해야 합니다. 확인은 "예"와 "아니요"가 번갈아 나타나는 순서로 수행됩니다(즉, 매 초마다 옵션 1과 2에 대한 행의 모든 ​​열을 검토해야 합니다). 그런 다음 총 확인 시간을 선택된 친구 수로 나누어 한 주제를 확인하는 데 걸리는 평균 시간을 구합니다.
• 데이터 삭제사용자의 모든 친구를 삭제합니다. 삭제 순서는 무작위입니다(즉, 데이터 기록에 사용된 원래 목록을 "섞습니다"). 총 확인 시간을 삭제되는 친구 수로 나누어 한 번의 확인에 걸리는 평균 시간을 구합니다.

5가지 데이터 모델 변형 각각과 다양한 규모의 소셜 네트워크에 대해 시나리오를 실행하여 네트워크가 성장함에 따라 시간이 어떻게 변하는지 확인해야 합니다. 5n 내에서 네트워크의 연결과 확인할 사용자 목록은 XNUMX가지 변형 모두에서 당연히 동일해야 합니다.
더 나은 이해를 위해, 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 결과를 낼 것입니다. "친구"의 삽입, 검증 및 삭제는 사전에 지정된 정확한 순서에 따라 수행됩니다.

이 실험은 노트북에서 실행되었습니다. Windows 10HBase는 하나의 Docker 컨테이너에서 실행되고, Python과 Jupyter Notebook은 다른 컨테이너에서 실행되었습니다. Docker에는 2개의 CPU 코어와 2GB의 RAM이 할당되었습니다. "더미 애플리케이션" 시뮬레이션과 테스트 데이터 생성 및 시간 측정 프레임워크를 포함한 모든 로직은 Python으로 작성되었습니다. 라이브러리는 다음과 같습니다. 해피베이스, 옵션 5에 대한 해시(MD5)를 계산하려면 - hashlib

특정 노트북의 컴퓨팅 성능을 고려하여 전체 테스트 주기(모든 n에 대한 모든 옵션에 대한 모든 시나리오)의 총 실행 시간이 한 번의 티파티(평균 10분) 동안 여전히 어느 정도 합리적이고 적합한 경우 n = 30, 170, … 15에 대해 실험적으로 출시를 선택했습니다.

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

실험 결과

첫 번째 실험은 친구 목록을 채우는 데 걸리는 시간이 어떻게 변하는지 살펴보는 것입니다. 결과는 아래 그래프와 같습니다.

옵션 3~5는 네트워크 규모의 성장에 의존하지 않는 사실상 일정한 "비즈니스 운영" 시간과 눈에 띄는 성능 차이를 보일 것으로 예상됩니다.
옵션 2도 일정하지만 약간 더 낮은 성능을 보이며, 옵션 2~3에 비해 거의 정확히 두 배 더 높습니다. 이는 이론과 일치하기 때문에 만족스럽지 않을 수 없습니다. 이 옵션에서는 HBase와의 입출력 작업 수가 정확히 두 배 더 많습니다. 이는 본 테스트가 이론적으로 우수한 정확도를 제공한다는 간접적인 증거가 될 수 있습니다.
옵션 1은 가장 느릴 것으로 예상되며, 네트워크 크기에 따라 친구 한 명을 추가하는 데 소요되는 시간이 선형적으로 증가하는 모습을 보입니다.
이제 두 번째 테스트의 결과를 살펴보겠습니다.

변형 3~5는 예상대로 네트워크 크기에 관계없이 상수 시간으로 동작합니다. 변형 1과 2는 네트워크 크기 증가에 따라 시간이 선형적으로 증가하며 유사한 성능을 보입니다. 더욱이 변형 2는 약간 더 느린 것으로 나타났습니다. 이는 추가 열 "count"를 읽고 처리해야 하기 때문인 것으로 보이며, 이는 n이 증가함에 따라 더욱 두드러집니다. 하지만 이 비교의 정확도가 상대적으로 낮기 때문에 결론을 내리지는 않겠습니다. 또한, 이러한 비율(변형 1과 2 중 어느 것이 더 빠른지)은 출시 시점마다 (종속성의 본질을 유지하면서도) 변경되었습니다.

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

여기서도 놀랄 일은 없습니다. 옵션 3~5는 제거 작업을 일정한 시간 안에 수행합니다.
게다가 흥미로운 점은 이전 시나리오와 달리 옵션 4와 5는 옵션 3보다 눈에 띄게 성능이 약간 떨어진다는 것입니다. 행 삭제 작업은 일반적으로 논리적인 열 삭제 작업보다 비용이 더 많이 드는 것으로 보입니다.

예상대로 옵션 1과 2는 시간이 선형적으로 증가합니다. 그러나 옵션 2는 카운트 열을 "처리"하기 위한 추가적인 입출력 작업으로 인해 옵션 1보다 지속적으로 느립니다.

실험의 일반적인 결론:

• 옵션 3~5는 HBase를 활용하므로 효율성이 더 높습니다. 그러나 성능은 일정하게 다르며 네트워크 크기에 따라 달라지지 않습니다.
• 변형 4와 5의 차이는 기록되지 않았습니다. 하지만 이것이 변형 5를 사용해서는 안 된다는 것을 의미하지는 않습니다. 테스트 스탠드의 성능 특성을 고려했을 때, 사용된 실험 시나리오가 차이를 드러내지 못했을 가능성이 매우 높습니다.
• 데이터를 사용하여 "비즈니스 운영"을 수행하는 데 필요한 시간이 증가한다는 사실은 이전에 얻은 모든 옵션에 대한 이론적 계산을 전반적으로 확인시켜 주었습니다.

커튼콜

이러한 대략적인 실험 결과는 절대적인 진리로 받아들여서는 안 됩니다. 고려되지 않은 여러 요인들이 결과에 영향을 미쳤으며, 특히 네트워크 규모가 작은 그래프에서 이러한 변동이 두드러지게 나타납니다. 예를 들어, happybase에서 사용하는 Thrift의 속도, 제가 작성한 Python 로직의 구현 방식과 용량(코드가 최적으로 작성되었거나 모든 구성 요소를 효율적으로 활용했다고는 보장할 수 없습니다), HBase 캐싱 기능, 그리고 백그라운드 활동 등이 영향을 미쳤을 수 있습니다. Windows 10 제 노트북 등에서 확인한 결과, 전반적으로 모든 이론적 가정이 실험적으로 타당성이 입증되었다고 결론지을 수 있습니다. 적어도, 이러한 정면 공격으로는 가정을 반박할 수 없었습니다.

결론적으로 HBase에서 데이터 모델을 설계하기 시작하는 모든 사람을 위한 몇 가지 권장 사항은 다음과 같습니다. 관계형 데이터베이스 작업 경험을 접어두고 "계명"을 기억하세요.

• 설계 시 주제 영역 모델이 아닌 작업 및 데이터 조작 패턴에서 진행합니다.
• 효율적인 액세스(전체 테이블 스캔 없음) - 키로만 가능
• 비정규화
• 각 행에는 각기 다른 열이 포함될 수 있습니다.
• 열의 동적 구성

출처 : habr.com