MySQL 데이터베이스를 호스팅 하는 5 가지 방법
본문
프로젝트에 대해 MySQL 서버를 설치하고 실행하는 방법에는 여러 가지가 있습니다. 서버 인스턴스를 직접 설치 및 관리하거나 관리형 MySQL 액세스를 제공하는 여러 공급자 중 하나를 활용할 수 있습니다.
이 기사에서는 MySQL 서버의 가장 일반적인 옵션 중 일부를 살펴보고 장점과 과제를 비교합니다. 프로젝트와 팀의 우선 순위를 파악하면 필요에 맞는 솔루션을 찾을 수 있습니다.
자체 관리형 MySQL
가장 유연하고 설명하기 가장 간단한 옵션은 MySQL 서버를 자체 호스팅하는 것입니다. 셀프 호스팅 MySQL은 다른 소프트웨어와 마찬가지로 사용자가 제어하는 컴퓨터에 데이터베이스를 설치하고 구성하는 것을 의미합니다.
셀프 호스팅은 데이터베이스를 설치하고 실행할 위치에 대한 많은 선택권을 제공합니다. 이 섹션의 옵션 중 하나를 선택하면 이 가이드를 사용하여 시스템에 MySQL을 설치하는 방법을 배울 수 있습니다.
로컬 개발 컴퓨터에 MySQL 설치
초기 개발, 테스트 및 개념 증명을 위해 로컬 개발 시스템에 MySQL을 설치하면 데이터베이스에 대한 안정적이고 관리하기 쉬운 액세스를 제공 할 수 있습니다.
Hosting Option |
Local development machine |
Project stage |
Development |
Cost |
No additional costs |
Performance |
Low |
Scalability |
None |
Management complexity |
Low |
Additional notes |
Does not require network configuration. Good for local development. |
Cost
개발 컴퓨터에서 MySQL을 설정하는 것은 무료입니다. 개발하면서 이미 활성화 된 컴퓨터에서 데이터베이스를 실행하고 있습니다. MySQL이 가동 및 실행될 때 소비 할 리소스의 양만 고려하면 됩니다.
Performance
개발 컴퓨터에 MySQL을 설치하는 것은 성능이 낮은 옵션입니다.
다른 사용자가 데이터베이스를 쉽고 안정적으로 사용할 수 없습니다. 데이터베이스 사용은 하드웨어와 MySQL을 위해 예비 할 수 있는 리소스의 양에 따라 제한됩니다. 이러한 문제는 로컬에서 테스트하거나 개발할 때 일반적으로 문제가 되지 않지만 더 복잡한 작업에는 전혀 부적절합니다.
Scalability
개발 머신에서 호스팅 하면 확장성이 거의 없습니다. MySQL에 할당 된 리소스의 양을 변경할 수 있지만 그 이상은 아닙니다. 개발 머신을 업그레이드 할 수 있지만 장기적으로는 실용적이거나 특히 유용하지 않습니다.
Management complexity
복잡성 측면에서 로컬 컴퓨터에서 MySQL을 호스팅 하는 것은 매우 간단합니다. 대부분의 운영 체제에 대한 설치 프로세스는 잘 고려되어 있으며 결과 데이터베이스를 쉽게 시작하거나 중지 할 수 있습니다. 외부 액세스를 위해 로컬 MySQL 인스턴스를 구성하는 것은 일반적으로 리소스 제한과 소비자 네트워크 불안정성을 고려할 때 그만한 가치가 없습니다.
MySQL을 로컬로 설정하는 것은 복잡하지 않지만 데이터베이스를 관리하고 필요에 따라 업그레이드를 수행해야 합니다. 보안 패치에 가끔 필요할 수 있으며 데이터에 대해 우려되는 경우 이러한 인스턴스를 추적하는 것은 귀하의 책임입니다.
추가 참고 사항
로컬로 설치하면 네트워크가 다운 된 경우에도 개발 컴퓨터에서 데이터베이스에 액세스 할 수 있습니다. 이것은 여행 할 때 특히 도움이 될 수 있습니다. 데이터에 로컬로 액세스하면 네트워크 복잡성이 제거되므로 데이터베이스 액세스 대신 개발에 집중할 수 있습니다.
로컬 개발 컴퓨터에 MySQL을 설치하는 것은 유용하지만 몇 가지 분명한 제한 사항이 있습니다. 다중 사용자 액세스를 쉽게 구성 할 수 없으며 데이터베이스 가동 시간은 컴퓨터의 가용성 및 네트워크 안정성과 직접적으로 연결됩니다. 이러한 이유로 개발 컴퓨터에 설치하는 것은 거의 항상 유일한 데이터베이스 설치가 아니라 생산성과 유연성을 높이기 위한 추가 옵션입니다.
별도의 서버에 MySQL 설치
또 다른 자체 호스팅 옵션은 별도의 컴퓨터에 MySQL을 설치하고 관리하는 것입니다. 몇 가지 일반적인 구현은 다음과 같습니다.
- 전용 서버에 설치 : MySQL은 전용 컴퓨터에서 실행되는 유일한 서비스로 구성됩니다. 컴퓨터의 모든 리소스에 액세스 할 수 있습니다.
- 관련 애플리케이션과 함께 설치 : MySQL이 필요한 애플리케이션과 함께 설치됩니다. 모든 구성 요소를 단일 시스템에서 관리 할 수 있으므로 소규모 배포에 널리 사용됩니다. 컴퓨터의 리소스는 MySQL과 실행 중인 다른 응용 프로그램간에 공유되어야 합니다.
별도의 서버에 MySQL을 설치하는 것은 개발 컴퓨터에 설치하는 것과 매우 다릅니다.
Hosting Option |
Separate server |
Project stage |
Development, staging, production |
Cost |
Variable. Purchase or rental of an additional server plus additional management costs. |
Performance |
높은 잠재력 |
Scalability |
높은 잠재력 |
Management complexity |
High |
추가 참고 사항 |
가장 유연한 옵션입니다. 또한 가장 큰 실무 관리의 양. 다음과 같은 경우 좋은 선택입니다. 사내에 하드웨어 또는 데이터베이스 전문 지식이 있습니다. 관리에 전념 할 수 있습니다. |
더 강조해야 할 한 가지 고려 사항은 MySQL을 직접 관리 할 때 보안이 귀하의 책임이라는 것입니다. 이미 인프라, 소프트웨어 및 네트워크 보안을 조직의 다른 부분에서 처리하고 있다면 이는 문제가 되지 않을 수 있습니다. 하지만 익숙하지 않은 경우 MySQL 인스턴스와 여기에 보관 된 데이터를 보호하는 것이 큰 도전이 될 수 있습니다. 이 경로를 선택하기 전에 계획에 이것을 고려하십시오.
Cost
전용 또는 공유 컴퓨터에서 MySQL을 실행하려면 사용할 서버 공간을 구입하거나 임대해야 합니다. 실제 서버는 조직의 온 프레미스에 있거나 데이터 센터에 배치되거나 클라우드 공급자가 호스팅 하는 가상 머신 (가상 사설 서버 또는 VPS라고도 함)으로 운영 될 수 있습니다.
서버 비용은 매우 다양 할 수 있습니다. 저전력 VPS는 매우 저렴할 수 있지만 여러 전용 서버는 빠르게 비용이 많이 듭니다. 그러나 서버 비용이 유일한 고려 사항은 아닙니다. 추가 관리 비용도 고려해야 합니다. 배포 환경에 따라 여기에는 데이터베이스 계층, 서버의 소프트웨어 및 하드웨어를 관리하기 위한 인건비가 포함될 수 있습니다. 이러한 비용은 가용성 요구 사항, 호스팅 환경 및 운영 규모에 따라 달라집니다.
Performance
별도의 서버에 MySQL을 배포하면 매우 높은 성능을 얻을 수 있습니다. MySQL을 실행할 머신의 사양은 사용자가 제어 할 수 있으므로 필요에 맞는 하드웨어를 선택할 수 있는 완전한 유연성이 있습니다. 향후 확장이 필요한 경우 하드웨어를 업그레이드하거나 추가 서버를 구입하여 워크로드를 확장 할 수 있습니다.
또한 추가 성능 이점을 얻기 위해 데이터베이스 구성을 미세 조정할 수 있습니다. 메모리 관리, 캐싱, 열린 파일 처리, 클라이언트 연결 등과 관련된 설정을 조정할 수 있습니다. 이것은 많은 힘을 제공하지만 이러한 옵션을 활용하려면 시간, 전문 지식 및 실험이 필요합니다. 자체 서버를 실행하는 다른 측면과 마찬가지로 이점은 프로젝트의 이러한 측면에 할당 할 수 있는 시간과 비용에 의해 제한됩니다.
Scalability
위에서 언급했듯이 전용 서버에서 실행하면 데이터베이스 시스템의 변화하는 요구에 대응할 수 있습니다. 데이터베이스 서버에 추가 리소스와 하드웨어를 추가하여 확장하거나 MySQL 서버 풀에서 요청의 균형을 조정하여 확장 할 수 있습니다. 두 옵션 모두 다양한 유형의 스트레스에 대한 합리적인 반응입니다.
Management complexity
일반적으로 확장은 성능 튜닝과 동일한 장점과 한계를 가지고 있습니다. 놀라운 유연성과 성능을 가지고 있지만 비용과 구성을 관리해야 합니다. 추가 하드웨어가 필요한 변경 (예 : 수요 증가)은 조직이 하드웨어를 조달하고, 소프트웨어를 구성하고, 워크로드의 균형을 맞추는 데 시간을 할애 할 수 있도록 사전 모니터링과 결합되어야 합니다.
추가 참고 사항
요약하면 자체 MySQL을 관리하는 것은 매우 효율적이고 강력하며 유연 할 수 있지만 많은 전용 시간과 리소스가 필요할 수 있습니다. 이 옵션은 데이터베이스의 런타임 환경, 구성 및 아키텍처 토폴로지를 제어하려는 내부 인프라 및 서버 전문 지식을 갖춘 조직에 가장 적합합니다.
Docker를 사용한 MySQL
또 다른 자체 호스팅 옵션은 Docker를 사용하여 MySQL을 컨테이너로 실행하는 것입니다. Docker를 사용하면 로컬 또는 원격 머신의 격리 된 환경에서 MySQL을 실행할 수 있습니다.
Hosting Option |
Docker containers |
Project stage |
Development, staging, production |
Cost |
Variable. Purchase or rental of an additional server plus additional management costs. |
Performance |
Medium-High |
Scalability |
High |
Management complexity |
Medium-High |
추가 참고 사항 |
Containerized infrastructure can vary dramatically in terms of complexity. While containers make many things easier, especially during development and staging, they also require experience and complex orchestration to run well in production. For production workloads, containers are likely only a good choice if you are already invested in container orchestration like Kubernetes. |
기존 로컬 설치에 비해 Docker를 사용하면 다음과 같은 이점이 있습니다.
- 공식 MySQL Docker 이미지로 MySQL을 실행하면 MySQL을 설치하는 것보다 적은 노력이 필요합니다.
- Docker를 사용하면 여러 환경에서 정확히 동일한 데이터베이스 구성을 재현 할 수 있으므로 동일한 MySQL 구성이 필요한 프로젝트에서 공동 작업하는 팀에 유용합니다.
- Docker를 사용하여 MySQL에 할당 된 CPU, 메모리 및 스토리지 리소스를 제어 할 수 있습니다.
- Docker는 MySQL과 컴퓨터에서 실행중인 다른 소프트웨어 간의 비 호환성 가능성을 줄입니다.
프로덕션 워크로드에 MySQL을 사용하는지 여부에 따라 몇 가지 추가 고려 사항이 있지만 Docker와 함께 MySQL을 로컬 또는 원격 머신에 설치하는 것은 비슷합니다.
Docker는 MySQL 실행의 특정 측면을 단순화하지만 알아야 할 몇 가지 장단점이 있습니다.
- 구성에 따라 Docker로 실행하면 네트워크 구성의 복잡성이 증가 할 수 있습니다.
- Docker는 추가적인 보안 고려 사항이 필요하고 문제 해결을 덜 직접적으로 만들 수 있는 추가적인 추상화 계층을 추가합니다.
컨테이너 및 Kubernetes
Kubernetes를 사용하면 여러 서버로 구성된 클러스터에서 Docker 컨테이너를 실행할 수 있습니다. 유지 관리를 위해 클러스터의 한 서버를 중단 해야하는 경우 Kubernetes는 기본 데이터 파티션에 액세스 할 수 있는 한 MySQL 컨테이너를 다른 서버로 이동합니다. 또한 Kubernetes에서 MySQL을 사용하는 애플리케이션을 실행하여 애플리케이션과 MySQL 간의 네트워크 지연 시간을 줄일 수 있습니다.
관리형 서비스
MySQL을 직접 실행하는 것의 대안은 공급자로부터 MySQL 데이터베이스를 대여하거나 구입하는 것입니다. 관리형 서비스를 사용하면 MySQL 소프트웨어 또는 기본 서버의 배후 관리에 대해 걱정할 필요 없이 서비스 또는 API로 데이터베이스를 쉽게 사용할 수 있습니다.
다양한 요구 사항을 충족하기 위해 다양한 유형의 관리 서비스가 존재합니다. 이 섹션에서는 호스팅 또는 클라우드 제공 업체에서 제공하는 서비스, 타사 관리 데이터베이스 및 애플리케이션 플랫폼에서 제공하는 데이터베이스를 다룹니다.
클라우드 공급자가 관리하는 데이터베이스
아마도 가장 친숙한 관리형 MySQL 호스팅 유형은 클라우드 또는 호스팅 제공 업체에서 제공하는 유형일 것입니다. 이러한 예로는 Amazon Web Service의 RDS (관계형 데이터베이스 서비스), Google Cloud Platform의 Cloud SQL 및 Azure Database가 있습니다.
Hosting Option |
Cloud provider-managed |
Project stage |
Development, staging, production |
Cost |
Highly variable, depending on your selections and usage. |
Performance |
Highly variable |
Scalability |
High |
Management complexity |
Low |
추가 참고 사항 |
A highly scalable solution often offered by the same cloud provider that can run your applications. This allows for additional control over networking and performance without the heavy lifting of running your own servers. |
클라우드 제공 업체는 데이터 센터에서 실행되고 다른 서비스와 원활하게 작동하도록 미세 조정 된 다양한 MySQL 데이터베이스를 제공합니다.
Cloud providers
다음 클라우드 제공 업체는 필요에 따라 구매, 구성 및 확장 할 수 있는 관리 형 MySQL 데이터베이스를 제공합니다.
서버와 대부분의 MySQL은 호스팅 제공 업체에서 관리하며 확장 옵션을 설정하고 설정을 조정하고 액세스를 관리 할 수 있습니다. 인터넷에서 연결할 수 있도록 데이터베이스를 구성하거나 동일한 공급자가 관리하는 애플리케이션에 직접 연결할 수 있습니다.
Cost
클라우드 제공 업체가 관리하는 MySQL 데이터베이스에는 다양한 비용이 발생할 수 있습니다. 저가형에서는 일부 제공 업체가 최소한의 성능과 가동 시간으로 무료 계층을 제공합니다. 하이 엔드에서 모든 수요를 충족하기 위해 자동으로 확장하면 예기치 않은 트래픽 급증이 발생할 경우 밤새 수천 달러의 비용이 발생할 수 있습니다. 클라우드에 있는 대부분의 항목과 마찬가지로 실제 사용량은 매월 청구서에 영향을 미칩니다. 많은 클라우드는 사용량 / 비용이 특정 지점을 초과하는 경우 비용 경고 또는 자동 끄기를 제공합니다. 사용량을 모니터링하고 컷오프를 구성하여 데이터베이스 시스템의 운영 비용을 관리하는 것이 중요합니다.
Scalability
비용을 예측하기 어려울 수 있지만 새로운 장점은 클라우드에서 확장이 매우 쉽다는 것입니다. 데이터베이스에 할당 된 리소스는 즉석에서 구성 할 수 있습니다. 즉, 계정의 설정을 변경하는 것만으로 스토리지 용량, 메모리 및 컴퓨팅 성능 또는 데이터를 관리하는 복제본 수를 늘릴 수 있습니다. 신중하게 구성하지 않으면 높은 비용에 기여할 수 있는 강력한 기능 중 하나는 현재 수요에 따라 데이터베이스 리소스를 동적으로 확장 할 수 있는 기능입니다. 이를 통해 비용을 충당 할 수 있다는 가정하에 항상 요구 사항을 충족 할 수 있는 능력을 가질 수 있습니다.
Performance
확장성과 관련하여 성능은 클라우드에서 매우 유연한 또 다른 영역입니다. 종종 사용 패턴에 따라 데이터베이스 성능에 가장 큰 영향을 미치는 설정을 미세 조정할 수 있습니다. 현재 구성이 부족한 경우 추가 리소스를 할당 할 수도 있습니다. 데이터베이스를 사용하는 애플리케이션과 함께 배치하면 데이터베이스와 애플리케이션 간의 우수한 네트워킹 성능을 얻을 수 있습니다.
Management complexity
관리 복잡성 측면에서 클라우드 호스팅 데이터베이스는 매우 간단합니다. 귀하는 귀하를 위한 대부분의 관리 부담을 제공자에게 지불하고 있습니다. 여전히 계정과 데이터베이스에 영향을 미치는 설정을 제어해야 하는 동안 하드웨어, 운영 체제 및 대부분의 MySQL 구성이 자동으로 처리됩니다. 이는 데이터베이스 사용으로 인한 관리 오버 헤드를 줄이는 데 큰 영향을 미칠 수 있지만 일부 특수한 경우 원하는 튜닝 수준에 액세스하지 못할 수도 있습니다.
추가 참고 사항
일반적으로 클라우드 공급자가 관리하는 MySQL 데이터베이스에 대한 비용을 지불하는 것은 일반적으로 매력적인 옵션입니다. 적은 양의 관리 작업으로 확장 및 성능 측면에서 뛰어난 유연성을 제공합니다. 클라우드 제공 업체의 데이터베이스 오퍼링을 사용할 때의 단점은 특정 수준에서 다른 방식으로 지불하는 것보다 더 많은 비용을 지불하게 될 수 있다는 것입니다. 또한 도구가 공급자 별 기능에 너무 많이 의존하기 시작하면 현재 공급자에게 갇힐 위험이 있습니다.
타사 관리 데이터베이스
클라우드 제공 업체에서 직접 데이터베이스를 구매하는 대신 타사 제공 업체를 통해 데이터베이스를 관리하도록 선택할 수 있습니다. 대부분의 경우 이 옵션은 기본 리소스 공급자로부터 데이터베이스 관리를 분리하여 선택한 클라우드 또는 클라우드에 데이터베이스를 배포 및 관리합니다.
Hosting Option |
Third party-managed |
Project stage |
Development, staging, production |
Cost |
Highly varied, depending on your selections and usage. |
Performance |
Highly variable |
Scalability |
High |
Management complexity |
Low |
추가 참고 사항 |
Third party managed databases have many of the same benefits as cloud provided databases. However, by managing your databases through a third party, you can decouple the database management from the underlying cloud provider. This can make it easier to migrate to a different host in the future and can sometimes allow for more powerful management options. |
타사 공급자가 관리하는 데이터베이스는 종종 클라우드 공급자가 제공하는 것과 동일한 기본 구성 요소를 사용합니다. 그러나 타사 제공 업체는 종종 여러 클라우드로 작업하고, 계정에서 리소스를 가동하고, 원하는 경우 낮은 수준의 액세스를 제공하는 경우가 많습니다. 클라우드 공급자가 제공하는 데이터베이스를 사용하는 대신 서비스는 공급자에서 가상 서버를 시작하고 이를 사용하여 MySQL을 설치 및 구성합니다. 운영 체제에서 설정을 조정하고 인스턴스를 호스팅 하는 서버에 대한 액세스를 제공 할 수 있습니다. 타사 MySQL 공급자의 예로는 현재 4 개의 다른 클라우드에서 인스턴스를 관리 할 수 있는 ScaleGrid가 있습니다.
Third-party offerings
다음 타사 제공 업체는 필요에 따라 구매, 구성 및 확장 할 수 있는 관리 형 MySQL 데이터베이스를 제공합니다.
서버와 대부분의 MySQL은 공급자가 관리하며 데이터베이스가 실행되는 클라우드 플랫폼, 확장 옵션, 설정 조정 및 액세스 관리를 설정할 수 있습니다. 인터넷에서 연결할 수 있도록 데이터베이스를 구성하거나 동일한 공급자가 관리하는 애플리케이션에 직접 연결할 수 있습니다.
Cost
비용 측면에서 타사 솔루션도 종종 매우 가변적입니다. 사용자는 배포하는 클라우드의 컴퓨팅 리소스와 데이터베이스 관리 서비스에서 부과하는 관리 비용을 지불해야 합니다. 관리 형 데이터베이스 대신 더 많은 기본 리소스에 대해 클라우드 공급자에게 비용을 지불하기 때문에 해당 측면의 비용이 더 적을 수 있습니다. 그러나 관리 서비스와 관련된 비용으로 인해 일부 가격대에서 누적 비용이 증가 할 수 있습니다. 총 비용을 결정하기 위해 각 측면이 다른 수준에서 어떻게 확장되는지 파악해야 합니다.
Performance
데이터베이스의 성능 특성도 크게 다를 수 있습니다. 관리 서비스가 클라우드의 컴퓨팅 인스턴스에 설치되므로 공급자는 MySQL 설정 외에도 서버 구성을 조정할 수 있습니다. 즉, 사용자의 요구에 보다 합리적으로 일치하도록 일부 설정을 조정할 수 있습니다.
반면에 충분히 조정하는 데 필요한 가상화 및 하드웨어 구성 요소의 하위 수준 계층에 액세스하지 못할 수 있습니다. 클라우드 공급자가 제공하는 기본 데이터베이스에 대해 성능을 테스트하는 것이 좋습니다.
Scalability
타사 관리 데이터베이스의 확장 성은 일반적으로 매우 좋습니다. 이러한 공급자는 충분한 리소스가 있는 모든 컴퓨팅 인스턴스에 배포 할 수 있기 때문에 때때로 클라우드 공급자가 노출하는 것보다 더 다양한 확장 옵션을 제공 할 수 있습니다. 확장의 이유 중 하나가 가용성을 높이는 것이라면 많은 타사 서비스가 여러 가용성 영역 또는 공급자에 걸쳐있을 수 있습니다.
Management complexity
데이터베이스 관리를 위한 타사 서비스에는 다양한 복잡성이 있습니다. 이 옵션을 사용하려면 서로 다른 두 공급자 (컴퓨팅 인스턴스를 호스팅 하는 클라우드와 데이터베이스 관리 서비스) 간의 조정이 필요하기 때문에 클라우드 공급자가 제공하는 기본 데이터베이스 서비스를 사용하는 것에 비해 본질적으로 복잡성이 증가합니다.
일부 관리 서비스는 공유 웹 호스팅과 거의 동일한 방식으로 복잡성을 숨기는 단순한 옵션으로 자리 매김합니다. 다른 솔루션은 운영 체제에 액세스 할 수 있다는 사실을 활용하여 다양한 구성 옵션을 사용자에게 노출합니다. 많은 서비스는 사용자가 원하는 수준의 복잡성을 찾을 수 있도록 두 가지 경험을 모두 제공합니다.
추가 참고 사항
기본 리소스 공급자로부터 데이터베이스 관리를 분리하면 장점과 단점이 모두 있습니다.
데이터베이스 관리 서비스가 기본 계층을 추상화 하는 경우 다른 클라우드 공급자로 마이그레이션 하는 데 더 많은 유연성을 가질 수 있습니다. 이 추상화는 또한 사용자가 편한 복잡성 수준을 선택할 수 있는 능력을 제공합니다. 데이터베이스 관리 서비스에서 제공하는 전체 추상화 및 인터페이스를 사용할 수 있지만, 프로비저닝 된 데이터베이스 서버에도 액세스 할 수 있으므로 로그인하여 적절하다고 판단되는 데이터베이스 서버를 수정할 수 있습니다. 데이터베이스 관리 서비스는 이러한 운영 체제 수준의 조정을 관리 할 수 있는 쉬운 인터페이스를 제공 할 수도 있습니다.
이 설정의 단점은 데이터베이스의 올바른 작동을 위해 여러 당사자에게 의존한다는 사실에서 비롯됩니다. 이는 서비스 중단 가능성을 높일 수 있습니다. 클라우드 공급자가 제공하는 데이터베이스 서비스에 사용할 수 있는 내부 최적화를 놓칠 수도 있습니다. 데이터베이스 관리 서비스는 클라우드 제공 업체가 노출하는 항목에만 액세스 할 수 있으며 기본 가상화 또는 하드웨어 계층을 최적화 할 수 없습니다.
전반적으로 타사 관리 서비스를 사용하는 것은 선호도와 테스트에 관한 것입니다. 성능을 테스트하고 가격 구조가 다양한 사용 수준에서 어떤 영향을 미칠 수 있는지 이해해야 합니다.
요약
여기에 설명 된 다양한 옵션이 서로 어떻게 비교 되는지에 대한 개요는 다음과 같습니다.
Hosting Option |
Local development machine |
Separate server |
Cloud provider-managed |
Third party-managed |
Application platform-managed |
Project stage |
Development |
Development, staging, production |
Development, staging, production |
Development, staging, production |
Development, staging, production |
Cost |
No additional costs |
Variable. Purchase or rental of an additional server plus additional management costs. |
Highly variable, depending on your selections and usage. |
Highly varied, depending on your selections and usage. |
Highly variable |
Performance |
Low |
High potential |
Highly variable |
Highly variable |
Highly variable |
Scalability |
None |
High potential |
High |
High |
High |
Management complexity |
Low |
High |
Low |
Low |
Low |
추가 참고 사항 |
Does not require network configuration. Good for local development. |
The most flexible option. Also requires the greatest amount of hands-on management. A good choice if you have hardware or database expertise in-house that you can devote to management. |
A highly scalable solution often offered by the same cloud provider that can run your applications. This allows for additional control over networking and performance without the heavy lifting of running your own servers. |
Third party managed databases have many of the same benefits as cloud provided databases. However, by managing your databases through a third party, you can decouple the database management from the underlying cloud provider. This can make it easier to migrate to a different host in the future and can sometimes allow for more powerful management options. |
The database services offered by application platforms are often focused on simple management and access above most other factors. The costs can vary dramatically depending on your usage, so it is important to keep an eye on how scaling and usage affect your payments. |
데이터베이스 호스팅을 위한 올바른 선택은 애플리케이션의 요구 사항, 개발 단계 및 MySQL을 직접 관리하는 능력에 따라 크게 달라집니다. 다른 선택은 특정 시간 또는 특정 조직에 더 적합하게 만드는 이러한 요소 간의 균형을 제공합니다.
https://www.prisma.io/dataguide/mysql/5-ways-to-host-mysql