3

我想知道您是否认为使用 monetdb（或另一个列式数据库）将所有数据放在一个大而平坦的表中而不是将其分解为多个相关表是否合理。

例如，二手车数据库（flat）可能如下所示：

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 单独压缩列，冗余无关紧要，您可以只使用平面表来期望相同或更好的性能（查询时间、磁盘使用情况），因为一组分解良好的关系表会提供。这节省了设计工作，但更好的是让您完全自动化模式设计——通过避免它。

你怎么看？是否有一些我没有看到的隐藏成本？

4

2 回答 2

0

您所描述的是（afaik）称为“统一表方法”。非常聪明的人尝试围绕这个想法实施系统并放弃了它。最新的（不成功的）尝试是 IBM DB2 Blink Project（阅读http://homepages.cwi.nl/~idreos/BlinkDebull2012.pdf的第 3 页）。本质：从查询处理的角度来看，您通常会更好地使用规范化模式，而不是让系统为您找出您的模式。

回答您的具体问题：MonetDB 不压缩字符串以外的数据（即使只有在唯一字符串很少的情况下也是如此）。如果您真的不能，我建议您花精力定义关系模式或切换到无模式 DBMS。这自然会导致性能损失。

于 2013-11-10T21:48:32.987 回答
0

好像你做对了。以我的经验，一般的列式数据库和 MonetDB 尤其是使用您所描述的数据结构提供极快的查询时间。对于您描述的示例，列式数据库将编码和压缩每一列（自然包含相同类型的数据，有很多重复）。

无论如何，如果您的工作量包括大量更新，请在决定之前对解决方案进行基准测试。

就我个人而言，我认为 MonetDB 的性能比大多数商业面向列的数据库要好得多，并且比面向行或 NoSQL 好得多，但要记住的底线是每个案例都有自己的行为。

于 2013-11-10T15:29:04.933 回答