問題タブ [oltp]

BIRT、Jasper Report などのレポート ツールに OLAP または OLTP を使用する必要がありますか? アドホックに多くのドキュメント (例: 1000000) を作成したい。

私は、合理的に可能な限り改善するために自由に統治できる大量のOLTPDBを導入しました。改善はすでに非常に役に立ちましたが、私はそれを次のレベルに引き上げたいと思います。私が見つけたデータアクセスパターンは、他のサーバーにデータをキャッシュするのに適したIMOの候補であり、このタイプのセットアップに関する誰かの経験や推奨事項を聞いてみたいと思います。

毎日約3GBのデータをテーブルに追加するDBがあり、それに関するレポートは非​​常に低速でした。一度入力するとデータは変更されず、1週間以上経過したデータは挿入されません。過去3日以内に入力された行には、数千万行の間に数千の挿入が表示される傾向があります。

2週間以上前のデータをMongoDBにプッシュすることを考えていました。次に、Mongoにプッシュされない2週間のスライディングウィンドウデータを何らかのキャッシュソフトウェアでキャッシュして、データがDBから常に読み取られるのではなく、クエリされて表示されるようにすることができます。このように、DBエンジンにすべてのデータを検証させ、DBにヒットしないため読み取りパフォーマンスが高く、Mongoが「トランザクション」でなくなったときにそれを取得できるようにすることで、ACIDに完全に準拠できると考えています。

誰かが推奨される解決策を持っていますか？私はMemCachedを見ていましたが、それが良い解決策であるか、それとももっともらしい解決策であるかはよくわかりません。ありがとう！

私は、DataWarehouse、より具体的には OLTP について、大学向けにこの書類を作成しています。ウェブ上で多くの情報を見つけることができませんでした。一般的で表面的な要約を見つけましたが、より詳細な作業を行う可能性を与えてくれるものは何もありません.

その種の情報を見つけるための助けを本当に感謝します.今は少し失われています.

それで、私の仕事のベースに使用できるPDFや電子書籍などはありますか？

ありがとう、ジョン

PS。OLTP、データウェアハウスについて 十分な情報を見つけることができます

私たちは、レポート要件に役立つデータ ウェアハウスをまとめ始めたばかりで、異種のデータ ソースをまとめています。

データの潜在的な用途をまとめて確認したところ、一部のトランザクション処理システムがこのデータを有用な方法で参照できる可能性のあるシナリオがいくつか見つかりました。明らかに、データは古くなり、読み取り用に最適化されますが、一部のシナリオでは、これはアプリケーションの目的には問題なく、コア サーバーの負荷を軽減します。

私の質問は次のとおりです。トランザクション システムがデータ ウェアハウスに格納されたデータにアクセスするのは、設計が悪いと見なされますか? 明らかに、私たちのウェアハウスの主な目的はレポートを作成することです。そのため、他の非レポート システムがデータを読み取れるようにする必要があるかどうか疑問に思います。私の本能は、アプリケーションがデータを読み取って表示できるようにすることから私を導きます. それらを聞く正当な理由はありますか?!

Webサーバー上のすべての履歴アクティビティを含むデータベースからapacheリクエストをプルして、オンデマンドでリグレッションをすばやく実行するためのインフラストラクチャを構築しようとしています。小規模なクライアントからのリクエストを確実にリグレッションすることでカバレッジを改善するために、クライアントごとに最大n個（この質問では10個）のリクエストを取得して、リクエストを確実に分散させたいと思います。

ここで回答された同様の質問がいくつか見つかりました。最も近いものは、IDの範囲全体でIDごとに上位N行を返すSQLクエリのようでしたが、回答の大部分は、すでに試したパフォーマンスに依存しないソリューションでした。たとえば、row_number（）分析関数は、探しているデータを正確に取得します。

ただし、このテーブルには特定の日の数百万のエントリが含まれており、このアプローチでは、row_number分析関数を適用するために、選択基準に一致するインデックスからすべての行を読み取る必要があるため、パフォーマンスはひどいものになります。最終的に100万行近くを選択しますが、row_numberが10を超えたため、それらの大部分を破棄するだけです。上記のクエリの実行による統計：

ただし、代わりに特定のコンテキストIDの最初の10件の結果のみをクエリすると、これを劇的に高速に実行できます。

このクエリの実行による統計：

この場合、Oracleは、10個の結果を取得した後にデータの取得を停止するのに十分なほど賢いです。コンテキストIDの完全なセットを収集し、コンテキストIDごとにこのクエリの1つのインスタンスと全体の混乱からなるクエリをプログラムで生成できますが、コンテキストunion allIDの数が非常に多い場合、Oracleの内部制限に遭遇する可能性があります。 、このアプローチは恨みの悪臭を放ちます。

2番目のクエリに見合ったパフォーマンスを維持しながら、最初のクエリの単純さを維持するアプローチを知っている人はいますか？また、安定した行のセットを取得することについては実際には気にしないことに注意してください。それらが私の基準を満たしている限り、回帰の目的には問題ありません。

編集： AdamMuschの提案がうまくいきました。彼の回答に対するコメントの回答にそれらを収めることができないため、ここに彼の変更を加えたパフォーマンス結果を追加しています。今回は、より大きなデータセットをテストに使用しています。これは、比較のために元のrow_numberアプローチからの（キャッシュされた）統計です。

私はアダムの提案を少し煮詰める自由を取りました。これが変更されたクエリです...

...およびその（キャッシュされた）評価からの統計：

