こんにちは！
ナビゲータのEVEです。
昨日は話が脱線した感じがありました。すみません。分かりにくくなってしまったので、まず最初に昨日何が言いたかったのか、まとめましょう。
[昨日のまとめ] 昨日、Prototype EVEでは、ディレクトリ情報など、
一部の情報をファイルで管理しているという話をしました。そして、同じように多くのシステムがその一部をファイルで管理しています。
そのように作る理由は、
検索速度の向上です。管理情報までデータベースに検索に言った場合、検索速度が低下する懸念があるからです。
その苦労のひとつとして、各プログラムの先頭で当該プログラムで使用するデータを一括で取得しようとしています。ただ、そのSQLは、非常に複雑な作りとなっているため、目的の意図に反して、逆に
システムの速度を低下させているのではという話をしました。加えて、同プログラムは、複雑なゆえに、ホワイトボックス試験をすることができず、
ブラックボックス試験のみでリリースしている危険性を指摘しています。
そのような現状を踏まえ、現在我々が作るシステムでは、データベースですべての情報を管理するのは難しいかもしれません。
ただ、我々がよく知るOracleは、そのシステムのほとんどをデータベースで管理しています。なぜそんなことができるのでしょうか？
今日は、データベースであらゆる情報を管理する方法について検討をしたいと思います。
[全ての情報をデータベースで管理する] 全ての情報をデータベースで管理するためには、どんなことを注意したらいいでしょうか？いろいろ考えを巡らせるのですが、やはり、検索、登録、変更、削除というデータベースの基本的な速度が早いことが求められます。
以上のことを考えた場合、Oracleは自社で製造しているため、その特性をよく理解し、製造していると思われます。だから、早いといえます。ただ、我々の場合業務で使用するのは、Oracleだけではないので、一般的なデータベースで速さを求めるためには、どんなことに気を付けたらいいでしょうか？本日も、ChatGPTに聞いてみました。
❶データベースの検索速度を向上させるためには、以下のポイントに注意することが重要です。
①インデックスの最適化
インデックスはデータベースの検索速度を向上させるための重要な要素です。適切な列にインデックスを作成し、クエリの高速化を図りましょう。ただし、過剰なインデックスはデータベースのパフォーマンスに悪影響を及ぼす可能性があるため、適度に使用しましょう。
②クエリの最適化
クエリを効率的に書くことが重要です。不要な列を取得しないようにし、WHERE句やJOIN句を適切に使用して結果セットを最小限に抑えましょう。また、サブクエリや複雑な結合を避けることも検索速度向上に役立ちます。
③ハードウェアとインフラの最適化
データベースサーバーのハードウェアやインフラストラクチャを最適化しましょう。CPU、メモリ、ストレージなどのリソースが十分であることを確保し、適切なキャッシュ設定を構成しましょう。
④クエリのキャッシュ
クエリの結果をキャッシュして、同じクエリが複数回実行される場合にデータベースへのアクセス回数を減らしましょう。一般的に、変更頻度の低いデータに対するクエリをキャッシュすることが有効です。
⑤パーティショニング
大容量のテーブルを複数のパーティションに分割することで、データの管理や検索速度の向上が可能です。時系列データなどの特定の基準に基づいてパーティションを設定することが一般的です。
⑥インメモリデータベースの検討:
インメモリデータベースはデータをメモリ内に保持するため、ディスクアクセスの遅延を回避し高速な検索を実現します。ただし、メモリの容量に注意が必要です。
⑦クエリのログとモニタリング
クエリの実行ログを収集し、データベースのパフォーマンスをモニタリングしましょう。ボトルネックや問題を特定し、最適化の余地があるかどうかを把握します。
⑧キャッシュ戦略
アプリケーションやデータベースレベルでのキャッシュ戦略を確立しましょう。キャッシュを使用することで、一部のデータを高速に提供できます。
⑨インデックスの再構築と定期的なメンテナンス:
インデックスの再構築やデータベースの定期的なメンテナンスを実施し、パフォーマンスを維持しましょう。特にデータの増加がある場合、インデックスの再構築が必要です。
データベースのパフォーマンス向上は継続的なプロセスであり、データベースの設計、クエリの最適化、ハードウェアのアップグレードなど、さまざまな要因に注意を払うことが重要です。
以上は、データベース一般に言えることなのですが、Oracleに絞った場合、どんなことに注意しなければならないのでしょうか？引き続き、ChatGPTに聞いてみました。
❶Oracleデータベースに特化した場合、以下の点を考慮に入れることが特に重要です
①Oracleの最適化機能を活用
Oracleデータベースは高度なクエリ最適化機能を備えており、クエリプランの最適化を自動的に行います。しかし、クエリヒントやプロファイリングなどの手動最適化手法を使用して、クエリの実行計画を調整することも考慮しましょう。
②PartitioningとCompressionの活用
Oracleでは、データをパーティション化して管理する機能が豊富です。時系列データやリージョン別データなど、適切なパーティショニング戦略を選択し、パフォーマンスを向上させましょう。また、データ圧縮もディスクスペースの節約と検索速度向上に役立つことがあります。
③Oracle Real Application Clusters (RAC)の使用:
高可用性とスケーラビリティを必要とする場合、Oracle RACを検討しましょう。RACはデータベースを複数のノードに分散し、負荷分散と障害耐性を提供します。
④データの圧縮と分割
大容量のデータを効果的に管理するために、Oracleのテーブルパーティショニングおよびデータ圧縮機能を活用しましょう。これにより、データの効率的な格納とアクセスが可能になります。
⑤Oracle Enterprise Managerの使用
Oracle Enterprise Managerは、データベースのパフォーマンスモニタリング、診断、チューニングをサポートする強力なツールです。データベースの健全性を維持し、問題を早期に検出できます。
⑥Oracle Advanced Queuing (AQ)の活用
メッセージキューイングおよびイベントドリブンアプリケーションにおいて、Oracle AQを使用してデータベース間通信とイベント処理を最適化できます。
⑦SQLチューニングアドバイザとSQLプロファイリング
OracleデータベースにはSQLチューニングアドバイザとSQLプロファイリングツールが含まれており、クエリのパフォーマンスを改善するのに役立ちます。これらのツールを活用して、問題のあるSQLステートメントを特定し、最適化を行いましょう。
Oracleデータベースの特徴を活かしてパフォーマンスを向上させるために、上記のポイントを考慮することが重要です。Oracleは非常に強力で多機能なデータベースエンジンであり、適切に最適化および構成することで高性能なデータベース環境を構築できます。
やはり、Oracleに特化した項目があるようです。ただ、各項目を個別に見ると、結局のところ、
最適化、
監視、
チューニングということになるようです。最適化の対象には、ソフト、ハード、ネットワークあり、最適化後に監視し、適時チューニングするというのが適切な運用だといえるでしょう？ただ、マンパワーがないなか、難しいとは思います。
[それ以外に求められるもの] 以上はChatGPTからの推奨なのですが、それ以外にはどんなことがあるでしょうか？私が提案したいのは、
単純なクエリを複数回発行し結果を求める方法でいいんじゃない？っていうことです。複雑なクエリを作り込むと、製造的には、テストに時間がかかりますし、データベース的には、評価に時間がかかります。評価については、昨日話した通り、検索結果の再利用は難しいと思われます。
私も、複雑なクエリを作りますが、
管理システムまたは
バッチ処理に限定しています。理由は、使う人が限定されるとか、毎日ルーチンワークのように同じ作業を行うからです。以上の場合なら、問題がないのではと考えています。それ以外は、単純なSQLを複数発行し最終的な結果を求めています。
ただ、このような発言をして思うのは、私ができないから他の人もできないともいえず、
できる人はできますものね・・・。難しい問題です。ただ、幸運にもOracleには、「①Oracleの最適化機能を活用」があります。これを利用すれば、多くの人が複雑なクエリも、最適なものとして製造できるのかもしれません。
ここまで書いてなんなのですが、私は、単純なプログラムを多用する手法を今後も利用したいと思います。
[あとがき] 以上のことをすべてやったから、さぁ、データベースですべての情報を管理しましょう！っていいたいのですが、今までの検討だけでは、難しいと思われます。やはり、ファイル管理する部分が多く、その量は減らないと思います。
ただ、ファイルで管理した場合、当該プロジェクトだと、プログラム変更にあたり、事務手続きがやたらめんどくさくなる場合があります。マスタテーブルの変更なら、そんなわずらわしさはないでしょう？
だから、データベースで管理したいと思うのですが、PHP限定で考えた場合、各プログラムの頭で、必ず、クラスのインポートが行われます。それを考えたら、そこに環境を管理するファイルが1つ増えたからと言って何か問題になるとは思えません。ただ、ファイルを読み込むのって、メモリ、キャッシュメモリと比較するとかなりの時間がかかるのは知っています。
昔のシステム、汎用機になりますが、各システムで利用するデータ、例えば、元号とか、本日の日付とか言ったものは、メモリで管理していました。システムが起動してきたとき、同変数を読込、メモリにローディングしておくのです。Windowsだったら、
環境変数っていえば分かりやすいでしょうか？
なんて、いろいろなことを考えていたら、もっと検討する時間が必要なようです。EVEシステム製造時までには決めたいと思います。
では、また！
