NoSQL에 대한 데이터, 안정성, 믿음을 잃지 않고 카산드라의 눈을 들여다보는 방법

그들은 인생의 모든 것이 적어도 한 번은 시도해 볼 가치가 있다고 말합니다. 그리고 관계형 DBMS 작업에 익숙하다면 우선 적어도 일반적인 개발의 경우 실제로 NoSQL에 익숙해지는 것이 좋습니다. 현재 이 기술의 급속한 발전으로 인해 이 주제에 대해 많은 상충되는 의견과 열띤 논쟁이 벌어지고 있으며, 특히 관심을 불러일으키고 있습니다.
이 모든 분쟁의 본질을 살펴보면 잘못된 접근 방식으로 인해 발생한다는 것을 알 수 있습니다. 필요한 곳에 정확하게 NoSQL 데이터베이스를 사용하는 사람들은 이 솔루션의 모든 이점에 만족하고 혜택을 받습니다. 그리고 이 기술을 전혀 적용할 수 없는 만병통치약으로 의존하는 실험자들은 상당한 이점을 얻지 못한 채 관계형 데이터베이스의 장점을 잃어 실망했습니다.

Cassandra DBMS를 기반으로 솔루션을 구현하면서 우리가 직면했던 일, 어려운 상황을 어떻게 극복했는지, NoSQL을 사용하여 이익을 얻을 수 있었는지, 추가 노력/자금을 투자해야 했던 부분에 대해 말씀드리겠습니다. .
초기 작업은 일종의 저장소에 통화를 기록하는 시스템을 구축하는 것입니다.

시스템의 작동 원리는 다음과 같습니다. 입력에는 호출 구조를 설명하는 특정 구조의 파일이 포함됩니다. 그런 다음 애플리케이션은 이 구조가 적절한 열에 저장되었는지 확인합니다. 향후 저장된 통화는 가입자의 트래픽 소비에 대한 정보(요금, 통화, 잔액 내역)를 표시하는 데 사용됩니다.

그들이 Cassandra를 선택한 이유는 매우 분명합니다. 그녀는 기관총처럼 글을 쓰고, 쉽게 확장할 수 있으며, 내결함성이 있습니다.

이것이 바로 경험이 우리에게 준 것입니다.

예, 실패한 노드는 비극이 아닙니다. 이것이 카산드라 내결함성의 핵심입니다. 하지만 노드는 살아 있으면서도 동시에 성능이 저하되기 시작할 수 있습니다.. 결과적으로 이는 전체 클러스터의 성능에 즉시 영향을 미칩니다.

Cassandra는 Oracle이 제약 조건으로 저장한 곳에서는 보호하지 않습니다.. 그리고 응용 프로그램 작성자가 이를 미리 이해하지 못했다면 Cassandra에 도착한 이중은 원본보다 나쁘지 않습니다. 도착하면 넣어드리겠습니다.

IB는 기본적으로 제공되는 무료 Cassandra를 매우 싫어했습니다. 사용자 작업이 기록되지 않으며 권한이 차별화되지 않습니다.. 통화에 관한 정보는 개인 데이터로 간주됩니다. 즉, 어떤 방식으로든 이를 요청/변경하려는 모든 시도는 후속 감사 가능성과 함께 기록되어야 합니다. 또한 다양한 사용자에 대해 다양한 수준에서 권한을 분리해야 할 필요성을 인식해야 합니다. 단순 운영 엔지니어와 전체 키스페이스를 자유롭게 삭제할 수 있는 슈퍼 관리자는 역할이 다르고, 책임이 다르며, 역량도 다릅니다. 이러한 액세스 권한의 차별화가 없으면 데이터의 가치와 무결성은 ANY 일관성 수준보다 더 빨리 즉시 의문이 제기됩니다.

통화에는 다양한 조건에 대한 진지한 분석과 주기적인 샘플링이 모두 필요하다는 점을 고려하지 않았습니다. 선택한 레코드는 삭제되고 다시 작성되어야 하기 때문에(작업의 일부로 데이터가 처음에 루프에 잘못 입력되었을 때 데이터를 업데이트하는 프로세스를 지원해야 함) 여기서 Cassandra는 우리 친구가 아닙니다. Cassandra는 돼지 저금통과 같습니다. 물건을 넣기에는 편리하지만 셀 수는 없습니다.

테스트 영역으로 데이터를 전송하는 중에 문제가 발생했습니다. (테스트에서는 노드 5개, 무도회에서는 노드 20개) 이 경우 덤프를 사용할 수 없습니다.

