2

質問があります。ここで提案を探しています。

そのため、私のアプリケーションはデスクトップ アプリケーションを Web に変換することで「最新化」しており、ICEFaces UI とサーバー サイドは Java で記述されています。ただし、現在のカウントでは約 700 ～ 900 のテーブルがあり、テーブルにはおそらく合計で 10 億のレコードがある同じ Oracle データベースを維持しています。個々のテーブルには 2 億 5000 万行あるものもあれば、2500 万行を超えるものもあります。

言うまでもなく、データベースは十分にスケーリングされていません。その結果、アプリケーションのパフォーマンスは最悪のようです。アーキテクト/意思決定者は、永続性を拒否するか、再構築することを望まないかのいずれかです。したがって、基本的には、現在ほとんどのユーザーのニーズに対応し、比較的簡単に機能するデスクトップ アプリケーションに新たな塗装を施しています。現在、デスクトップ アプリでの実際のデータベース パフォーマンスはかなり遅いです。先ほど言及したクイック パフォーマンスは、データベースに関係のないものでした (言い間違えてすみません)。このアプリケーションのパフォーマンスがどれほど低く、日常​​のユーザーが仕事をするのがどれほど難しいかを考えると、夜眠れません。

では、私の質問は、この差し迫った災害を軽減するためにどのようなオプションが必要ですか? データベース構造を損なわずにパフォーマンスを高速化するために、データベースと Java コードの間に配置できる何らかのタイプの中間層はありますか? キャッシュは明らかにオプションですが、それが万能薬だとは思いません。間に NoSQL DB をレイヤー化することは可能ですか?

4

10 に答える 10

4

あなたが言った2つのことをどのように調整するのか理解できません。

言うまでもなく、データベースは十分にスケーリングされていません

と

現在、ほとんどのユーザーのニーズに対応しており、比較的簡単かつ迅速なパフォーマンスでそれを実現しています。

新しいユーザーや新しい機能を追加しているとは言いません。同じ機能を Web インターフェイス経由でアクセスできるようにするだけです。

では、なぜ問題があるのでしょうか。Web アプリは、以前とほぼ同じデータベース作業を行います。

実際、Web 層を導入すると、新しいキャッシングの機会が得られる可能性が高く、DB の作業が削減されます。

Web アプリ開発の初期段階でパフォーマンスが低下している場合は、Web アプリで実行しているクエリが既存のアプリで実行されているクエリとどのように異なるかを理解することから始めます。クエリを生成するためにやや単純なアプローチを取っているツールを使用している可能性はありますか?

于 2010-06-03T04:05:25.853 に答える
3

現在のアプリが正常に動作し、新しいJavaアプリが正常に動作しない場合、問題はデータベースレイヤーではなく、アプリケーションレイヤーにあります。あなたが言うほどパフォーマンスが悪い場合、彼らはかなり早く気づき、デスクトップアプリケーションに戻るオプションを持っているはずです。

DBAは、アプリケーションからデータベース上の追加のワークロードを簡単に識別できる必要があります。ロジックが変更されていないと仮定すると、それ以上の書き込みを行う可能性は低くなります。それは読み取りである場合もあれば、「おしゃべり」である場合もあります（同じ量の情報をより小さな区画で移動します）。おしゃべりなアプリケーションは多くのCPUを使用できます。多くのアーキテクトは、「データベースでの作業にはコストがかかる」ため、処理をデータベース層からアプリケーション層に移そうとしますが、実際には「往復」のオーバーヘッドのために事態が悪化します。

PS。

テーブルに2億5000万行あることについて「悪い」ことは何もありません。通常、インデックスを介してテーブルにアクセスします。通常、インデックスの上部から下部まで（さらに、テーブルまで1つ）ホップが2つまたは3つあります。BLEVELが2の2,000万行のテーブルと、BLEVELが3の1億2,000万行以上のテーブルがあります。

