어느 것이 더 낫습니까 – Oracle 또는 Redis 또는 플랫폼 선택을 정당화하는 방법

“이건 꼭 필요한 일이에요.” 그녀는 누구에게도 말을 걸지 않은 채 큰 소리로 말했다. - 이건 꼭 필요해요! 이것이 바로 회사의 주요 임무는 주주의 이익을 위해 이익을 창출하는 것입니다. 글쎄, 생각해 보세요! 그들은 아무것도 두려워하지 않습니다!

율리 두보프, <차악>

이러한 헤드라인을 본 후 해당 기사가 어리석거나 도발적이라고 이미 판단했을 것입니다. 그러나 성급하게 결론을 내리지 마십시오. 대기업, 특히 국가에 참여하는 기업의 직원은 완전히 다른 플랫폼(예: 제목에 있는 플랫폼)을 포함하여 다양한 플랫폼을 비교해야 하는 경우가 많습니다.

물론 DBMS를 이런 식으로 비교하는 사람은 아무도 없습니다. DBMS의 장점과 단점은 잘 알려져 있기 때문입니다. 일반적으로 일부 애플리케이션 문제를 해결하는 플랫폼은 비교 대상입니다. 이 기사에서는 Habr 독자들에게 직접 친숙한 주제로 데이터베이스의 예를 사용하여 이 경우에 사용되는 방법론을 보여줄 것입니다. 그래서,

자극

교육 프로젝트나 취미 프로젝트를 시작할 때 플랫폼을 선택하는 동기는 매우 다양할 수 있습니다. "이것이 내가 가장 잘 아는 플랫폼입니다.", "이 플랫폼을 이해하고 싶습니다.", "여기 최고의 문서가 있습니다." ... 상업 회사의 경우 선택 기준은 동일합니다. 지불해야 할 금액과이 돈으로 무엇을 얻을 수 있습니까?

당연히 당신은 더 적은 비용을 지불하고 더 많은 것을 얻고 싶어합니다. 그러나 더 적은 비용을 지불하거나 더 많은 것을 얻는 것 중 무엇이 더 중요한지 결정하고 각 노드에 가중치를 할당해야 합니다. 저렴한 솔루션보다 고품질 솔루션이 더 중요하다고 가정하고 "비용" 노드에 40%, "기회" 노드에 60%의 가중치를 할당합니다.

대기업에서는 일반적으로 그 반대가 사실입니다. 비용 가중치는 50% 미만으로 떨어지지 않으며 60% 이상일 수도 있습니다. 모델 예에서 중요한 것은 모든 상위 노드의 하위 노드의 총 가중치가 100%여야 한다는 것입니다.

컷오프 조건

사이트 db-engines.com 약 500개의 데이터베이스 관리 시스템이 알려져 있습니다. 당연히 수많은 옵션 중에서 대상 플랫폼을 선택하면 리뷰 기사가 나올 수 있지만 상업 프로젝트는 아닐 수도 있습니다. 선택의 여지를 줄이기 위해 컷오프 기준을 정하고, 해당 기준을 만족하지 못하는 플랫폼은 고려하지 않는다.

컷오프 기준은 다음과 같은 기술적 특징과 관련될 수 있습니다.

• ACID 보장;
• 관계형 데이터 모델;
• SQL 언어 지원(참고: 이는 "관계형 모델"과 동일하지 않음)
• 수평 확장 가능성.

일반적인 기준이 있을 수 있습니다.

• 러시아에서의 상업적 지원 가용성;
• 오픈 소스;
• 통신 및 매스커뮤니케이션부 등록부에 플랫폼 가용성;
• 일부 등급(예: db-engines.com 등급의 처음 XNUMX개 등급)에서 플랫폼의 존재
• 시장 내 전문가의 존재(예: hh.ru 웹사이트의 이력서에서 플랫폼 이름을 검색한 결과를 기반으로 함)

결국 기업별 기준이 있을 수 있습니다.

• 직원 중 전문가의 가용성;
• 모든 지원의 기반이 되는 모니터링 시스템 X 또는 백업 시스템 Y와의 호환성...

가장 중요한 것은 컷오프 기준 목록이 있다는 것입니다. 그렇지 않으면 “플랫폼 Z를 선택하지 않은 이유는 무엇입니까? 최고인 줄 압니다”라고 경영진으로부터 특별한 신뢰를 받는 전문가(또는 “전문가”)가 분명히 있을 것입니다.

