Oracle と Redis のどちらが優れているか、またはプラットフォームの選択を正当化する方法

- まあまあ...

ユーリ・ドゥボフ「小さな悪」

このような見出しを見たら、おそらくこの記事は愚かか挑発的だと判断したでしょう。しかし、結論を急ぐ必要はありません。大企業、特に国が関与する企業の従業員は、見出しにあるような全く異なるプラットフォームも含め、様々なプラットフォームを比較検討しなければならないことがよくあります。

もちろん、DBMSの長所と短所はよく知られているため、このように比較する人はいません。一般的に、何らかの応用問題を解決するプラットフォームが比較の対象となります。この記事では、Habr読者にとって馴染みのあるデータベースを例に、このケースで用いられる方法論を示します。

動機

学習や趣味のプロジェクトを始めるとき、プラットフォームを選択する動機は非常に多様です。「このプラットフォームを最もよく知っている」、「これを理解することに興味がある」、「ドキュメントが最も優れている」など...営利企業の場合、選択基準は1つです。いくら支払う必要があり、そのお金で何が得られるのかということです。

当然のことながら、より少ない費用でより多くのものを手に入れたいと考えるでしょう。しかし、より少ない費用でより多くのものを手に入れることと、より少ない費用でより多くのものを手に入れることのどちらが重要かを判断し、各ノードに重みを割り当てる必要があります。例えば、高品質なソリューションが安価なソリューションよりも重要であると仮定すると、「コスト」ノードに40%、「機能」ノードに60%の重みを割り当てます。

大企業では通常、逆の傾向が見られます。つまり、コストウェイトは50%を下回ることはなく、60%を超えることもあります。このモデル例では、親ノードの子ノードのウェイトの合計が100%であることが重要です。

カットオフ条件

サイト db-engines.com 既知のデータベース管理システムは約500種類あります。当然のことながら、これほど多くの選択肢の中から対象プラットフォームを選択すると、レビュー記事は掲載されるかもしれませんが、商用プロジェクトは掲載されません。選択肢を絞り込むために、カットオフ基準が策定されており、プラットフォームがこれらの基準を満たさない場合は、対象から除外されます。

カットオフ基準は、次のような技術的特徴に関連している場合があります。

• ACID 保証;
• リレーショナルデータモデル。
• SQL 言語のサポート (これは「リレーショナル モデル」と同じではないことに注意してください)。
• 水平スケーラビリティ機能。

一般的な基準は次の通りです:

• ロシアにおける商業的サポートの利用可能性。
• オープンソース;
• プラットフォームが通信省の登録簿に記載されていること。
• プラットフォームが何らかの評価にランクインしていること（たとえば、db-engines.com の評価で上位 100 位内）。
• 市場における専門家の存在（たとえば、hh.ru ウェブサイトの履歴書にあるプラットフォーム名の検索結果に基づく）。

最後に、企業固有の基準がある場合があります。

• スタッフに専門家がいるかどうか
• すべてのサポートが結びついている監視システム X またはバックアップ システム Y との互換性…

最も重要なのは、カットオフ基準のリストを用意することです。そうでなければ、経営陣から特別な信頼を得ている専門家（あるいは「エキスパート」）が必ず現れ、「なぜZプラットフォームを選ばなかったんだ？最高なのは分かっているのに」と言うでしょう。

コスト評価

ソリューションのコストは、当然のことながら、ライセンスのコスト、サポートのコスト、機器のコストで構成されます。

システムがほぼ同じクラス（たとえば、Microsoft SQL Server と PostgreSQL）である場合、単純化のために両方のソリューションに必要な機器の量はほぼ同じであると想定できます。これにより機器の評価が不要になり、時間と労力を大幅に節約できます。一方、完全に異なるシステム（たとえば、Oracle と Redis）を比較する必要がある場合、正確な評価にはサイジング（機器の量の計算）が必要であることは明らかです。存在しないシステムのサイジングは非常に手間のかかる作業であるため、このような比較は避けようとします。これは簡単に実行できます。データ損失ゼロとリレーショナルモデルをカットオフ条件に記述するか、その逆（50秒あたりXNUMX万トランザクションの負荷）を記述します。

ライセンスを評価するには、ベンダーまたはそのパートナーに、固定コア数のライセンスと固定期間のサポート費用を問い合わせるだけで十分です。企業は通常、ソフトウェアベンダーと既に緊密な関係を築いており、DB運用部門が単独で費用に関する質問に答えられない場合は、1通の手紙で十分な情報を得ることができます。

ベンダーによって、コア数、データ量、ノード数など、ライセンスのメトリックが異なる場合があります。スタンバイデータベースは無料の場合もあれば、メインデータベースと同じライセンス体系の場合もあります。メトリックに違いが見つかった場合は、モデルスタンドを詳細に記述し、スタンドのライセンスコストを計算する必要があります。

正しい比較を行う上で重要なポイントは、サポート条件が同じであることです。例えば、Oracleのサポートは年間ライセンス費用の22%かかりますが、PostgreSQLのサポートは無料です。このような比較は正しいのでしょうか？いいえ、そうではありません。なぜなら、自分で解決できないエラーは、全く異なる結果をもたらすからです。前者の場合はサポートスペシャリストが迅速に解決を支援しますが、後者の場合は、プロジェクトの遅延や、完成したシステムの無期限のダウンタイムのリスクがあります。