アドバタイズされているように、完全にフィルタリングされた行のdailylogdataテーブルにのみアクセスしています。選択していると主張する行数（1213K）に基づいてurlcontextインデックスのフルスキャンを実行しているように見えるのではないかと心配していますが、6770個のバッファーのみを使用していることを考えると（この数は私がコンテキスト固有の結果の数を増やす）これは誤解を招く可能性があります。

私の質問はこの質問と同じですが、少し追加します。私の問題は、Web アプリのユーザーが新しいバージョンのレコードを作成できることです。レコードのすべての新しいバージョンは、その特定のバージョンへの個々の変更を記録するために、50 の他の関連テーブルに対応する「新しいバージョン」を作成することになります。関連する約 50 のテーブルを含むこの新しいバージョンの作成は、トランザクション内で実行されます (エラーが発生した場合にすべての変更をロールバックするため)。多くの場合、この手順は遅くなります。当然のことながら、テーブルの「挿入」が多すぎる「長いトランザクション」が原因です。

このようなシナリオを実装するためのより良いソリューション/設計を検討しています。

1. 特に複数のテーブルであまりにも多くの重複を作成する場合、同じレコードの「バージョン」を維持するためのより良い方法はありますか?
2. 「すべての行バージョン」に挿入されるレコードが多すぎるため、設計自体は良いとは思いませんが、少なくとも差し迫った問題である「長いトランザクション」に対処したいと思います-これは時々遅延を引き起こします. 抜け道はないかもしれませんが、それでも質問したい - 「バージョン管理」をトランザクション内に配置しない場合、エラーが発生した場合にロールバックするより良い方法はありますか (トランザクションが他の OLTP をブロックしているように見えるため)クエリ - すべてのプライマリ テーブルに新しいバージョンを挿入するため)

バージョン管理クエリは現在約 10 秒間実行されますが、時々悪化します。どんな考えでも大歓迎です

C# でアプリケーションを開発しており、適切なデータベース プラットフォームを選択しようとしています。私のアプリケーションは、ある種のデータ分析ツールです。データベースにデータを最初にインポートした後は、常に SELECT クエリを作成します。SQL CE と比較して読み取りパフォーマンスが優れているため、SQLite を使用する予定です。（どこかで比較したことがある）

ただし、この目的のためには、OLTP データベースではなく OLAP データベースが必要な気がします。また、SQLite が OLTP のみをサポートしていることもどこかで読みました。SQLite に似た OLAP をサポートする他の PORTABLE ライブラリを知っていますか? または、私に何をお勧めしますか？

現在、私は、毎日約 100,000 件の挿入を行う高度なトランザクション データベースを持っています。メイン トランザクション テーブルから多数の同時読み取りを許可し始めた場合、心配する必要はありますか? 並行性については気にしていませんが、パフォーマンスはそれほど気にしていません。

現在、このテーブルには 1 億 1000 万以上のトランザクションがあり、SQL 2005 を使用しています。

より広い視野: Stock EOD データを維持するためのデータベース計画。

手元にあるツール: PHP と共に MySQL データベース 4.1+ を使用する予定です。カスタム DBAL (mysqli に基づく) は、MySQL と連携するために PHP に実装されています。ただし、無料で利用でき、SQL ステートメントで動作する場合は、他のデータベース エンジンを使用できます :P

問題領域:株式の EOD データを維持するために、プロジェクトのデータベースを計画する必要があります。データベースに保持される在庫の数は膨大になるため、同じ EOD データの更新プロセスは、1 日の終わりにかなり重いプロセスになります。言うまでもなく、私は共有ホスティングを使用しており、最初の起動時に MySQL のパフォーマンスのボトルネックを回避する必要があります。ただし、後で VPS に移行する可能性があります。

質問:

1.正規化されたスキーマは、パフォーマンスの問題を発生させずに重い更新プロセスを実行できますか?

2. MACD や CMF などの一般的なアルゴリズムに基づく分析を EOD データに対して実行して、株式の特定の傾向を特定する必要があります。分析からのデータは、さらなる参照のために再度保存する必要があります。その日の EOD データが更新されると、分析データが計算されます。ここで正規化されたスキーマを使用しても問題ありませんが、パフォーマンスの問題は考慮されていますか? また、EOD と分析データの両方を頻繁にフェッチする必要があります。

詳細:

1 つの INSERT ステートメント(EOD データを挿入するため) + 1 つの INSERT ステートメント(分析データを挿入するため)

= 2 INSERT ステートメント* 1500 株(スタートアップ用)

= 3000 INSERT ステートメントが 2 つ戻って実行されました。

プロジェクトが成長するにつれて、さらに在庫を追加することを計画しているため、ここではスケーラビリティも検討しています。

DW の概念については知りませんが (聞いただけです)、パフォーマンスの観点から OLTP よりも実行可能である場合は、試してみる準備ができています。

I am interested in comments and insights relating to using Microstrategy to report against a complex snowflake SQL Server database comprising of several transactional, normalized (3NF) tables.

Specifically, what is the best approach or the challenges on reporting in such an environment? Currently, there are some complex views that serve as analytical fact tables using complex SQL joins between the several transactional tables.

The transactional tables also have their own dimensions, and so on. The views seem to work fine in SSRS. However, I have read that Microstrategy is not ideal for reporting against such a complex database (not due to performance of the tool, but more so because of the complexity of the SQL in building these metrics in Microstrategy).

What would be the best approach on reporting in such an environment? Would building an SSAS cube on the current data warehouse be a good idea? Should reporting be done on the database, or should a new database or mart be created, specifically to be used by Microstrategy, with only the relevant views for basic reporting?

Any advice or opinions are appreciated.