我想知道您是否认为使用 monetdb(或其他列式数据库)将所有数据放在一个大的平面表中而不是将其分解成几个相关的表是否合理。
例如,二手车数据库可能如下所示:
Make Model Year Color Mileage
Chevy Malibu 2009 orange 102100
Chevy Malibu 2009 orange 98112
Chevy Malibu 2008 orange 210232
Chevy Malibu 2009 pink 150100
注意 Make-Model-Year-Color 中的冗余,在 SQL 数据库或 excel 电子表格或其他任何东西中,您可能有两个表,例如:
mId Make Model Year Color
1 Chevy Malibu 2009 orange
2 Chevy Malibu 2008 orange
3 Chevy Malibu 2009 pink
mId Mileage
1 102100
1 98112
2 210232
3 150100
这有助于以更复杂的查询为代价的冗余,并且必须考虑如何分解(分解)表。
我正在阅读有关列式数据库,尤其是 monetdb 的内容。看起来,因为 monetdb 单独压缩列,所以冗余无关紧要,您可以只使用平面表来期望相同或更好的性能(查询时间、磁盘使用),因为一组分解良好的关系表将提供。这节省了设计工作,但更好的是让您完全自动化模式设计 - 通过避免它。
你怎么看?是否有一些我没有看到的隐藏成本?
最佳答案
看来你做对了。 以我的经验,一般的列式数据库和 MonetDB 特别是使用您所描述的数据结构提供极快的查询时间。 对于您描述的示例,列式数据库将编码和压缩每一列(自然包含相同类型的数据,有很多重复)。
无论如何,如果您的工作负载包括大量更新,请在决定之前对解决方案进行基准测试。
我个人认为 MonetDB 的性能比大多数商业列式数据库好得多,比行式数据库或 NoSQL 好得多,但要记住的底线是每种情况都有自己的行为。
关于sql - 使用像 MonetDB 这样的列式数据库来避免维度建模?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19885446/