4

1 つのケースではHibernateを使用し、2 つ目のケースでは Hibernate と Javaコンテンツ リポジトリ(具体的にはJackRabbit ) の組み合わせを使用する 1 組のアプリケーションの再構築を行っています。

再設計の重要な課題はパフォーマンスの向上であるため、アプリケーションの設計と開発にDBAを導入する価値があるかどうか疑問に思っています。

実動データベースの管理に DBA を関与させることの価値について、私が疑問を呈しているわけではないことに注意してください。しかし、過去のプロジェクトでは、優れた DBA が設計およびコーディング フェーズに関与し、データ構造を最適化する方法を考え出し、ストアド プロシージャにコードを挿入することが不可欠でした。

しかし、データベース構造が Hibernate と JackRabbit によってほぼ完全に管理されていることを考えると、それらを最適化する余地はあまりありません。確かに、それらがうまく機能しないことがわかった場合、DBA は潜在的に問題を特定し、それらを改善するためにパッチを提出することができますが、アプリケーションの方法で多くのことをしたい (またはできる) かどうかはわかりません-特定のチューニング。

このタイプのアプリケーションでの DBA の役割について考えるもう 1 つの理由は、パフォーマンスの問題の大部分が永続化レイヤーの上にある可能性が高いことです。つまり、データベース、休止状態、または JackRabbit が遅すぎるということではありません。データを構造化してプッシュするのはあまり良くありません。これを修正するにはデータ モデリングが必要ですが、実装媒体はデータベース テーブルと SQL ではなく、XML ファイルと Java コードです。DBA は通常、この種のことについてよく知っていますか?

永続化レイヤーの上に構築されたアプリケーションの設計と開発において DBA の必要性を完全に否定できないのは、懐疑論です。事前にパッケージ化されたソリューションを使用することで、特定のアプリケーションのデータベース最適化の必要性が完全になくなるとは思えません。

キーポイントがありませんか？熟練した DBA は、休止状態の構成ファイルを微調整して、アプリの特定のユース ケースで非常に高速に処理できますか? DBA が DB 自体を手動で調整したり、インデックスを作成したりせずに、高負荷の Hibernate アプリを実行することを検討するのは狂気ですか? それとも、XML ベースのデータ モデルと抽象化された永続化レイヤーの最適化を専門とする新しい生き物が開発環境に登場するのでしょうか?

4

5 に答える 5

7

DBAとDBAがあります。一部のDBAは、管理者（バックアップ、復元、付与、取り消し）のような人々です。ライトをオンにしてください。基礎。

他のDBAはアーキテクト/デザイナーです。「これを修正するには、データモデリングが必要です」これは、DBAのこの第2層が行うべきことです。

多くの管理者DBAはアーキテクトの役割に突入します-結局のところ、彼らはSQLを知っています-しかし、実際にはそれに適していません。あなたはあなたが間違った人を持っていることを知っています...

  1. 彼らはテーブルと列の命名規則にこだわっています。

  2. 彼らはFK/PKの関係にこだわっており、行をフェッチしてオブジェクトにすると、関係を管理するために利用できる豊富で洗練されたコレクションクラスがたくさんあるという事実を無視しています。

  3. テーブル内の行を、アプリケーション内のオブジェクトおよび両方が実装されている実際のエンティティから切り離すことはできません。これは多くの場合、目立たないものになる可能性があります。複雑なプログラミング言語構造によって実装され、複雑なデータベース構造にマップされる複雑な実世界のオブジェクトがある場合、混乱する可能性があります。そして、何人かの人々は彼らの快適ゾーンに後退し、「それはすべてほんの少しです」または「最終的にはすべてがFKであり、オブジェクト参照でさえあります」のような無意味なフレーズを繰り返し始めます。

  4. 「より高速であるため」、すべてをストアドプロシージャにすることを要求します。彼らが証拠を提供できない場合、これはさらに悪いことです。

ここにポイントがあります...

パフォーマンスは、データ構造とアルゴリズムの2つに依存します。リソースの使用（I / O、メモリなど）を最小限に抑えるには、適切なデータ構造とアルゴリズムを選択します。

データベースの非正規化は、アルゴリズムに一致するようにデータ構造を微調整する方法です。他のパフォーマンス調整もほぼ同じ概念です。データ構造をアプリケーションアルゴリズムによりよく一致させるためにパラメーターとオプションを変更します。

これは双方向に進むはずです。エンティティと要件を確認し、正しいことを行うデータ構造とアルゴリズムの両方を理解する必要があります。それが済んだら、バッファのサイズなどを微調整して、パフォーマンスを少し向上させることができます。

基本的に、燃える速度は、最も内側の最も内側のループを考慮することから得られます。それらは何をループしているのでしょうか。彼らは何を探していますか？ループが少ない、またはまったくループしないものに置き換えるにはどうすればよいですか？

DBAがアルゴリズムとデータ構造の設計に参加できる場合、それらは資産であり、頻繁に使用します。

DBAが参加できない場合は、設計を快適なものに限定しないでください。

于 2008-10-09T13:18:40.863 に答える
3

DBA が DB 自体を手動で調整したり、インデックスを作成したりせずに、高負荷の Hibernate アプリを実行することを検討するのは狂気ですか?

はい、（AFAIK）HibernateはDBの最適化を行わないため、これらは常にワークロードに依存するためです。

より大きな質問に対処するには、もちろん、パフォーマンスのためにデータベースを調整するのに適した人が必要です。はい、休止状態を使用すると、必要なスキルセットが変わります。

于 2008-10-09T13:06:50.827 に答える
2

Hibernateはデータベース構造を制御できます。それは、休止状態がそれらを制御する必要があるという意味ではありません。

大量のデータを含む大規模なアプリがあり、パフォーマンスが重要である場合、自動生成されたテーブル定義はおそらく使用しません。完全に最適化されたデータベース構造が必要であり、それを使用するためにHibernateマッピングを記述します。開発を少し理解しているDBAを入手すれば、HQLやカスタムSQLを記述して状況を改善することもできます。

（私はJackRabbitを使用したことがないので、コメントすることはできません）

また、テスト中のパフォーマンスの問題のトラブルシューティングを支援するのはおそらくDBAです。

于 2008-10-09T13:18:09.197 に答える
0

私はデビッドに同意します。さらに悪いことに、永続化レイヤーを使用する開発者は、呼び出しに時間がかかる理由と回避策を見つける方法を理解するために、DB に関する十分な知識を持っている必要があります。

于 2008-10-09T13:13:20.250 に答える
0

それはあなたのアプリに依存すると思います-Hibernateでネイティブクエリを実行できます-したがって、存在する可能性があり、調整が必要なものがあるかどうかによって異なります. 同様に、必要なパフォーマンスによって異なります。パフォーマンスが重要なセクションがある場合は、そのセクションの速度を低下させている原因を特定するためのサポートが必要になる場合があります。また、一部のDBは他のDBよりも多くの管理者を必要とします(Oracle ...)

于 2008-10-09T13:10:18.777 に答える