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

「まあ、これは必要だ」と彼女はだれにも話しかけずに大声で言った。-まあこれは必要です！したがって、それは直接書かれています-会社の主な仕事は株主の利益のために利益を上げることです。さて、あなたは思います！彼らは何も恐れていません！



ジュリアス・デュボフ、「小悪」

そのような見出しを見て、あなたはおそらくその記事が愚かさか挑発のどちらかであるとすでに決めているでしょう。しかし、結論に急がれることはありません。大企業、特に州が参加する企業の従業員は、たとえば、タイトルにあるような完全に異なるプラットフォームを含め、さまざまなプラットフォームを比較しなければならないことがよくあります。







もちろん、DBMSの長所と短所はよく知られているため、そのようなDBMSを比較する人はいません。原則として、適用された問題を解決するプラットフォームは比較の対象となります。この記事では、Habrの読者が聞き慣れていない主題としてデータベースの例を使用して、同時に使用される手法を示します。そう、

動機

教育プロジェクトや趣味のプロジェクトを始めるとき、プラットフォームを選択する動機は非常に多様です。「私はこのプラットフォームを最もよく知っています」、「このプラットフォームを理解することに興味があります」、「ここに最適なドキュメントがあります」...商業企業の場合、選択基準は次の1つです。私はいくら払わなければならず、このお金のために何を手に入れますか。



当然、あなたはより少ない支払いでより多くを得たいと思っています。ただし、どちらがより重要であるかを決定する必要があります-支払う金額を減らすか受け取る金額を増やし、各ノードに重みを割り当てます。安価なソリューションよりも高品質のソリューションのほうが私たちにとって重要であり、「Cost」ノードに40％の重みを割り当て、「Opportunities」ノードに60％を割り当てたとします。







大企業では、通常は逆のことが当てはまります。値の重みは50％未満ではなく、おそらく60％を超えます。モデルの例では、親ノードの子ノードの総重量が100％であることだけが重要です。

カットオフ条件

約500のデータベース管理システムで知られている サイトdb-engines.com。当然のことながら、非常に多くのオプションからターゲットプラットフォームを選択すると、最終的にはレビュー記事になってしまいますが、商用プロジェクトにはなりません。選択スペースを削減するために、カットオフ基準が策定され、プラットフォームがこれらの基準を満たさない場合は考慮されません。



カットオフ基準は、次のような技術的特徴を参照できます。

• ACID保証。
• リレーショナルデータモデル;
• SQL言語サポート（注：これは「リレーショナルモデル」と同じではありません）。
• 水平スケーリングの可能性。

一般的な基準があるかもしれません：

• ロシアでの商業的支援の利用可能性。
• オープンソース;
• テレコムおよびマスコミュニケーション省の登録簿でのプラットフォームの可用性。
• ある評価（たとえば、db-engines.comの最初の100の評価）におけるプラットフォームの存在。
• 市場での専門家の可用性（たとえば、hh.ru Webサイトで履歴書でプラットフォーム名を検索した結果に基づく）。

結局、企業固有の基準があるかもしれません：

• スタッフの専門家の可用性。
• すべてのメンテナンスが関連付けられている監視システムXまたはバックアップシステムYとの互換性...

最も重要なことは、カットオフ基準のリストを用意することです。それ以外の場合は、「プラットフォームZを選択しなかった理由は何だと思いますか？」という経営陣の特別な信頼を享受する専門家（または「エキスパート」）が必ずいます。

原価見積

ソリューションのコストは、明らかにライセンスのコスト、メンテナンスのコスト、および機器のコストで構成されています。



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



ライセンスを評価するには、一定数のコアと一定期間のサポートのライセンスのコストをベンダーまたはそのパートナーに依頼するだけで十分です。原則として、企業はすでにソフトウェアベンダーと強い関係を築いており、データベース運用部門が独自にコストの質問に答えられない場合、この情報を受け取るには1通で十分です。



コアの数、データの量、ノードの数など、ベンダーによってライセンスの測定基準が異なる場合があります。スタンバイデータベースは無料にすることも、メインデータベースと同じ方法でライセンスを取得することもできます。メトリックの一部の違いのみが見つかった場合は、モデルスタンドを詳細に説明し、スタンドのライセンスのコストを計算する必要があります。



正しい比較のための重要なポイントは、同じサポート条件です。たとえば、Oracleのサポートのコストは年間ライセンス価格の22％であり、PostgreSQLのサポートは無料です。比較するのは正しいですか？いいえ、私たちだけでは解決できないエラーの影響はまったく異なります。最初のケースでは、サポートスペシャリストが迅速に修正を支援し、2番目のケースでは、プロジェクトの遅延や完成したシステムの無期限のダウンタイムのリスクがあります。