비용 견적

솔루션 비용은 당연히 라이센스 비용, 지원 비용, 장비 비용으로 구성됩니다.

시스템의 클래스가 거의 동일한 경우(예: Microsoft SQL Server 및 PostgreSQL) 단순화를 위해 두 솔루션의 장비 수가 거의 동일하다고 가정할 수 있습니다. 이렇게 하면 장비를 평가할 필요가 없으므로 많은 시간과 노력을 절약할 수 있습니다. 완전히 다른 시스템(예: Oracle과 Redis)을 비교해야 하는 경우 올바른 평가를 위해서는 크기 조정(장비 양 계산)이 필요하다는 것이 분명합니다. 존재하지 않는 시스템의 크기를 조정하는 것은 매우 고마운 작업이므로 여전히 그러한 비교를 피하려고 노력합니다. 이는 수행하기 쉽습니다. 차단 조건에서는 데이터 손실이 없고 관계형 모델이 기록되거나 그 반대로 초당 50건의 트랜잭션 로드가 기록됩니다.

라이선스를 평가하려면 공급업체나 파트너에게 고정된 수의 코어와 고정된 기간 동안의 지원에 대한 라이선스 비용을 문의하는 것으로 충분합니다. 일반적으로 기업은 이미 소프트웨어 공급업체와 긴밀한 관계를 맺고 있으며, 데이터베이스 운영 부서가 비용 문제에 자체적으로 답변할 수 없는 경우 편지 한 통이면 이 정보를 얻을 수 있습니다.

공급업체마다 코어 수, 데이터 볼륨, 노드 수 등 라이선스 지표가 다를 수 있습니다. 대기 베이스는 무료일 수도 있고, 메인 베이스와 동일한 방식으로 라이센스를 받을 수도 있습니다. 측정 기준에서 차이가 발견되면 모델 스탠드를 자세히 설명하고 스탠드 라이센스 비용을 계산해야 합니다.

올바른 비교를 위해 중요한 점은 동일한 지원 조건입니다. 예를 들어 Oracle 지원 비용은 연간 라이선스 가격의 22%이지만 PostgreSQL 지원 비용을 지불할 필요는 없습니다. 이렇게 비교하는 게 맞나요? 아니요. 스스로 해결할 수 없는 오류는 완전히 다른 결과를 초래하기 때문입니다. 첫 번째 경우에는 지원 전문가가 신속하게 문제 해결을 도와주지만 두 번째 경우에는 프로젝트가 지연되거나 완료된 프로젝트의 다운타임이 발생할 위험이 있습니다. 무기한으로 운영되는 시스템입니다.

다음 세 가지 방법으로 계산 조건을 균등화할 수 있습니다.

1. 지원 없이 Oracle을 사용하십시오(실제로는 이런 일이 발생하지 않습니다).
2. PostgreSQL에 대한 지원을 구매하세요(예: Postgres Professional에서).
3. 지원 부족과 관련된 위험을 고려하십시오.

예를 들어 위험 계산은 다음과 같습니다. 치명적인 데이터베이스 오류가 발생한 경우 시스템 가동 중지 시간은 영업일 기준 1일입니다. 시스템 사용에 따른 예상 이익은 연간 40억 MNT이고, 사고율은 1/400으로 추산되므로 지원 부족 위험은 연간 약 100억 MNT로 추산됩니다. 물론 '계획이익'과 '예상사고빈도'는 가상의 가치이지만 그런 모델이 있는 것이 없는 것보다는 있는 것이 훨씬 낫다.

실제로 시스템은 장기적인 다운타임으로 인한 평판 손실을 용납할 수 없을 만큼 중요할 수 있으므로 지원이 필요합니다. 가동 중지 시간이 허용되는 경우 지원을 거부하는 것이 때로는 비용을 절약하는 좋은 방법이 될 수 있습니다.

모든 계산을 거쳐 5년간 A 플랫폼을 운영하는 비용이 800억 MNT, B 플랫폼을 운영하는 비용이 650억 600천만 MNT, C 플랫폼을 운영하는 비용이 0.75억 MNT라고 가정해 보겠습니다. 승자로서 플랫폼 C는 가격에 대해 전체 포인트를 받는 반면, 플랫폼 A와 B는 가격이 몇 배나 더 비싼지에 비례하여 약간 적은 금액을 받습니다. 이 경우 – 각각 0.92점과 XNUMX점.

기회 평가

