카산드라. 오라클만 알면 죽지 않는 법

헤이 하브르.

제 이름은 Misha Butrimov입니다. Cassandra에 대해 조금 말씀드리고 싶습니다. 내 이야기는 NoSQL 데이터베이스를 접해 본 적이 없는 사람들에게 유용할 것입니다. NoSQL 데이터베이스에는 여러분이 알아야 할 많은 구현 기능과 함정이 있습니다. 그리고 Oracle이나 다른 관계형 데이터베이스 외에 다른 것을 본 적이 없다면 이러한 것들이 당신의 생명을 구할 것입니다.

카산드라의 좋은 점은 무엇입니까? 단일 장애 지점 없이 확장성이 뛰어나도록 설계된 NoSQL 데이터베이스입니다. 일부 데이터베이스에 몇 테라바이트를 추가해야 하는 경우 간단히 링에 노드를 추가하면 됩니다. 다른 데이터 센터로 확장하시겠습니까? 클러스터에 노드를 추가합니다. 처리된 RPS를 늘리시겠습니까? 클러스터에 노드를 추가합니다. 반대 방향으로도 작동합니다.

그 사람이 또 잘하는 게 뭐야? 많은 요청을 처리하는 것입니다. 그런데 많이는 얼마인가요? 초당 10, 20, 30, 40개의 요청은 많지 않습니다. 녹음 요청도 초당 100만 건입니다. 초당 2만 건의 요청을 보관한다고 하는 회사가 있습니다. 그들은 아마도 그것을 믿어야 할 것입니다.

그리고 원칙적으로 Cassandra는 관계형 데이터와 한 가지 큰 차이점이 있습니다. 전혀 유사하지 않습니다. 그리고 이것은 기억하는 것이 매우 중요합니다.

동일해 보인다고 모두 동일하게 작동하는 것은 아닙니다.

한번은 동료가 나에게 와서 이렇게 물었습니다. “여기 CQL Cassandra 쿼리 언어가 있는데 여기에는 select 문이 있고 where, and가 있습니다. 편지를 쓰는데 잘 안 돼요. 왜?". Cassandra를 관계형 데이터베이스처럼 취급하는 것은 폭력적인 자살을 저지르는 완벽한 방법입니다. 저는 그것을 홍보하는 것이 아닙니다. 러시아에서는 금지되어 있습니다. 당신은 뭔가 잘못된 것을 디자인하게 될 것입니다.

예를 들어, 고객이 우리에게 와서 이렇게 말합니다. “TV 시리즈용 데이터베이스나 레시피 디렉토리용 데이터베이스를 구축하자. 거기에는 음식 요리나 TV 시리즈와 배우 목록이 있을 거예요.” 우리는 기쁜 마음으로 “가자!”라고 말합니다. XNUMX바이트와 몇 개의 기호만 전송하면 완료됩니다. 모든 것이 매우 빠르고 안정적으로 작동합니다. 그리고 고객이 와서 주부들도 반대 문제를 해결하고 있다고 말할 때까지는 모든 것이 괜찮습니다. 그들은 제품 목록을 가지고 있고 어떤 요리를 요리하고 싶은지 알고 싶어합니다. 당신은 죽은.

이는 Cassandra가 하이브리드 데이터베이스이기 때문입니다. 동시에 키 값을 제공하고 넓은 열에 데이터를 저장합니다. Java 또는 Kotlin에서는 다음과 같이 설명할 수 있습니다.

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

즉, 정렬된 지도도 포함하는 지도입니다. 이 맵의 첫 번째 키는 분할 키인 행 키 또는 파티션 키입니다. 이미 정렬된 맵의 키인 두 번째 키는 클러스터링 키입니다.

데이터베이스의 분포를 설명하기 위해 세 개의 노드를 그려보겠습니다. 이제 데이터를 노드로 분해하는 방법을 이해해야 합니다. 왜냐하면 우리가 모든 것을 하나로 묶는다면 (그런데 천, 이천, 다섯이 될 수 있습니다 - 원하는만큼) 이것은 실제로 배포에 관한 것이 아닙니다. 따라서 숫자를 반환하는 수학 함수가 필요합니다. 단지 숫자, 어떤 범위에 속하는 긴 int입니다. 그리고 우리는 하나의 범위를 담당하는 하나의 노드를 갖게 되며, 두 번째는 두 번째, n번째는 n번째를 담당하게 됩니다.