Cassandra에 쓰는 애플리케이션의 데이터 스키마를 업데이트하는 데 문제가 있습니다. 롤백하면 수많은 삭제 표시가 생성되어 예측할 수 없는 방식으로 생산성 손실을 초래할 수 있습니다.. Cassandra는 녹음에 최적화되어 있어 쓰기 전에 많은 생각을 하지 않으며 기존 데이터를 사용하는 모든 작업도 녹음입니다. 즉, 불필요한 것을 삭제함으로써 더 많은 기록을 생산하게 되고 그 중 일부에만 묘비가 남게 되는 것입니다.

삽입 시 시간 초과가 발생했습니다. 녹음 속 카산드라는 아름답지만 때때로 들어오는 흐름이 그녀를 크게 당황하게 할 수 있습니다.. 이는 애플리케이션이 어떤 이유로 삽입할 수 없는 여러 레코드를 순환하기 시작할 때 발생합니다. 그리고 gc.log, 느린 쿼리에 대한 시스템 및 디버그 로그, 보류 중인 압축에 대한 측정항목을 모니터링할 실제 DBA가 필요합니다.

클러스터에 있는 여러 데이터 센터. 어디서 읽고 어디서 써야 할까요?
아마도 읽기와 쓰기로 나누어질 수도 있겠죠? 그렇다면 쓰기 또는 읽기 신청에 더 가까운 DC가 있어야 합니까? 그리고 일관성 수준을 잘못 선택하면 진짜 분열이 발생하지 않을까요? 질문도 많고, 알 수 없는 설정도 많고, 실제로 만져보고 싶은 가능성도 많습니다.

우리가 결정한 방법

노드가 가라앉는 것을 방지하기 위해 SWAP이 비활성화되었습니다.. 이제 메모리가 부족하면 노드가 다운되고 대규모 gc 일시 중지가 생성되지 않아야 합니다.

따라서 우리는 더 이상 데이터베이스의 논리에 의존하지 않습니다. 애플리케이션 개발자는 스스로 재교육을 받고 있으며 자신의 코드에 적극적으로 예방 조치를 취하기 시작했습니다. 데이터 저장과 처리를 이상적으로 명확하게 분리합니다.

DataStax에서 지원을 구입했습니다. 박스형 Cassandra의 개발은 이미 중단되었습니다(마지막 커밋은 2018년 XNUMX월이었습니다). 동시에 Datastax는 우수한 서비스와 기존 IP 솔루션에 맞게 수정되고 적용된 다양한 솔루션을 제공합니다.

또한 Cassandra는 선택 쿼리에 그다지 편리하지 않다는 점도 지적하고 싶습니다. 물론 CQL은 Trift에 비해 사용자에게 있어서 큰 발전입니다. 그러나 이러한 편리한 조인, 모든 필드별 무료 필터링 및 쿼리 최적화 기능에 익숙한 전체 부서가 있고 이러한 부서가 불만 및 사고를 해결하기 위해 노력하고 있다면 Cassandra의 솔루션은 그들에게 적대적이고 어리석은 것처럼 보입니다. 그리고 우리는 동료들이 어떻게 샘플을 만들어야 할지 결정하기 시작했습니다.

우리는 두 가지 옵션을 고려했는데 첫 번째 옵션에서는 C*뿐만 아니라 아카이브된 Oracle 데이터베이스에서도 호출을 작성했습니다. 단, C*와 달리 이 데이터베이스는 이번 달의 통화만 저장합니다(충전 케이스에 충분한 통화 저장 깊이). 여기서 우리는 즉시 다음과 같은 문제를 발견했습니다: 동기식으로 작성하면 빠른 삽입과 관련된 C*의 모든 이점을 잃게 되며, 비동기식으로 작성하면 필요한 모든 호출이 Oracle에 전혀 전달된다는 보장이 없습니다. 한 가지 장점이 있지만 큰 장점은 작동을 위해 동일한 친숙한 PL/SQL 개발자가 남아 있다는 것입니다. 즉, 실제로 "Facade" 패턴을 구현한다는 것입니다. 대체 옵션입니다. 우리는 C*에서 호출을 언로드하고, Oracle의 해당 테이블에서 강화를 위해 일부 데이터를 가져오고, 결과 샘플을 조인하고 결과를 제공하는 메커니즘을 구현합니다. 그런 다음 이를 어떻게든 사용합니다(롤백, 반복, 분석, 감탄). 단점: 프로세스가 상당히 다단계이고, 게다가 운영 직원을 위한 인터페이스도 없습니다.

