반짝이는 차세대 제품을 위한 데이터 저장소를 선택하는 방법

참고: 이것은 수석 엔지니어 Silvia Botros가 작성한 기술 블로그 게시물이며 2017년 12월 25일 Sysadvent 블로그에 처음 등장했습니다.

데이터베이스는 어려울 수 있습니다. 더 힘든게 뭔지 알아? 우선 하나를 선택합니다. 이것은 당신이 여전히 제품/시장 적합성을 찾고 있는 새로운 회사에 있거나 잠재 고객을 찾았고 단순히 제품 제공을 확장하고 있는 회사에 있는지 여부에 관계없이 도전적입니다.

새로운 것을 구축할 때 설계 프로세스의 가장 첫 번째 부분 중 하나는 어떤 데이터 저장소를 사용해야 하고 단일 또는 복수여야 하는지입니다. 관계형 저장소를 사용해야 합니까 아니면 키 값 저장소를 선택해야 합니까? 시간 옵션은 어떻습니까? 분산 로그 재생도 뿌려야 합니까?

그래서. 많은. 옵션…

나는 이 기사에서 그 결정을 인도할 프로세스를 설명하고 해당되는 경우 조직의 규모와 성숙도가 이 결정에 어떤 영향을 미칠 수 있는지 설명하려고 노력할 것입니다.

기준 요구 사항

데이터는 모든 제품의 생명선입니다. 애플리케이션 상태를 저장하기 위해 더 많은 최첨단 기술을 사용하도록 설계를 계획하더라도(MySQL 또는 Postgres는 더 이상 "쿨"하지 않기 때문에) 우리가 선택하는 것은 여전히 ​​데이터 저장소이므로 다음과 같은 경우 엄격함을 적용해야 합니다. 우리의 선택을 하고 있습니다.

기억해야 할 중요한 것은 공짜는 없다는 것입니다. 모든 데이터 저장소에는 타협이 따르며 비즈니스 위험으로 어떤 타협을 하고 있는지 명시하지 않으면 최악의 시간에 나타날 수 있는 알려지지 않은 위험을 감수하게 됩니다.

제품 관리자는 데이터 저장소에 무엇을 사용하는지 알지 못하거나 신경 쓸 필요가 없지만 옵션 목록을 축소하는 요구 사항을 주도할 것입니다. 때로는 개발 팀의 약간의 넛지가 필요합니다. 다음은 제품 팀에 옵션을 추진하는 데 도움을 요청해야 하는 목록입니다.

• 성장률: 시간이 지남에 따라 데이터 자체 또는 데이터에 대한 액세스가 어떻게 변할 것으로 예상됩니까?
• 청구 팀은 이 새 데이터를 어떻게 사용합니까?
• ETL 팀은 이 데이터를 어떻게 사용합니까?
• 이 새로운 기능에 대해 어떤 정확도/일관성 요구 사항이 필요합니까?
• 그 일관성에 대해 어느 정도의 시간 범위가 허용됩니까? 사후 처리 수정이 허용됩니까?

말하지 않은 맥락 찾기

데이터 저장소의 선택은 DBA나 Ops 팀 또는 코드를 작성하는 엔지니어만 선택할 수 있는 것이 아닙니다.

알려진 시장을 가진 성숙한 조직은 조직 전체의 이해 관계자로부터 결정을 내려야 합니다.

제품 팀의 요구 사항이 12개의 데이터 저장소에 맞는 경우 명시적으로 호출되지 않은 요구 사항을 어떻게 결정합니까?

무언의 요구 사항을 가능한 한 빨리 표면화해야 합니다. 이는 기대가 실패로 이어지는 길이기 때문입니다.

암시된 많은 것들이 이 '너무 많은 선택' 함정에서 실패하게 만들 수 있습니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 불완전한 기능 목록
• 명시적으로 나열되지 않은 성능 요구 사항
• 가정되는 일관성 요구
• 지정되지 않은 성장률
• 아직 사용할 수 없거나 알 수 없는 청구 또는 ETL 쿼리 요구 사항