이 숫자는 파티션 키라고 부르는 것에 적용되는 해시 함수를 사용하여 가져옵니다. 이는 Primary key 지시문에 지정되는 열이며, 맵의 첫 번째이자 가장 기본적인 키가 될 열입니다. 어떤 노드가 어떤 데이터를 수신할지 결정합니다. SQL과 거의 동일한 구문을 사용하여 Cassandra에서 테이블이 생성됩니다.

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

이 경우 기본 키는 하나의 열로 구성되며 분할 키이기도 합니다.

사용자의 성과는 어떻게 될까요? 일부는 한 노드로 이동하고, 일부는 다른 노드로, 일부는 세 번째 노드로 이동합니다. 결과는 맵이라고도 알려진 일반 해시 테이블, Python에서는 사전이라고도 알려져 있거나 모든 값을 읽고 키로 읽고 쓸 수 있는 간단한 Key 값 구조입니다.

선택: 허용 필터링이 전체 검사로 전환되는 경우 또는 하지 말아야 할 사항

몇 가지 선택 문을 작성해 보겠습니다. select * from users where, userid = . 이는 Oracle과 같습니다. select를 작성하고 조건을 지정하면 모든 것이 작동하고 사용자가 이를 얻습니다. 그러나 예를 들어 특정 연도의 사용자를 선택하면 Cassandra는 요청을 이행할 수 없다고 불평합니다. 그녀는 출생 연도에 대한 데이터를 어떻게 배포하는지 전혀 모르기 때문에 키로 표시된 열이 하나만 있습니다. 그런 다음 그녀는 “좋아요. 아직 이 요청을 이행할 수 있어요. 허용 필터링을 추가하세요." 지시문을 추가하면 모든 것이 작동합니다. 그리고 이 순간 끔찍한 일이 일어납니다.

테스트 데이터를 실행하면 모든 것이 정상입니다. 예를 들어 4만 개의 레코드가 있는 프로덕션 환경에서 쿼리를 실행하면 모든 것이 좋지 않습니다. 허용 필터링은 Cassandra가 모든 노드, 모든 데이터 센터(이 클러스터에 데이터 센터가 많은 경우)에서 이 테이블의 모든 데이터를 수집한 다음 필터링할 수 있도록 허용하는 지시어이기 때문입니다. 이것은 전체 스캔과 유사하며 거의 만족하지 않습니다.

ID별로 사용자만 필요하다면 이것으로도 괜찮을 것입니다. 그러나 때로는 다른 쿼리를 작성하고 선택에 다른 제한을 적용해야 하는 경우도 있습니다. 따라서 우리는 이것이 모두 분할 키가 있는 맵이지만 그 내부에는 정렬된 맵이 있다는 것을 기억합니다.

그리고 그녀는 클러스터링 키라고 부르는 키도 가지고 있습니다. 이 키는 우리가 선택한 열로 구성되며, 이를 통해 Cassandra는 데이터가 물리적으로 정렬되고 각 노드에 위치하는 방식을 이해합니다. 즉, 일부 파티션 키의 경우 클러스터링 키는 데이터를 이 트리에 푸시하는 방법과 트리에서 어떤 위치를 차지할지 정확하게 알려줍니다.

이것은 실제로 트리이며, 비교기는 간단히 호출되어 객체 형태로 특정 열 집합을 전달하고 열 목록으로도 지정됩니다.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

기본 키 지시문에 주의하세요. 첫 번째 인수(이 경우 연도)는 항상 파티션 키입니다. 하나 이상의 열로 구성될 수 있지만 중요하지 않습니다. 여러 열이 있는 경우 언어 전처리기가 이것이 기본 키이고 그 뒤에 있는 다른 모든 열은 클러스터링 키임을 이해할 수 있도록 대괄호로 다시 제거해야 합니다. 이 경우에는 표시된 순서대로 비교기에서 전송됩니다. 즉, 첫 번째 열은 더 중요하고 두 번째 열은 덜 중요합니다. 예를 들어 작성 방법은 데이터 클래스의 필드와 같습니다. 필드를 나열하고 해당 필드에 대해 어느 것이 더 크고 어느 것이 더 작은지 기록합니다. Cassandra에서 이는 상대적으로 말하면 데이터 클래스의 필드이며 이에 대해 작성된 동등 항목이 적용됩니다.

정렬을 설정하고 제한을 적용합니다.

