在这种情况下,NoSql可以用于报告吗?

时间:2011-06-21 05:59:32

标签: sql architecture nosql design-consideration

情况

我正在考虑构建一个基于NoSQL的应用程序,作为现有基于Excel的财务风险管理报告工具的替代方案。简而言之,我的问题围绕着考虑以下

使用NoSQL的适用性
  1. 主要来源数据(csv文件)来自另一个应用程序,实际上是根据市场变动报告当前交易和相关估值计算。这是一个固定的来源,不会改变。报告行数可以从少量的1,5k行到超过65k行。不是真正大量的数据,但这是一个相当线性的增长率。还有其他几个支持数据源。
  2. 报告格式相当一致,但报告内容可以是动态的。即,大多数报告允许企业根据业务需求决定他们希望看到哪些额外的列式数据。
  3. 此时发生的报告涉​​及拼接和切割上述报告;在这种情况下,考虑枢轴,图形,聚合,额外的计算等。这里有一些复杂的东西,我不太了解。
  4. 这不是交易系统,而是风险管理系统,因此在使用源数据时存在假定的和预期的时间延迟。它主要是阅读重量。
  5. 报告通常仅与当天(最重要)相关,并且需要为源数据中的每个更改(在#1中列出)保留先前运行的历史记录以供进一步分析。
  6. 这不是一个简单的应用程序,但我的感觉是Excel不能很好地扩展和足够快(六个月前这是梦想成真,它是)。有一些隐藏的业务规则已为少数人所知,并且通过此练习/重写会强制所有这些表面。从业务和开发的角度来看,我们有太多bus-factors
  7. 整体解决方案需要满足动态报告或数据的动态呈现。与Excel相比,我认为速度并不是真正的问题(我假设我的解决方案会更快) - 但是如果要使用真正的动态查询,则需要在合理的时间内完成(<1分钟)
  8. 为什么我考虑使用NoSQL?

    首先,对于NoSQL来说,我是一个完整的菜鸟,所以我目前的理解可能还不够发达。我已经修改了NoSQL,但我没有考虑到我目前正在考虑的规模。

    我认为NoSQL的主要原因是源数据。虽然实际格式(csv文件)是无关紧要的,但是根据动态列的数据的动态特性,我认为基于SQL的方法会受到严格的限制和不灵活,因为表结构非常静态。但是NoSQL文档可以处理这个问题。

    第二个原因是,数据格式的变化需要在日常的基础上随时提供。使用基于SQL的解决方案,迫使我们遵循企业级变更管理流程(对SQL数据库的更改),这些流程既费力又费力又麻烦。所以我想,我的目标是在我的应用和解决方案中有足够的灵活性来绕过这一切的官僚主义。 (如果您打算评论企业变更管理的奇迹和好处,请不要!

    最后一个原因,有点自私,我想尝试不同的东西。

    我完全承认我没有详细考虑过这个问题,因此我提出问题的原因是因为我知道我缺少一些非常相关的方面需要考虑。如果基于SQL的解决方案更合适,您可以根据列出的6个点进行详细说明。

    目前,这还处于一个非常探索的阶段 - 在我考虑提出这种解决方案之前,我需要连续抓住所有的鸭子。

1 个答案:

答案 0 :(得分:3)

关键问题是如何定义报告。

如果报告都是自定义代码,并且您可以合理地设置新的自定义索引或map reduce查询以获取报告的简单数据表,那么使用NoSQL可能是有意义的。

如果您需要最终用户定义或配置报告,除了excel或基于SQL的报告工具之外,您确实没有合理的选择。

您还需要考虑如何使用动态列 - 无架构存储适用于只需要在找到记录后显示的列,但对于查询则不太好。使用SQL,所有列都是可查询的。许多NoSQL系统通过了解大多数列永远不会包含在查询中来获得性能提升。