TencentDB for MySQL は、現在、MySQL 8.0、MySQL 5.7、MySQL 5.6、MySQL 5.5をサポートしています。各バージョンに関する特性は、公式ドキュメントをご参照ください。MySQL 公式によるサービスのライフサイクルに対するサポートポリシーは次となります。
Release | GA Date | Premier Support End | Extended Support End | Sustaining Support End |
---|---|---|---|---|
MySQL Database 5.0 | Oct-05 | Dec-11 | Not Available | Indefinite |
MySQL Database 5.1 | Dec-08 | Dec-13 | Not Available | Indefinite |
MySQL Database 5.5 | Dec-10 | Dec-15 | Dec-18 | Indefinite |
MySQL Database 5.6 | Feb-13 | Feb-18 | Feb-21 | Indefinite |
MySQL Database 5.7 | Oct-15 | Oct-20 | Oct-23 | Indefinite |
MySQL Database 8.0 | Apr-18 | Apr-23 | Apr-26 | Indefinite |
説明:
- MySQL 5.5の公式によるサービス延長期間は2018年12月まででしたが、期限切れ後に、サービスのサポートに関する明確な説明がありません。恐らくトラブルシューティングの周期が長かったためと思われます。より高いバージョンのMySQLを使用することをお勧めします。
- MySQL 5.6 およびそれ以上のバージョンは MyISAM ストレージエンジンをサポートしていません。より性能が良く、より安定した InnoDB エンジンのご利用をお勧めします。
- MySQL 5.6およびそれ以上の バージョンは3種類のレプリケーション方式(非同期、半同期、強い同期)をサポートしています。5.5バージョンは非同期モードをサポートしています。
比較項目 | TencentDB for MySQL 8.0 | Oracle MySQL 8.0 |
---|---|---|
費用対効果 | 1. 弾力性のあるリソース。 2. TXSQL 自社開発カーネル。 3. 統合化されたバックアップとリストア。 4. 完備されたSaaSツールによるサービス。 |
1. 1回の投資コストが膨大。 2. オープンソース版には性能の最適化がない。 3. バックアップリソースの単独のデプロイは別途コストが必要。 4. パブリックネットワークのトラフィック料金、ドメイン名費用が高い。 |
可用性 | 1. 完備されたHA切り替えシステム。 2. 読み取り専用インスタンスは、自動的に負荷とトラフィックのバランスを取ります。 3. ディザスタリカバリインスタンスが提供され、高可用性が保証されます。 |
1. サーバーの独自購入は、割り振りサイクルを待つ必要がある。 2. 高可用性システムとロードバランサシステムは別々にデプロイ。 3. 多地点マルチセンターはクロスリージョンデータセンターの構築が必要でコスト高。 |
信頼性 | 1. データの信頼性は99.9996%。 2. RPO、RTOが低い。 3. 安定したマスター/スレーブのデータレプリケーション。 |
1. データの信頼性は99%、単独ブロックの損害の確率によって決まる。 2. 低 RPO実現のコストが高く、単独の開発費用が必要。 3. データレプリケーションのディレー、レプリケーション中断。 |
使いやすさ | 1. データベースの管理制御が完備され、コンソールの操作が簡単。 2. 秒単位のモニタリング + インテリジェントアラーム。 3. クロスAZ(アベイラビリティーゾーン)の自動 HA(高可用性)機能。 4. バージョンのアップグレードが1つの操作で完了。 |
1. HAとバックアップリカバリシステムを単独でデプロイし、時間と手間がかかる。 2. 監視システムの単独購入で、費用を別途投じる必要がある。 3. クロスリージョンデータセンター構築のコストは大きく、運用保守に人材を投じる必要がある。 4. バージョンアップのコストが高く、マシンを停止してメンテナンスする時間も長い。 |
性能 | 1.ローカルの SSDストレージの性能が極めて優秀、カスタムハードウェアは反復をサポート。 2. TXSQL カーネルの最適化により性能を保障。 3.DBbrainインテリジェント診断、MySQLの性能を最適化。 |
1. クラウドコンピューティングのハードウェア反復速度に追いつけない、一般的に性能はクラウドより劣る。 2.ベテランのデータベース管理者に依存するため、支出が大きい。 3. 対応する機能のツールが乏しく、別途購入またはデプロイする必要がある。 |
セキュリティ | 1. 事前の予防保護:ホワイトリスト、セキュリティグループ、プライベートネットワークによる分離。 2. 事中の保護:TDE + KMS データ暗号化。 3. 事後の監査:SQL 監査。 4. 公式版のセキュリティが更新されると、カーネルチームが同時にフォローアップ。 |
1. ホワイトリストの設定コストが高く、専用ネットワークの実現には自主的なデプロイが必要。 2. 事中には暗号化機能を単独で実現する必要がある。 3. 事後の監査が困難。オープンソース版には SQL監査機能がない。 4. バージョン更新後、運用保守にパッチの挿入またはマシン停止によるメンテナンスが必要。 |
この記事はお役に立ちましたか?