計算条件を均等化する方法は3つあります。

1. サポートなしでOracleを使用します（実際にはこれは起こりません）。
2. PostgreSQLサポートを購入します-たとえば、Postgres Professionalから。
3. サポートの不足に関連するリスクを含めます。

たとえば、リスクの計算は次のようになります。致命的なデータベース障害が発生した場合、システムのダウンタイムは1営業日になります。このシステムの使用による計画利益は年間400億モンゴルのトルコ人であり、事故の頻度は1/400と推定されています。したがって、支援の不足のリスクは年間約1億のモンゴルのトルコ人と推定されています。明らかに、「計画利益」と「推定事故率」は仮想的な量ですが、そのようなモデルがない方が、ないことよりもはるかに優れています。



実際には、システムが非常に重要であり、長時間のダウンタイムによる評判の低下は許容できないため、サポートが必要になります。ダウンタイムが許容される場合、サポートを停止することは、コストを節約するための良い方法になることがあります。



すべての計算の結果、5年間のプラットフォームAの運用コストが8億モンゴルトゥグリク、プラットフォームBの運用コスト-6億5,000万トゥグリク、プラットフォームCの運用コスト-6億トゥグリクであることがわかりました。プラットフォームCが勝者として、コストとプラットフォームAとBのフルウェイトポイントを受け取ります。プラットフォームAとBは、より高い回数に比例してわずかに少なくなります。この場合-それぞれ0.75ポイントと0.92ポイント。

機会の評価

機会の評価は多くのグループに分けられ、その数は評価を行う人の想像力によってのみ制限されます。最良のオプションは、これらの機能を使用するチームに機能を分割することです。この例では、これらは開発者、管理者、および情報セキュリティ担当者です。これらの関数の重みが40:40:20として分布していると仮定します。



開発機能は次のとおりです。

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

重みのように、基準のリストは非常に主観的です。同じ問題を解決する場合でも、これらのリスト、項目の重み、および回答は、チームの構成によって大きく異なります。たとえば、FacebookはMySQLを使用してデータを保存し、InstagramはCassandraの上に構築されています。これらのアプリケーションの開発者がそのようなテーブルに記入することはほとんどありません。Mark Zuckerbergが完全なリレーショナルモデルを選択し、適用されたシャーディングの必要性に応じて支払い、Kevin Systromがプラットフォームを使用してスケーリングを規定し、データアクセスの利便性を犠牲にしたことは推測できます。



管理機能は次のとおりです。

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

質問の文言は定量化できる必要があることに注意してください。特定の関数を評価する方法についても同意できます。たとえば、Oracle DBMSで提供されるツールの例を使用して、バックアップツールを評価してみましょう。





明確な評価基準がない場合は、何人かの専門家にマークを提供してもらい、それらを平均化することは理にかなっています。



最後に、情報セキュリティ機能の一覧を示します。

• パスワード管理ポリシーの可用性。
• 外部認証ツール（LDAP、Kerberos）を接続する機能。
• アクセスの役割モデル。
• ;
• ;
• (TLS);
• .

これとは別に、あなたが行っていない負荷テストの結果を引数として使用しないように警告します。



まず、テスト対象のアプリケーションのデータ構造と負荷プロファイルは、解決しようとしているタスクとは大幅に異なる場合があります。約10〜15年前、データベースベンダーはTPCベンチマークの結果を誇示するのが大好きでしたが、今では誰もこれらの結果を真剣に受け止めているようには見えません。



次に、システムのパフォーマンスは、コードが最初に作成されたプラットフォームと、テストが実行されたハードウェアに大きく依存します。 OracleとPostgreSQLを比較する多くのベンチマークを見てきました。結果は、あるシステムの無条件の優位性から、別のシステムの同様に無条件の優位性までさまざまです。



そして最後に、3番目に、誰がテストを実施したかについて何も知りません。OSの品質とプラットフォームのカスタマイズに影響を与える両方の資格、および他のすべての要因を組み合わせた場合よりもテスト結果に影響を与える動機が重要です。



パフォーマンスが重要な要素である場合は、運用システムを構成および保守する専門家の助けを借りて、自分でテストを実施してください。

結果

最後に、行われたすべての作業の結果は、すべての推定値がまとめられ、乗算され、合計されるスプレッドシートである必要があり







ます。理解できるように、重みを変更して推定値を調整することで、任意の望ましい結果を得ることができますが、これは完全に異なるストーリーです...