이는 엔지니어링 팀이 작업 중인 명시적 기준이 너무 관대하거나 불완전하기 때문에 데이터 저장소 선택의 긴 목록을 너무 오래 검토하도록 하는 모든 가능한 방법입니다.

앞서 언급했듯이 더 많은 '그린필드' 제품의 경우 목표는 유연성입니다. 따라서 보다 일반적인 목적의 알려진 품질 데이터 저장소는 결과에 더 가까이 다가가는 데 도움이 될 것이며, 결과적으로 새로운 규모에 더 적합한 데이터 저장소로 이동해야 할 수도 있다는 사실을 알게 될 것입니다.

목록을 만드세요

요구 사항 목록을 기준으로 잠재적 솔루션을 필터링할 때입니다. 결과 목록은 가능한 데이터 저장소의 수보다 많지 않아야 합니다. 사용할 수 있는 잠재적 데이터베이스 목록이 그보다 많다면 요구 사항이 너무 관대하여 돌아가서 더 많은 정보를 찾아야 합니다.

젊고 덜 성숙한 회사의 경우 데이터 저장소 요구 사항은 가장 알려지지 않은 영역입니다. 아직 아무도 제공하지 않는 새로운 것을 구축하고 있을 수 있으므로 전체 시장 규모 및 성장률과 같은 사항은 상대적으로 알려지지 않고 수량화하기 어려울 수 있습니다.

이 경우 필요한 것은 one-trick pony 데이터 저장소를 사용하여 새 회사의 수명 초기에 너무 일찍 자신을 제한하지 않는 것입니다. 예, 어느 시점에서 데이터는 새롭고 예상치 못한 방식으로 성장할 것입니다. 그러나 지금 필요한 것은 틈새 시장을 찾고 데이터 성장이 어떤 모습일지, 그리고 어떤 특정 확장성 기능이 중요하게 될 것인지 배울 때 유연성입니다. 당신의 성장.

유료 고객의 수가 증가하는 대규모 회사의 경우 여기에서 해야 할 일은 옵션 목록을 가급적이면 이미 보유하고 유지 관리하는 데이터 저장소로 축소하는 것입니다. 이미 많은 유료 고객이 있는 경우 팀에 익숙하지 않은 새 데이터 저장소를 추가할 위험이 더 높아지고 데이터 컨텍스트에 따라 단순히 허용할 수 없습니다.

명심해야 할 또 다른 사항은 데이터 저장소에 대해 이미 존재하는 도구와 새 도구를 채택하는 것이 팀이 수행해야 하는 선행 작업에 대한 의미입니다. 구성 관리, 백업 스크립트, 데이터 복구 스크립트, 새로운 모니터링 검사, 구축하고 익숙해지는 새로운 대시보드. 위험에 관계없이 새 데이터 저장소의 운영 비용 목록은 간단하지 않습니다.

당신의 독을 선택하십시오

그래서 여기에 DBA가 간직하고 있는 잘 알려지지 않은 비밀이 있습니다. 데이터베이스는 모두 무언가에 끔찍합니다. 그것에 대한 전체 정리도 있습니다. 전통적인 의미의 데이터베이스뿐만 아니라 상태를 저장하는 모든 기술은 사용 방법에 따라 고유한 방식으로 끔찍할 것입니다.

그것은 당신이 지금 내면화하는 것이 더 나은 삶의 사실입니다. 아니요, 이러한 기술의 사용을 피해야 한다고 말하는 것이 아닙니다. 기대치를 정상으로 유지하고 궁극적으로 귀하와 귀하의 팀만이 약속을 이행할 책임이 있다는 것을 알고 있어야 합니다.

이것은 추상적이지 않은 용어로 무엇을 의미합니까? 어떤 데이터 저장소가 구축 대상의 일부가 될 것인지 확실하게 파악했다면 이러한 데이터 저장소의 약점을 파악하는 것부터 시작해야 합니다. 이러한 약점에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 이 데이터 저장소는 스캔 쿼리에서 잘 작동합니까?
• 이 데이터 저장소는 데이터 복제를 위해 가십 프로토콜에 의존합니까? 그렇다면 네트워크 파티션을 어떻게 처리합니까? 그 가십에 얼마나 많은 데이터가 관련되어 있습니까?
• 이 데이터 저장소에 단일 실패 지점이 있습니까?
• 커뮤니티의 드라이버가 얼마나 성숙하여 그것에 대해 이야기할 수 있습니까? 아니면 직접 굴려야 합니까?
• 이 목록은 엄청날 수 있습니다

