状況
既存のExcelベースの財務リスク管理レポートツールの代わりに、NoSQLベースのアプリケーションを構築することを検討しています。要するに、私の質問は、次のことを考慮してNoSQLを使用することの適合性を中心に展開します
- 主なソースデータ（csvファイル）は別のアプリケーションからのものであり、実際には現在のトランザクションと市場の動きに基づく関連する評価計算のレポートです。これは固定ソースであり、変更されません。レポートの行数は、わずか1.5k行から65k行を超える範囲になります。それほど大量のデータではありませんが、これはかなり直線的な増加率です。他にもいくつかのサポートデータソースがあります。
- レポートの形式はかなり一貫していますが、レポートの内容は動的にすることができます。つまり、ほとんどのレポートでは、ビジネス要件に基づいて、どの追加の列データを表示するかをビジネスで決定できます。
- 現時点で発生しているレポートには、上記のレポートのスプライスとダイシングが含まれます。この場合、ピボット、グラフ、集計、追加の計算などを考えてください。ここには、私があまり知らない複雑なものがいくつかあります。
- これはトランザクションシステムではなく、リスク管理システムであるため、使用されているソースデータには想定および予想される時間遅延があります。主に読み取りが多くなります。
- レポートは通常、当日（最も重要）にのみ関連し、さらに分析するために、ソースデータ（＃1にリストされている）のすべての変更について以前の実行の履歴を維持する必要があります。
- これは単純なアプリケーションではありませんが、Excelは十分に拡張できず、十分に高速ではないように感じます（6か月前、これは夢の実現でした）。少数の人に知られている隠されたビジネスルールが多すぎるため、この演習/書き換えを行うと、この表面のすべてが強制されます。ビジネスと開発の観点から、バスファクターが多すぎます。
- ソリューションは全体として、動的なレポートまたはデータの動的な表示に対応する必要があります。Excelと比較すると、速度は実際には問題ではないと思います（私のソリューションの方が速いと思います）。ただし、真に動的なクエリを使用する場合は、妥当な時間（<1分）で完了する必要があります。
なぜNoSQLの使用を検討したのですか？
まず、私はNoSQLに関しては完全な初心者なので、現在の理解は十分に発達していない可能性があります。私はNoSQLを少しいじって遊んでいますが、現在検討している規模には何もありません。
私がNoSQLを検討した主な理由は、ソースデータによるものでした。実際の形式（csvファイル）は関係ありませんが、動的列に関するデータの動的な性質は、テーブル構造がかなり静的であるため、SQLベースのアプローチは厳しく制限されて柔軟性がないと思うかもしれません。ただし、NoSQLドキュメントはこれを処理できます。
The second reason, is that changes to data formats need to catered for on the fly, on a day-to-day basis. Using a SQL based solution, forces us to conform to enterprise level change management processes (for changes to a SQL database) which are laborious and painstakingly cumbersome. So I guess, my objective here is to have enough flexilbilty in my application and solution to bypass the bureaucracy of it all. (If you intend commenting about the wonders and benefits of enterprise change management, don't!)
The last reason, and somewhat selfish, I want to try something different.
I fully concede that I have not thought about this in full detail, thus the reason for my question since I know I am missing some very relevant aspects for consideration. If a SQL based solution is more appropriate, can you elaborate based on the 6 listed points.
Right now, this is still in a very exploratory phase - I need to get all my ducks in a row before I even considered proposing this type of solution.