インデックス作成とは、データブロックのごく一部にしかヒットしないことを意味します。頻繁に使用されるインデックスブロック（およびデータブロック）は、データベースサーバーのメモリにキャッシュされます。DBAは、このメモリ領域がワークロードに対して小さすぎるかどうか（つまり、物理ディスクIOが多いかどうか）を確認できます。

アプリが実際には必要のない多くの情報を取得している場合、これはメモリスペースに圧力をかける可能性があります。貪欲にならないでください。行から3つの列だけが必要な場合は、行全体を取得しないでください。

于 2010-06-03T04:51:44.033 に答える
1

データベースにないアイテムの検索が多い場合は、ブルーム フィルターを使用して数を減らすことができます。データベース内のすべてをブルーム フィルターに追加してから、検索を行う前にまずブルームをチェックします。ブルームが存在を報告する場合にのみ、データベースを気にする必要があります。ブルームによって誤検知が発生しますが、最適な「サイズと誤検知」のトレードオフになるように設計できます。

この戦略は、Google のビッグテーブル データベースで使用されており、パフォーマンスが大幅に向上することが報告されています。

http://en.wikipedia.org/wiki/Bloom_filter

頑張ってください。自分が信じていないタスクに取り組むのは大変です。

于 2010-06-03T03:26:19.747 に答える
1

では、機能的で高速なデスクトップ アプリケーションに新たなペンキを塗った後、システムが遅くなったということですか?

そして、「言うまでもなくデータベースのスケーリングがうまくいっていない」とおっしゃいますか？

理解できません。データベースではなく、塗りたての塗装に問題があると思います。

于 2010-06-03T08:32:21.560 に答える
1

あなたが説明することは、適切な機器とデータベース設計があれば、オラクルが非常に簡単に処理できるはずです。大規模なアプリケーションのパフォーマンス チューニングのスペシャリストをチームに配置すれば、うまく拡張できるはずです。

データベースをゼロからやり直すと、莫大な費用がかかり、新しいバグが発生し、重要な情報が失われる可能性が非常に高くなります。この時点でデータベースを書き直すことは、ほとんど良い考えではありません。通常、この種のプロジェクトは、会社に数千ドル、さらには数百万ドルの費用がかかった後、惨めに失敗します。あなたの建築家は正しい選択をしました。自分が望んでいることが常に最良の方法であるとは限らないことを受け入れることを学びましょう。会社にとってデータは、アプリよりもはるかに重要です。データベースをゼロから再設計しようとしないことを人々が学んだのには、多くの理由があります。

現在、データベースのパフォーマンスを向上させる方法があります。このサイズのデータ​​ベースで最初に検討することは、データのパーティション分割です。また、古いデータをデータ ウェアハウスにアーカイブし、そこからほとんどのレポートを作成することも検討します。他に考慮すべきことは、サーバーをより高性能なモデルに改善すること、実行速度が最も遅いクエリを見つけるためのプロファイリングと個別の修正、インデックス作成の確認、統計とインデックスの更新です (これが Oracle で行っていることかどうかはわかりませんが、私は SLQ です)サーバーギャルですが、あなたのデータベースは知っているでしょう）。古いレガシー データベースのリファクタリングに関する優れた書籍がいくつかあります。以下のものはデータベース固有ではありません。 http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1275577997&sr=8-1 パフォーマンス チューニングに関する優れた本もいくつかあります (Oracle 固有の本を探してください。SQL Server で機能するものや、mySQL が Oracle に最適なものではない) 個人的には、それらを入手して最初から最後まで読んでから、方法の計画を立てます。パフォーマンスの低下を修正します。また、すべての計画に DBA を含めたいと思います。DBA は、データベースについてあなたが知らないことや、一部の設計がそのように設計されている理由を知っています。

于 2010-06-03T15:19:08.760 に答える
0

「この差し迫った災害を軽減する」方法は、とにかくやるべきことをすることです。ベスト プラクティスに従えば、後の段階で永続化レイヤーを切り替える手間が最小限に抑えられます。

有効なパフォーマンス ベンチマークを取得し、パフォーマンスに関するシステムのボトルネックを特定するまでは時期尚早です。いずれにせよ、「中間層」戦略の多くがまだデータベース レベルで実装されていないとしたら、私は驚かれることでしょう。