여전히 목록에 있는 잠재적 솔루션의 약점을 생각하면 목록에서 더 많은 옵션을 제외할 수 있습니다. 이것은 이제 기술의 숭고한 약속을 충족시키는 현실입니다.

스프레드 시트와 굽기!

선택 목록이 몇 개로 줄어들면 모두 스프레드시트에 넣고 조금 더 깊이 파고들 시간입니다. 찬성 열과 반대 열이 필요하며 이 시점에서 특정 작업을 수행하는 방법에 대한 핵심 세부 정보를 찾기 위해 각 데이터베이스 문서에서 시간을 할애해야 합니다.

성장률이 높을 것으로 예상되는 데이터인 경우 이러한 옵션 중 확장하기 쉬운 옵션을 알아야 합니다. 이것이 많은 퍼지 검색을 수행하는 기능이라면 어떤 데이터 저장소가 어떤 디자인으로 많은 수의 행을 통한 스캔이나 검색을 더 잘 처리할 수 있는지 알아야 합니다. 이 단계의 목표는 이 새로운 기능이 회사의 성공에 충분히 중요하다면 세 가지 모두를 벤치마킹해야 하기 때문에 문서만을 통해 이상적으로는 2개 또는 3개의 옵션으로 목록을 줄이는 것입니다.

왜 벤치마킹을 말합니까? 두 회사가 동일한 데이터 저장소를 동일한 방식으로 사용하지 않기 때문입니다. 때때로 문서에는 다른 사람들의 전쟁 이야기에서만 노출되는 경고가 포함되어 있기 때문입니다.

이 데이터 저장소의 안정성, 신뢰성 및 예측 가능성은 사용자 외에는 아무도 없기 때문입니다.

벤치마크를 미리 설계하십시오. 이상적으로는 프로덕션 수준 사양으로 목록에 있는 데이터 저장소의 전체 인스턴스를 설정하고 부하 테스트를 쓸모 없게 만들기에는 너무 작지 않은 테스트 데이터를 생성합니다. '정상 부하'에 대한 벤치마크뿐만 아니라 일부 오류 시나리오도 테스트해야 합니다.

벤치마크를 통해 나중에 모든 코드가 작성되고 많은 시간이 소요되는 소방 훈련 단계에 있는 것이 아니라 지금 옵션 목록을 다시 방문하게 할 만큼 심각한 경고를 찾을 수 있기를 바랍니다. 그리고 당신이 한 선택에 헌신하는 노력.

선택 문서화

당신이 무엇을 하든, 당신이 선택한 방법과 그 결정에 이르는 과정에서 조사한 대안을 문서화하고 내부적으로 공개해야 합니다. 이 새로운 기능과 모든 구성 요소가 어떻게 생성될 것인지에 대한 포괄적인 아키텍처 청사진이 있다고 가정하고 팀이 내린 결정에 도달하기 위해 수행된 모든 벤치마크에 대한 링크와 함께 이 새로운 기능을 지원하는 데이터 저장소 전용 섹션을 만들어야 합니다. .

이것은 미래의 신입 사원뿐만 아니라 현재 팀의 이익을 위한 것입니다. 사람들이 비동기적으로 읽고 의견을 개발할 수 있는 문서는 결정 프로세스를 투명하게 유지하고 팀 구성원 간에 최선의 의도를 키우는 방법을 제공하며 예상하지 못한 관점에서 비판을 가져올 수 있습니다.

테이크아웃

이러한 단계는 비즈니스 오퍼링을 성장시킬 때 데이터에 입각한 결정으로 이어질 뿐만 아니라 강력한 인프라와 계속 성장하는 기술 분야를 사용하여 지불하는 비용에 가치를 제공하는 시기와 장소에 대한 보다 엄격한 접근 방식으로 이어질 것입니다. 고객.