我们有一个架构,我们为他们的网站(互联网商家)提供每个客户类似商业智能的服务.现在,我需要在内部分析这些数据(用于算法改进,性能跟踪等),而这些数据可能相当沉重：我们有高达数百万行/客户/天,我可能想知道有多少个查询我们在最后一个月,每周比较,等等,这是数十亿条目的顺序,如果不是更多.
当前完成的方式是非常标准的：扫描数据库的日常脚本,并生成大型CSV文件.我不喜欢这个解决方案有几个原因：
>与这些类型的脚本一样,它们属于一次写入并且从未被触动过的类别
>“实时跟踪”是必要的(我们有独立的工具集来查询最近几个小时的ATM).
>这是缓慢而非“敏捷”
尽管我在处理巨大的科学数据资料方面有一些经验,但就传统的RDBM而言,我是一个完整的初学者.似乎使用面向列的数据库进行分析可能是一个解决方案(分析不需要我们在应用程序数据库中的大部分数据),但我想知道这种问题还有哪些其他选项可用.
解决方法
您将需要google
Star Schema.基本思想是以优化的方式为现有的OLTP系统建立特殊的数据仓库/ OLAP实例,以提供您所描述的聚合类型.这个例子将由事实和维度组成.
在下面的示例中,销售“事实”被建模为基于客户,商店,产品,时间和其他“维度”的分析.
您会发现Microsoft’s Adventure Works样本数据库具有指导性,因为它们提供OLTP和OLAP模式以及代表性数据.