정렬 순서(내림차순, 오름차순 등)는 키가 생성되는 동시에 설정되며 나중에 변경할 수 없다는 점을 기억해야 합니다. 이는 데이터 정렬 방법과 저장 방법을 물리적으로 결정합니다. 클러스터링 키나 정렬 순서를 변경해야 하는 경우 새 테이블을 만들고 데이터를 테이블로 전송해야 합니다. 기존 항목에서는 작동하지 않습니다.

우리는 테이블을 사용자로 채웠고 그들이 처음에는 생년월일별로 링에 들어간 다음 급여와 사용자 ID별로 각 노드에 들어가는 것을 확인했습니다. 이제 제한을 적용하여 선택할 수 있습니다.

우리 일하는 사람이 다시 나타납니다 where, and, 그리고 사용자를 확보하면 모든 것이 다시 정상이 됩니다. 그러나 클러스터링 키의 일부와 덜 중요한 키만 사용하려고 하면 Cassandra는 맵에서 null 비교기에 대한 필드가 있는 이 객체가 있는 위치를 찾을 수 없다고 즉시 불평할 것입니다. 그건 방금 정해졌어 - 그가 누워 있는 곳이요. 이 노드에서 모든 데이터를 다시 가져와서 필터링해야 합니다. 이는 노드 내 전체 검색과 유사하며 이는 좋지 않습니다.

불확실한 상황에서는 새 테이블을 만듭니다.

ID별, 연령별, 급여별 타겟팅을 하려면 어떻게 해야 할까요? 아무것도 아님. 테이블 10개만 사용하세요. 세 가지 다른 방법으로 사용자에게 접근해야 하는 경우 세 개의 테이블이 있습니다. 나사 공간을 절약하던 시절은 지나갔습니다. 이것은 가장 저렴한 자원입니다. 응답 시간보다 비용이 훨씬 적게 들기 때문에 사용자에게 해로울 수 있습니다. 사용자는 XNUMX분 안에 무언가를 받는 것보다 XNUMX초 안에 무언가를 받는 것이 훨씬 더 즐겁습니다.

우리는 확장이 잘되고 안정적으로 작동할 수 있는 능력을 위해 불필요한 공간과 비정규화된 데이터를 교환합니다. 결국, 실제로 XNUMX개의 데이터 센터로 구성되고 각 데이터 센터에는 XNUMX개의 노드가 있으며 허용 가능한 수준의 데이터 보존(아무 것도 손실되지 않는 경우)을 갖춘 클러스터는 하나의 데이터 센터가 종료되더라도 완전히 살아남을 수 있습니다. 나머지 두 개에는 각각 두 개의 노드가 더 있습니다. 그 후에야 문제가 시작됩니다. 이는 꽤 좋은 중복성이므로 SSD 드라이브와 프로세서를 추가로 추가할 가치가 있습니다. 따라서 결코 SQL이 아닌 관계, 외래키가 없는 카산드라를 사용하기 위해서는 간단한 규칙을 알아야 한다.

우리는 귀하의 요청에 따라 모든 것을 디자인합니다. 가장 중요한 것은 데이터가 아니라 애플리케이션이 데이터를 어떻게 사용할 것인지입니다. 서로 다른 데이터를 서로 다른 방식으로 수신해야 하거나 동일한 데이터를 서로 다른 방식으로 수신해야 하는 경우 애플리케이션에 편리한 방식으로 배치해야 합니다. 그렇지 않으면 전체 스캔이 실패하고 Cassandra는 우리에게 어떤 이점도 주지 않습니다.

데이터를 비정규화하는 것이 일반적입니다. 우리는 정규 형식을 잊어버리고 더 이상 관계형 데이터베이스를 갖고 있지 않습니다. 100번 물건을 내려놓으면 100번 누워 있게 됩니다. 멈추는 것보다 여전히 저렴합니다.

파티셔닝용 키를 선택하여 정상적으로 배포되도록 합니다. 우리는 키의 해시가 하나의 좁은 범위에 들어가는 것을 원하지 않습니다. 즉, 위 예에서 태어난 연도는 나쁜 예이다. 더 정확하게 말하면, 사용자가 출생연도별로 정규 분포되어 있으면 좋고, 5학년 학생에 대해 이야기하면 좋지 않습니다. 파티셔닝이 그리 좋지 않을 것입니다.

Clustering Key 생성 단계에서 Sorting을 XNUMX회 선택합니다. 변경해야 하는 경우 테이블을 다른 키로 업데이트해야 합니다.

그리고 가장 중요한 점은 동일한 데이터를 100가지 다른 방법으로 검색해야 한다면 100개의 다른 테이블을 갖게 된다는 것입니다.

출처 : habr.com