数据库分析的体系结构

Question

我们有一个架构,我们为他们的网站(互联网商家)提供每个客户类似商业智能的服务.现在,我需要在内部分析这些数据(用于算法改进,性能跟踪等等),这些数据可能非常繁重:我们有多达数百万行/客户/天,我可能想知道有多少查询我们在上个月,每周比较等等......即使不是更多,也是数十亿条目的顺序.

目前的工作方式非常标准:每日脚本扫描数据库,并生成大型CSV文件.我不喜欢这个解决方案有几个原因:

• 对于那些类型的脚本而言,它们属于一次写入而从未触及的类别
• "实时"跟踪事物是必要的(我们有单独的工具集来查询ATM的最后几个小时).
• 这很慢而且非"敏捷"

虽然我在处理大量科学数据集方面有一些经验,但就传统的RDBM而言,我是一个完全的初学者.似乎使用面向列的数据库进行分析可能是一种解决方案(分析不需要我们在app数据库中拥有的大部分数据),但我想知道有哪些其他选项可用于此类问题.

Answer 1

你会想要google Star Schema.基本思想是以优化的方式为现有OLTP系统的特殊数据仓库/ OLAP实例建模,以提供您描述的聚合类型.该实例将包含事实和维度.

在下面的示例中,销售"事实"被建模为基于客户,商店,产品,时间和其他"维度"提供分析.

您会发现Microsoft的Adventure Works示例数据库具有指导性,因为它们提供OLTP和OLAP模式以及代表性数据.