对于每个帐户，我有数百万个数据项（分析日志中的行），每个数据项都有20-50个数字属性（它们也可以为null）。我需要向他们展示主要涉及SELECT SUM(f1), f2, f3 WHERE f4>f5 GROUP BY f2, f3等查询的统计信息。聚合函数有时比SUM（）更复杂，GROUP BY有时涉及简单的函数，如ROUND（）。问题是这样的查询是在用户界面中构建的，并且可以在这些属性的任何组合上运行（尽管当然有一些流行的组合）。
一旦进入数据库，数据很可能不会被修改，只能读取。应该可以轻松添加/删除属性 - 不一定是数据库术语中的实时，但它不应该像MySQL中那样需要完整的表块。
哪种SQL或NoSQL数据库最适合处理这类查询？我在想PostgreSQL或MongoDB，尽管在后者中我很可能因为它的局限性而不得不使用MapReduce而不是Group功能。
有关此类查询的其他建议吗？这听起来是否可行，或者我是否必须要求用户预先定义他们想要运行的确切查询？
非常感谢任何想法。
答案 0 :(得分：1)
您在寻找什么查询性能？它会多久被询问一次？
如果您在低分钟内查询性能良好且查询率相似，则可以使用带有主表的关系表作为数据项，并使用属性的连接表。确保在组合的第二个表上放置组合索引（property_type，data_item_id，property_value）以保证良好的查询性能。你实际上并不需要property_value，但是如果你有，那么查询可以高效地从索引中提取数据，这将使连接变得更加容易。您可以使用任何关系数据库执行此操作。我碰巧喜欢PostgreSQL，但MySQL也可以工作。 （但复杂查询效率较低。）
如果您遵循此策略，则您需要的每个属性都需要您添加另一个联接。但是连接效率会很高。
答案 1 :(得分：1)
您可以在RDBMS或NoSQL数据库中构建此类应用程序（例如Berkeley DB，同时具有键值对API和SQL API）。键值对API是一个不错的选择，因为它支持一些非常低级别的优化，在查看如何调整性能以满足您的应用程序需求时可能会有所帮助。
另一个选择是查看一个柱状数据存储，但即使是那种产品也必须从多个列中检索数据（在这些类型的数据库中速度很慢），以便解决您的查询类型名单。
最终，这里的问题归结为磁盘I / O VS缓存和数据组织。您可以放入内存的数据越多，您执行的I / O就越少，I / O将成为性能杀手。您可以制作数据越紧凑，您拥有的内存就越多。我建议查看Berkeley DB，特别是键值对API。然后，您可以选择创建一个或多个表，其中的属性以优化最常见访问类型的方式进行组织。此外，如果您正在使用键值对API，请查看批量获取功能 - 这样您就可以一次获取和处理整组记录。
您可能还想创建和维护一些众所周知的＆＃34;统计结果（在内存中和/或保留在磁盘上），允许您采取＆＃34;快捷方式＆＃34;当用户要求已经计算的值时。
祝你的研究顺利。
答案 2 :(得分：1)
您所描述的内容 - 本质上是对不需要实时的数据的临时聚合查询 - 是OLAP解决方案非常擅长的。除了您看到的其他建议之外，您还应该了解OLAP解决方案是否对您有意义。