데이터베이스 성능은 심각한 비즈니스이지만 왜 그것의 도전과 복잡성을 탐구하는 재미가 없습니까? 😉 여기에 우리가 제 1 장에서 제시 한 상당히 환상적인 이야기입니다. . Database Performance at Scale, 무료 오픈 액세스 책 데이터베이스 성능 Scale 데이터베이스 성능 Scale 여기서 다루는 기술적 주제는 책 전체에 걸쳐 확장됩니다.그러나 이것은 우리가 가난한 패트릭에 대해 이야기하는 유일한 시간입니다.그의 투쟁은 당신에게 가치있는 교훈, 자신의 데이터베이스 성능 예측에 대한 위안을 가져다 줄 것입니다.그리고 아마도 몇 가지 웃음도 가져올 것입니다. * FAANG MAANG (MANGA?) 회사에서 일자리를 잃은 후, 패트릭은 스스로 파업하기로 결정하고 헤드웨어, 녹색 fedoras 사이의 절대적인 좋아하는 거래에 전념하는 니치 온라인 상점을 설립했습니다. 제공의 무료 계층에 대한 몇 가지 실험 후, 패트릭은 NoSQL 데이터베이스-as-a-service 제공에 대한 상당한 할인을 얻기 위해 주요 클라우드 공급 업체와 1 년 계약을 체결하기로 결정했습니다. 매초 최대 1,000 명의 고객에게 서비스를 제공 할 수있는 예비 통과량으로 기술 스택이 준비되었으며 가게는 고객에게 가상 문을 열었습니다. 패트릭의 실망에 따라 매일 10 명 미만의 고객이 사이트를 방문했습니다. Patrick’s Diary of Lessons Learned, Part I Patrick's Diary of Lessons Learned, Part I에 대한 리뷰 보기 수업은 즉시 시작되었습니다 : 일부 데이터베이스는 자신을 보편적이라고 광고하지만 대부분의 데이터베이스는 특정 유형의 워크로드에 가장 잘 작동합니다.The analysis before selecting a database for your own needs must include estimating the characteristics of your own workload: 예측가능하고 안정적인 요청 흐름이 있을 가능성이 있습니까 (예를 들어, 다른 시스템에서 정기적으로 업데이트를 가져오고 있습니까)? 데이터베이스-as-a-service offers often let you choose between provisioned throughput and on-demand purchasing. Although the former is more cost-efficient, it incurs a certain cost regardless of how busy the database actually is. 선택을 평가하고 장기 계약에 헌신하는 것을 피할 수있는 시간을주십시오 (삭감에 의해 유혹되더라도) 설정이 지속 가능한 방식으로 당신을 위해 작동한다는 것을 알기 전에. 최초의 스파이크 3 월 17 일은 매우 행운의 날처럼 보였습니다. 패트릭은 새벽부터 많은 새로운 주문을 발견하게되어 기습니다.그러나 활성 고객의 수가 점점 높아지면서 패트릭의 기분이 악화되기 시작했습니다. 자신과 웹 검색 엔진과 함께 짧은 뇌졸중 세션을 마친 후, 패트릭은 자신의 귀중한 (그리고 꽤 비싼) 데이터베이스 클러스터에 관찰 도구가 부족하다는 것을 깨달았습니다. 패트릭은 자신에게 울부짖으며, 오전 11시경에 나타나기 시작한 수천 개의 "전달량을 초과한"오류 메시지를 스크롤하면서 다시 공격했습니다. Patrick’s Diary of Lessons Learned, Part II Patrick's Diary of Lessons Learned, Part II에 해당되는 글 1건 이것은 Patrick이 배운 것입니다 : 데이터베이스-as-a-service 솔루션은 제공된 통과량을 동적 방식으로 구성할 수 있기 때문에 수락된 요청의 경계가 때때로 일시적으로 이전에 구성된 수준으로 일시적으로 상승될 수 있음을 의미합니다.Or, respectively, they allow it to be temporarily reduced to make the solution slightly more cost-efficient. 작업량이 절대적으로 안정적이더라도 일시적인 하드웨어 실패 또는 갑작스러운 DDoS 공격은 들어오는 요청의 급격한 증가를 일으킬 수 있습니다. 관찰성은 분산된 시스템에서 핵심입니다.그것은 개발자가 실패를 추적적으로 조사 할 수 있습니다.그것은 또한 가능성 실패 시나리오가 감지 될 때 실시간 경고를 제공하여 사람들이 신속하게 반응하고 더 큰 실패를 방지하거나 적어도 클러스터에 대한 부정적인 영향을 최소화 할 수 있습니다. 첫 번째 손실 패트릭은 편지가 도착했을 때 녹색 fedoras가 어떤 종류의 수요를 경험했을 때 일년 내내 유일한 날에 잠재적 인 수입의 대부분을 잃는 외상에서 회복 할 수 없었습니다.이 편지는 성공적으로 주문을 진행하고 그것을 지불 한 잠재 고객의 분노 한 잔을 포함했지만 (증거로 지불 처리 사업자로부터 수수료를 받았음), 그러나 지금은 주문의 세부 사항을 볼 수 없습니다 - 그는 여전히 배달을 기다리고 있습니다! 더 이상 걱정없이 패트릭은 데이터베이스를 탐색했습니다. 놀랍게도 그는 주문의 흔적도 찾지 못했습니다. 완전성을 위해 패트릭은 또한 백업 스냅샷 디렉토리를 탐색함으로써 자신의 바람직한 생각을 실천시켰습니다. 패트릭의 초기 집행 결정 중 하나는 정기적 인 백업 절차를 계획하지 않음으로써 시간과 돈을 절약하는 것이었습니다. 모든 사람에게 데이터 손실이 어떻게 일어났습니까? 선택한 데이터베이스의 일관성 모델을 연구한 후, 패트릭은 일관성 보증, 성능 및 가용성 사이에 합의가 있다는 것을 깨달았습니다. 쿼리를 구성함으로써 linearizabilityFootnote7을 감소한 전송량의 비용으로 요구하거나 일관성 보증을 줄이고 성능을 향상시킬 수 있습니다. 더 높은 전송 능력은 패트릭에게 며칠 전에 무의미한 것이었지만 궁극적으로 고객 데이터는 시스템에 배포되는 복제본이 없어 단일 서버에 착륙했습니다. Patrick’s Diary of Lessons Learned, Part III Patrick's Diary of Lessons Learned, Part III에 해당되는 글 1건 추가 교훈은 포함 : 백업은 분산 된 환경에서 필수적이며, 백업 루틴을 "너무 빨리" 설정하는 것과 같은 것은 없습니다. 모든 데이터베이스 시스템에는 특정 일관성 모델이 있으며, 프로젝트를 설계할 때 이를 고려하는 것이 중요합니다. 일부 사용 사례(금융 시스템을 생각하십시오)에서 일관성은 핵심입니다. 스파이크가 다시 공격한다 몇 달이 지났고 패트릭의 수면 일정은 심지어 안정화의 징후를 나타내기 시작했습니다.정기적 인 백업, 재 설계 된 일관성 모델 및 3 월 16 일에 클러스터를 확대하여 높은 트래픽을 관리하기 위해 그의 달력에 설정 된 상기 안전을 느꼈습니다. 만약 그가 말레이시아에서 레프레초처럼 옷을 입은 고양이의 10초 비디오가 바이러스로 퍼졌다는 것을 알았더라면 ... 시간대를 고려하면 2시 패트릭 시간에 일어났으며 위에서 언급 한 수면 안정화 노력을 망쳤습니다. 한편으로는 관찰성 스위트가 업무를 수행하고 일찍 경고를 시작하여 신속한 반응을 허용했습니다. 한편으로는 패트릭이 시간에 반응했음에도 불구하고 데이터베이스는 거의 즉시 규모를 확대 할 수 없으며 그의 선택 시스템은 그 점에서 예외가 아닙니다. 동시 경쟁의 상승은 매우 높고 집중되었으며, 수천 명의 말레이시아 청소년이 인터넷의 끊임없이 변화하는 트렌드를 추구하기 위해 녹색 모자를 대량 구매하기 위해 서둘렀습니다. 패트릭은 실제 인스턴션을 관찰 할 수있었습니다. L = λW의 아름답게 간결한 수식으로, 법칙은 공통점이 통과 시간 지연과 동일하다는 사실로 단순화 될 수 있습니다. Little의 법칙 공식을 기억하는 데 어려움을 겪는 사람들을 위해, 단위를 생각하십시오. 경쟁은 단지 숫자이며, 지연은 초로 측정 될 수 있으며, 전달량은 일반적으로 1/s로 표현됩니다. 타이프 : 타이프 : 흐름은 하드웨어에 달려 있으며 자연스럽게 제한이 있습니다 (예를 들어, 2023 년에 구입 한 NVMe 드라이브가 초당 테라바이트로 데이터를 제공 할 것으로 예상할 수는 없지만, 우리는이 가정이 가까운 장래에 무효화 될 수 있도록 손가락을 건너고 있습니다!) 한 번 제한이 충돌하면 수식에서 일정으로 취급 할 수 있습니다. 동시가 상승함에 따라 지연도 증가한다는 것이 분명합니다. 최종 사용자들(이 시나리오에서 말레이시아 청소년들)에게는 지연이 몇 초의 평균 인간 인식을위한 마법 장벽을 극복 할 것이라는 것을 의미합니다. 일단이 발생하면 사용자는 너무 좌절하고 시스템이 수리를 넘어 깨졌다고 가정하면서 단순히 포기합니다. " Patrick’s Diary of Lessons Learned, Part IV Patrick's Diary of Lessons Learned, Part IV에 해당되는 글 1건 수업은 계속됩니다 : 예상치 못한 스피크는 피할 수 있으며 클러스터를 확장하는 것은 과도한 동기화의 부정적인 영향을 완화하기에 충분히 빠르지 않을 수 있습니다. 데이터베이스가 적절하게 처리하도록 기대하는 것은 혜택이 없지만 모든 데이터베이스가 할 수있는 것은 아닙니다. 가능하다면 시스템의 동기화를 최대한 빨리 제한하십시오. 예를 들어 데이터베이스가 고객에 의해 직접적으로 접촉되지 않는 경우 (여러 가지 이유로 매우 좋은 아이디어) 대신에 당신의 통제하에 있는 마이크로 서비스 세트를 통해 액세스되면 마이크로 서비스가 동기화 제한을 인식하고 준수하는지 확인하십시오. 리틀의 법칙이 존재한다는 것을 명심하십시오 - 분산 시스템에 관심이있는 사람들을위한 기본적인 지식입니다. Backup Strikes 다시 예상되고 예상치 못한 동전 변동을 고려하기 위해 프로젝트를 다시 설계한 후, 패트릭은 그의 fedora 사업이 마침내 ramen이 수익성이되기를 기쁘게 기다렸다. 불행히도, 다음 3 월 17 일은 예상했던 것처럼 부드럽게 진행되지 않았습니다. 패트릭은 일정한 Grafana 대시보드를 즐기며 하루의 대부분을 보냈으며, 이는 트래픽이 통제되고 고객의 부하를 관리 할 수있는 능력을 유지했습니다.그러나 대시보드는 중지했으며 디스크가 심각하게 과도하게 사용되었다는 것을 친절하게 언급했습니다.이 점은 관찰 된 동일성을 감안할 때 완전히 벗어난 것처럼 보였습니다.이 불규칙성의 가능한 원인을 찾는 동안 패트릭은 그의 공포에 대해 계획된 백업 절차가 연간 최고 부하와 일치했다는 것을 알았습니다... Patrick’s Diary of Lessons Learned, Part V Patrick's Diary of Lessons Learned, Part V에 해당되는 글 1건 결론적인 생각 : 데이터베이스 시스템은 들어오는 사용자 요청 없이도 거의 쓸모가 없으며, 유지 보수 작업은 종종 발생하며, 그들은 동기화와 자원 소비의 내부 원천이기 때문에 고려해야 합니다. 가능한 경우 시스템에 예상되는 낮은 압력의 시간에 대한 유지 보수 옵션을 예약하십시오. 데이터베이스 관리 시스템이 어떤 종류의 서비스 품질 구성을 지원하는 경우, 이러한 기능을 조사하는 것이 좋습니다. 예를 들어, 일반적인 유지 보수 작업보다 사용자 요청에 대한 우선 순위를 설정할 수 있습니다., 특히 피크 시간 동안. 따라서, 사용자 유도 활동이 낮은 기간은 배경 활동을 가속화하는 데 사용될 수 있습니다. 데이터베이스 세계에서, 기본 저장용으로 LSM 나무의 변형을 사용하는 시스템은 읽기/쓰기 성능을 예측할 수 있고 안정적으로 유지하기 위해 약간의 압축(데이터에 대한 일종의 유지 보수 작업)을 수행해야 합니다. 그 끝 Piotr Sarna에 관하여 그는 오픈소스 프로젝트와 Rust 및 C++ 언어에 관심이있는 소프트웨어 엔지니어입니다. 그는 이전에 오픈소스 분산 파일 시스템을 개발하고 삼성 전자에서 학습하는 동안 리눅스 커널과 짧은 모험을 보냈습니다. 그는 또한 ScyllaDB, libSQL뿐만 아니라 ScyllaDB의 오랜 기여자이자 유지 관리자입니다. Piotr는 바르샤바 대학에서 컴퓨터 과학 석사 학위를 졸업했습니다. 그는 "데이터베이스 성능 스케일"과 "개발자를위한 쓰기 : 읽을 수있는 블로그"라는 책의 공동 저자입니다. 피터