于 2010-06-03T04:37:23.993 に答える
0

この種のことで落ち込まないでください。寝坊するのではなく、挑戦と考えてください。プログラマーとして、すべてをぶち壊して最初からやり直したいと思う気持ちはわかりますが、ビジネスの観点からすると、それが常に実行可能であるとは限りません。たとえば、同じデータベースを使用することで、ビジネスは新しいアプリケーションの開発中に古いアプリケーションを引き続き使用し、顧客をグループで切り替えることができます。同時に全員を切り替える必要はありません。

パフォーマンスに関して何ができるかについては、使用パターンに大きく依存します。キャッシングは、ほとんどが読み取り専用のデータベースで非常に役立ちます。読み取り/書き込み可能なデータベースであっても、正しく設計されていればメリットがあります。NoSQL データベースは、書き込みの多いものには役立つかもしれませんが、データを通常のデータベースに保存する必要がある場合は、価値がある以上に面倒になる可能性があります。

最終的には、アプリケーションのアーキテクチャと使用パターンに大きく依存します。

幸運を！

于 2010-06-03T03:38:50.450 に答える
0

どのような種類のクエリが主に実行されるかについてあまり知らなくても (ルックアップの方が一般的だと思います)、おそらく最初にキャッシュを試す必要があります。そして、可能であればアプリサーバーの前のレイヤーで、さまざまなレイヤーでキャッシュし、もちろん、アプリサーバーとデータベースの間のレイヤーでキャッシュすることを提案しました。

キャッシングは読み取りデータに対してうまく機能し、思ったほど悪くはないかもしれません。

テラコッタを見たことがありますか？それらには、あなたに関連する可能性のあるキャッシングとスケーリングに関するものがいくつかあります。

挑戦してください！

于 2010-06-03T03:42:17.730 に答える
0

データベースがレガシーで巨大な場合、

1) インターフェースを変更するような方法で変更することはできません。これは、あまりにも多くの既存のアプリケーションを壊してしまうためです。または、インターフェイスを変更する場合は、関連するテストで複数のアプリケーションを変更して調整する必要があります。

2) 問題がパフォーマンスである場合、インターフェイスを変更せずにデータベースを最適化するために行うことができる多くの変更がおそらくあります。

3) ビューを使用して既存のインターフェースを維持しながらテーブルを再構築して効率を高めたり、将来により効率的なアクセスを許可したりすることができます。

4) パフォーマンス分析、インデックス作成、キャッシングなどの標準的なデータベースの最適化により、インターフェイスを変更することなく、効率とパフォーマンスを大幅に向上させることができます。

できることは他にもたくさんありますが、アイデアはわかります。1回の大きな変更で実際に更新することはできません。変更は増分的である必要があり、それを使用するアプリケーションに対して透過的である必要があります。

于 2010-06-03T04:44:10.763 に答える
0

データベースはアプリケーションの一部です。それらを別々に考えないでください。そうではありません。

開発者として、必要に応じてスキーマを自由に変更し、本番環境でのパフォーマンスや機能を改善するためにデータの変更を提案する必要があります (古いデータのアーカイブなど)。

開発システムにはおそらくそれほど多くのデータはありませんが、まったく同じスキーマがあります。

パフォーマンス テストを行うには、本番環境と同じハードウェアと同じサイズのデータ​​ (可能であれば同じデータ) を備えたシステムが必要です。アプリが機能しないと感じているため、パフォーマンス テストが絶対に必要であることを管理者に説明する必要があります。

もちろん、スキーマの変更 (インデックスの追加/削除、テーブルの分割など) は、システムの他の部分 (システムの一部と見なす必要があります) に影響を与える可能性があるため、必要な回帰テストと修正を行います。

データベース スキーマを変更し、それに応じてデスクトップ クライアントに変更を加えて Web アプリを実行する必要がある場合は、それを実行する必要があります。設計上の決定を管理者に説明してください。

于 2010-06-04T12:56:56.933 に答える