결국 우리는 두 번째 옵션을 선택했습니다. Apache Spark는 다양한 jar에서 샘플링하는 데 사용되었습니다. 메커니즘의 본질은 지정된 키(구독자, 호출 시간 - 섹션 키)를 사용하여 C*에서 데이터를 가져오고 다른 데이터베이스에서 강화하는 데 필요한 데이터를 가져오는 Java 코드로 축소되었습니다. 그런 다음 이를 메모리에 결합하고 결과 테이블에 결과를 표시합니다. 우리는 스파크 위에 웹 페이스를 그렸고 꽤 유용하게 나타났습니다.

산업 테스트 데이터 업데이트 문제를 해결하면서 우리는 몇 가지 솔루션을 다시 고려했습니다. 둘 다 Sstloader를 통해 전송되며 테스트 영역의 클러스터를 두 부분으로 분할하는 옵션이 있습니다. 각 부분은 프로모션 클러스터와 동일한 클러스터에 교대로 속하므로 Sstloader를 통해 구동됩니다. 테스트를 업데이트할 때 이를 교체할 계획이었습니다. 테스트에서 작동한 부분은 지워지고 프로덕션에 들어가고 다른 부분은 별도로 데이터 작업을 시작합니다. 그러나 다시 생각해 본 결과 전송할 가치가 있는 데이터를 보다 합리적으로 평가했으며 호출 자체가 테스트에 일관성이 없는 개체이고 필요할 경우 빠르게 생성되며 홍보용 데이터 세트이므로 전송 가치가 없다는 것을 깨달았습니다. 시험. 이동할 가치가 있는 여러 개의 저장 개체가 있지만 이는 문자 그대로 두 개의 테이블이며 그리 무겁지는 않습니다. 그러므로 우리는 해결책으로 Spark가 다시 구조에 나섰고, 그 도움으로 우리는 테이블 간 데이터 전송, 무도회 테스트 스크립트를 작성하고 적극적으로 사용하기 시작했습니다.

현재 배포 정책을 통해 롤백 없이 작업할 수 있습니다. 프로모션 전에는 실수로 인해 비용이 많이 들지 않는 필수 테스트 실행이 있습니다. 실패할 경우 언제든지 케이스 공간을 삭제하고 처음부터 전체 구성표를 롤링할 수 있습니다.

Cassandra의 지속적인 가용성을 보장하려면 그뿐만 아니라 DBA도 필요합니다. 애플리케이션을 사용하는 모든 사람은 현재 상황을 어디서, 어떻게 살펴보고 적시에 문제를 진단하는 방법을 이해해야 합니다. 이를 위해 우리는 DataStax OpsCenter(워크로드 관리 및 모니터링), Cassandra 드라이버 시스템 지표(C* 쓰기 제한 시간 수, C* 읽기 제한 시간 수, 최대 대기 시간 등)를 적극적으로 사용하고 작업을 모니터링합니다. Cassandra와 함께 작업하는 애플리케이션 자체의 모습입니다.

이전 질문에 대해 생각했을 때 우리는 주요 위험이 어디에 있는지 깨달았습니다. 이는 여러 독립적인 쿼리의 데이터를 저장소에 표시하는 데이터 표시 형식입니다. 이런 식으로 우리는 매우 일관성 없는 정보를 얻을 수 있습니다. 하지만 이 문제는 우리가 단 하나의 데이터 센터에서만 작업하는 경우에도 마찬가지입니다. 따라서 여기서 가장 합리적인 것은 물론 타사 애플리케이션에서 데이터를 읽기 위한 일괄 기능을 만드는 것입니다. 이를 통해 단일 기간 내에 데이터가 수신되도록 할 수 있습니다. 성능 측면에서 읽기와 쓰기를 구분하는 경우 DC 간의 연결이 일부 끊어지면 서로 완전히 일치하지 않는 두 클러스터가 발생할 수 있다는 위험으로 인해 중단되었습니다.

그 결과 지금으로서는 EACH_QUORUM 쓰기, 읽기 - LOCAL_QUORUM 일관성 수준에서 중지되었습니다.

간략한 인상과 결론

운영 지원 및 추가 개발 전망의 관점에서 결과 솔루션을 평가하기 위해 우리는 이러한 개발이 다른 곳에 적용될 수 있는지 생각해 보기로 결정했습니다.

즉시, "편리할 때 지불"(C*에 정보 로드, Spark 스크립트를 사용하여 계산)과 같은 프로그램에 대한 데이터 점수 매기기, 영역별 집계를 통한 청구 계산, 역할 저장 및 역할에 따라 사용자 액세스 권한 계산 행렬.

보시다시피 레퍼토리는 넓고 다양합니다. 그리고 우리가 NoSQL의 지지자/반대자 진영을 선택한다면 우리는 우리의 이점을 얻었고 정확히 기대했던 곳에서 지지자에 합류하게 될 것입니다.