기회 평가는 여러 그룹으로 나뉘며 그 수는 평가하는 사람의 상상력에 의해서만 제한됩니다. 최적의 옵션은 이러한 기능을 사용할 팀으로 기능을 나누는 것 같습니다. 이 예에서는 개발자, 관리자 및 정보 보안 담당자가 있습니다. 이들 함수의 가중치가 40:40:20으로 분포되어 있다고 가정해보자.

개발 기능은 다음과 같습니다.

• 데이터 조작의 용이성;
• 스케일링;
• 보조 인덱스의 존재.

기준 목록과 가중치는 매우 주관적입니다. 동일한 문제를 해결하더라도 이러한 목록, 항목 가중치 및 답변은 ​​팀 구성에 따라 크게 달라집니다. 예를 들어 Facebook은 MySQL을 사용하여 데이터를 저장하고 Instagram은 Cassandra를 기반으로 구축되었습니다. 이러한 응용 프로그램의 개발자가 그러한 표를 작성했을 가능성은 거의 없습니다. Mark Zuckerberg는 샤딩 적용에 따른 비용을 지불하면서 본격적인 관계형 모델을 선택했고, Kevin Systrom은 데이터 액세스 용이성을 희생하면서 플랫폼을 사용하여 확장성을 구축했다고 추측할 수 있습니다.

관리 기능에는 다음이 포함됩니다.

• 백업 시스템 기능;
• 모니터링 용이성;
• 용량 관리 용이성 – 디스크 및 노드;
• 데이터 복제 기능.

질문은 정량적인 방식으로 표현되어야 합니다. 특정 기능을 평가하는 방법에 동의할 수도 있습니다. 예를 들어, Oracle DBMS와 함께 제공되는 도구의 예를 사용하여 백업 도구를 평가해 보겠습니다.

수단
논평
평가

임프/경험치
데이터 업로드 및 로드
0.1

백업 시작/종료
파일 복사
0.3

RMAN
증분 복사 기능
0.7

ZDLRA
증분 복사만 가능, 가장 빠른 지점 복구
1.0

명확한 평가 기준이 없다면 여러 전문가에게 평점을 매긴 후 평균을 내는 것이 합리적이다.

마지막으로 정보 보안 기능을 간단히 나열하면 다음과 같습니다.

• 비밀번호 관리 정책의 가용성;
• 외부 인증 도구(LDAP, Kerberos)를 연결하는 기능
• 접근의 역할 모델;
• 감사 기능;
• 디스크의 데이터 암호화;
• 네트워크를 통한 전송 중 암호화(TLS)
• 관리자의 데이터 보호.

성능 시험

이와 별도로, 귀하가 수행하지 않은 부하 테스트 결과를 논거로 사용하지 말 것을 경고하고 싶습니다.

첫째, 테스트 중인 애플리케이션의 데이터 구조와 로드 프로필이 해결하려는 문제와 크게 다를 수 있습니다. 약 10~15년 전에는 데이터베이스 공급업체가 TPC 테스트에서 얻은 결과를 과시하는 것을 좋아했지만 지금은 누구도 이러한 결과를 진지하게 받아들이지 않는 것 같습니다.

둘째, 시스템 성능은 코드가 원래 작성된 플랫폼과 테스트가 수행된 장비에 따라 크게 달라집니다. 저는 Oracle을 PostgreSQL과 비교하는 많은 테스트를 보았습니다. 그 결과는 한 시스템의 무조건적인 우월성에서부터 다른 시스템의 동등하게 무조건적인 우월성까지 다양합니다.

그리고 마지막으로, 세 번째로, 누가 테스트를 했는지에 대해 아무것도 모릅니다. 두 자격 모두 중요하며 OS 및 플랫폼 설정 품질뿐만 아니라 다른 모든 요소를 ​​합친 것보다 테스트 결과에 더 많은 영향을 미치는 동기에 영향을 미칩니다.

성능이 중요한 요소인 경우 가급적 생산 시스템을 구성하고 유지 관리할 사람들의 도움을 받아 직접 테스트를 수행하십시오.

결과

마지막으로, 수행된 모든 작업의 ​​결과는 모든 추정치가 결합되고, 곱해지고, 요약되는 스프레드시트가 되어야 합니다.

아시다시피 척도를 변경하고 등급을 조정하면 원하는 결과를 얻을 수 있지만 이는 완전히 다른 이야기입니다...

출처 : habr.com