計算条件を均一化するには、次の 3 つの方法があります。

1. サポートなしで Oracle を使用します (これは現実には起こりません)。
2. PostgreSQL のサポートを購入します（例：Postgres Professional）。
3. サポート不足に関連するリスクも計算に含めます。

例えば、リスク計算は次のようになります。修復不可能なデータベース障害が発生した場合、システムのダウンタイムは1営業日となります。システム利用による計画利益は年間40億モンゴル・トゥグルグ、事故率は1/400と推定されるため、サポート不足のリスクは年間約100億モンゴル・トゥグルグと推定されます。もちろん、「計画利益」と「推定事故率」は仮想的な値ですが、モデルが全くない場合よりも、このようなモデルを用意する方がはるかに効果的です。

実際には、システムの重要性が高すぎて、長時間のダウンタイムによる評判の失墜が許容できないため、サポートが必要になる場合があります。ダウンタイムが許容できる場合は、サポートを中止することがコスト削減につながる場合もあります。

すべての計算結果を踏まえ、プラットフォームAの5年間の運営コストが800億モンゴル・トゥグルグ、プラットフォームBの運営コストが650億600万トゥグルグ、プラットフォームCの運営コストが0.75億トゥグルグだと仮定しましょう。勝者であるプラットフォームCは、そのコストに対して満点のポイントを獲得し、プラットフォームAとBは、コストの何倍も高いかに応じて、わずかに低いポイントを獲得します。この場合、それぞれ0.92ポイントとXNUMXポイントです。

機会アセスメント

能力評価は多くのグループに分割されますが、その数は評価者の想像力によってのみ制限されます。最適な方法は、能力を、それらを使用するチームごとに分割することです。この例では、開発者、管理者、情報セキュリティ担当者です。これらの機能の重み付けが40:40:20と配分されていると仮定しましょう。

開発機能には以下が含まれます。

• データ操作の容易さ
• スケーリング;
• 二次インデックスの存在。

基準のリストとその重み付けは非常に主観的です。同じ問題を解決する場合でも、これらのリスト、項目の重み付け、そして答えは、チームの構成によって大きく異なります。例えば、Facebookはデータの保存にMySQLを使用し、InstagramはCassandra上に構築されています。これらのアプリケーションの開発者がそのようなテーブルを埋めた可能性は低いでしょう。マーク・ザッカーバーグは本格的なリレーショナルモデルを選択し、シャーディングを適用する必要性を代償に、ケビン・シストロムはプラットフォームによるスケーリングを優先し、データアクセスの利便性を犠牲にしたと推測するしかありません。

管理機能には以下が含まれます。

• バックアップシステムの機能。
• 監視の容易さ
• 容量管理の容易さ（ディスクとノード）
• データ複製機能。

質問の文言は定量的な評価を可能にするものでなければなりません。特定の機能の評価方法についても合意を得ることが可能です。例えば、Oracle DBMSに付属するツールを例に挙げて、バックアップツールを評価してみましょう。

ツール
コメント
評価

輸入/輸出
データのアップロードとダウンロード
0.1

バックアップの開始/終了
ファイルのコピー
0.3

マン
増分コピー機能
0.7

ZDLRA
増分バックアップのみ、ポイントへの最速の復元
1.0

明確な評価基準がない場合は、複数の専門家に評価を依頼し、その平均を出すのが合理的です。

最後に、情報セキュリティ機能をリストアップしてみましょう。

• パスワード管理ポリシーの可用性。
• 外部認証ツール (LDAP、Kerberos) に接続する機能。
• ロールベースのアクセスモデル。
• 監査機能
• ディスク上のデータの暗号化。
• トランスポート層セキュリティ (TLS)
• 管理者からのデータ保護。

性能試験

また、自分で実行していない負荷テストの結果を引数として使用しないよう警告しておきます。

まず、テスト対象となるアプリケーションのデータ構造と負荷プロファイルは、実際に解決しようとしているタスクとは大きく異なる可能性があります。10～15年前、データベースベンダーはTPCテストの結果を誇示することに夢中でしたが、今では誰もこれらの結果を真剣に受け止めていないようです。

第二に、システムパフォーマンスは、コードが元々書かれたプラットフォームとテストが行​​われたハードウェアに大きく依存します。OracleとPostgreSQLを比較したテストを数多く見てきましたが、結果は、どちらかのシステムが絶対的に優れているという結果から、もう一方のシステムが同様に絶対的に優れているという結果まで、実に様々です。

そして最後に、3つ目は、誰がテストを実施したかが全く分からないことです。資格とモチベーションはどちらも重要で、OSとプラットフォーム設定の品質に影響を与えます。そしてモチベーションは、他のすべての要素を合わせたよりもテスト結果に大きな影響を与えます。

パフォーマンスが重要な要素である場合は、できれば実稼働システムをセットアップおよび保守する専門家の協力を得て、自分でテストを実行してください。

結果

最後に、すべての作業の結果として、すべての成績が要約され、乗算され、合計されたスプレッドシートが作成されます。

ご存知のとおり、重みを変更して推定値を調整することで、望ましい結果を得ることができますが、それはまったく別の話です…

出所： habr.com