기본적으로 제공되는 Cassandra 옵션도 실시간 수평 확장이 가능하므로 시스템의 데이터 증가 문제를 전혀 고통 없이 해결할 수 있습니다. 우리는 호출 집계를 계산하기 위한 로드가 매우 높은 메커니즘을 별도의 회로로 이동할 수 있었고, 애플리케이션 스키마와 로직도 분리하여 데이터베이스 자체에 사용자 정의 작업과 개체를 작성하는 나쁜 관행을 제거할 수 있었습니다. 우리는 계산을 수행할 DC와 데이터를 기록할 DC를 선택하고 구성하고 속도를 높일 수 있는 기회를 얻었으며 개별 노드와 DC 전체의 충돌로부터 스스로를 보호했습니다.

우리 아키텍처를 새로운 프로젝트에 적용하고 이미 경험을 쌓았기 때문에 위에서 설명한 뉘앙스를 즉시 고려하여 실수를 방지하고 처음에는 피할 수 없었던 날카로운 모서리를 부드럽게 만들고 싶습니다.

예를 들어, 적시에 Cassandra의 업데이트를 추적합니다.왜냐하면 우리가 겪은 문제 중 상당수가 이미 알려져 있고 해결되었기 때문입니다.

데이터베이스 자체와 Spark를 동일한 노드에 배치하지 마십시오. (또는 허용되는 리소스 사용량으로 엄격하게 나누기) Spark는 예상보다 많은 OP를 소모할 수 있으므로 목록에서 문제 번호 1을 빠르게 얻을 수 있습니다.

프로젝트 테스트 단계에서 모니터링 및 운영 역량을 향상시킵니다. 처음에는 우리 솔루션의 모든 잠재적 소비자를 최대한 고려하십시오., 이는 데이터베이스 구조가 궁극적으로 의존하는 것이기 때문입니다.

가능한 최적화를 위해 결과 회로를 여러 번 회전합니다. 직렬화할 수 있는 필드를 선택합니다. 가장 정확하고 최적으로 고려하기 위해 어떤 추가 테이블을 만들어야 하는지 이해한 다음 요청 시 필요한 정보를 제공합니다(예: 동일한 데이터를 다른 테이블에 저장할 수 있다고 가정하여 다른 기준에 따라 읽기 요청에 대한 CPU 시간을 크게 절약할 수 있습니다.

나쁘지 않다. 즉시 TTL 첨부 및 오래된 데이터 정리를 제공합니다.

Cassandra에서 데이터를 다운로드할 때 애플리케이션 논리는 FETCH 원칙에 따라 작동해야 하므로 모든 행이 한 번에 메모리에 로드되지 않고 일괄적으로 선택됩니다.

설명된 솔루션으로 프로젝트를 전송하기 전에 권장됩니다. 일련의 충돌 테스트를 수행하여 시스템의 내결함성을 확인합니다.한 데이터센터 내 데이터 손실, 일정 기간 동안 손상된 데이터 복구, 데이터센터 간 네트워크 단절 등이 대표적이다. 이러한 테스트를 통해 제안된 아키텍처의 장단점을 평가할 수 있을 뿐만 아니라 이를 수행하는 엔지니어에게 좋은 준비 연습을 제공할 수 있으며 시스템 오류가 프로덕션에서 재현되는 경우 습득한 기술은 결코 불필요한 것이 아닙니다.

중요한 정보(청구용 데이터, 가입자 부채 계산 등)로 작업하는 경우 DBMS의 기능으로 인해 발생하는 위험을 줄이는 도구에도 주목할 가치가 있습니다. 예를 들어 nodesync 유틸리티(Datastax)를 사용하여 최적의 사용 전략을 개발했습니다. 일관성을 위해 Cassandra에 과도한 부하를 생성하지 마십시오. 특정 기간 동안 특정 테이블에만 사용하세요.

XNUMX개월이 지난 후 카산드라는 어떻게 되나요? 일반적으로 해결되지 않은 문제는 없습니다. 또한 심각한 사고나 데이터 손실도 허용하지 않았습니다. 예, 우리는 이전에 발생하지 않았던 몇 가지 문제를 보상하는 것에 대해 생각해야 했지만 결국 이로 인해 우리의 아키텍처 솔루션이 크게 흐려지지는 않았습니다. 새로운 것을 시도하는 것을 원하고 두려워하지 않으며 동시에 너무 실망하고 싶지 않다면 무료는 아무것도 없다는 사실에 대비하십시오. 이전 레거시 솔루션보다 더 많은 것을 이해하고 문서를 조사하고 자신만의 개별 갈퀴를 조립해야 하며 어떤 이론도 어떤 갈퀴가 당신을 기다리고 있는지 미리 알려주지 않습니다.

출처 : habr.com