数据库分析的体系结构

Question

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

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

• 与这些类型的脚本一样，它们属于一次写入而从未触及的类别
• “实时”跟踪内容是必要的（我们有单独的工具集来查询ATM的最后几个小时）。
• 这很慢而且非“敏捷”

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

Answer 1

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

在下面的示例中，销售“事实”的建模是为了根据客户，商店，产品，时间和其他“维度”提供分析。

您会发现Microsoft's Adventure Works样本数据库具有指导性，因为它们提供OLTP和OLAP模式以及代表性数据。

Answer 2

有像Greenplum，Aster数据，Vertica，Netezza，Infobright等分析的特殊数据库。您可以在此站点上阅读有关这些数据库的信息：http://www.dbms2.com/

Answer 3

关于Star-Schema风格数据仓库的规范手册是Raplh Kimball的“数据仓库工具包”（在同一系列中也有“点击流数据仓库”，但这是从2002年开始我认为，并且有点过时了，我认为如果有一个新版本的Kimball书，它可能会为你提供更好的服务。如果你谷歌搜索“网络分析数据仓库”，可以下载和研究一堆样本架构。

另一方面，在现实生活中发生的许多no-sql都是基于挖掘点击流数据，因此可能值得看看Hadoop / Cassandra / [最新酷的东西]社区在案例研究的方式，看看你的用例是否与他们能做的事情相符。