问题标签 [column-oriented]

我目前正在尝试提高 Web 应用程序的性能。该应用程序的目标是提供(real time) analytics. 我们有一个类似于star schema少量事实表和多维表的数据库模型。数据库Mysql与MyIsam引擎一起运行。
Fact 表的大小很容易达到上百万，一些维度表也可以达到上百万。
现在的重点是，如果维度表在事实表上连接并且聚合完成，则选择查询会变得非常慢。听到这个时首先想到的是，为什么不预先计算数据呢？这是不可能的，因为允许用户使用几个可自由定制的过滤器。

所以我需要的是一个适合各种用途的一体化系统；）遗憾的是，它还没有被发明出来。所以我想到了结合两个现有系统的想法。混合 arow oriented和column oriented数据库（例如 likeinfinidb或infobright）。保留 mysql MyIsam 解决方案（用于快速插入和基于行的查询）并向其添加面向列的数据库（用于在少数列上进行快速聚合操作）并通过 cronjob 定期（每晚）填充它。问题是当查询当前数据（它必须是实时的）时，因此我可能需要从两个数据库中获取数据，这会使事情变得复杂。

使用 infinidb 进行的第一次测试显示在聚合几列时性能非常好，所以我真的认为这可以帮助我加快应用程序的速度。

所以问题是，这是个好主意吗？有人可能已经这样做了吗？也许有更好的方法来做到这一点。

我还没有面向列的数据库的经验，我也不确定它的架构应该是什么样子。第一次测试显示在相同star schema like结构上的良好性能，而且在结构上也表现出良好的性能big table like。

我希望这个问题适合SO。

有没有人有过 MonetDB 的经验？目前，我的 MySQL 数据库变得太大，查询变得太慢。根据面向列的范例，插入会更慢（我一点也不介意），但数据检索会变得非常快。我是否有机会通过切换到 MonetDB 获得更多的数据检索性能？MonetDB 是否足够成熟？

跟着C-store上发表的论文，部分没看懂

以不同顺序在多个重叠投影中冗余存储表格元素，以便使用最有利的投影解决查询

首先，我不明白它是如何得出数据库表中哪些列构成“冗余”列的？

其次，关于上述几点，我的理解是这些标记为“冗余”的列不必存储在表上创建的每个投影中。如果查询请求此类列，则只需要其中一个投影即可回答查询。我对么？

在互联网上阅读了几篇论文和文档，我发现了许多关于 Cassandra 数据模型的相互矛盾的信息。有许多人将其识别为面向列的数据库，其他人将其识别为面向行的数据库，然后将其定义为两者的混合方式。

根据我对 Cassandra 如何存储文件的了解，它使用 *-Index.db 文件访问 *-Data.db 文件的正确位置，其中存储了布隆过滤器、列索引，然后是所需的行。

在我看来，这是严格面向行的。有什么我想念的吗？

这是与 Infragistics UltraWinGrid Columns 有关的问题。

我正在使用 Infragistics2.Win.UltraWinGrid.v10.3

正如您在图像中看到的，列在顶部并且从左到右跨越。

我可以用左侧从上到下的列显示相同的数据吗？

设置在哪里？
谢谢。

我知道面向文档的 NoSQL DB 是 KV 模型的“扩展”，因为它们允许您查询的不仅仅是单个查找键。但是一旦某个东西是“文档”，我觉得它已经包含了一个关系模型：

对我来说，我看不出这个 JSON 与一个json_objects带有fizzandbuzz字段的表以及与第二个表的外键关系之间的区别widgets。

像 Cassandra 这样的“柱状”数据库听起来就像是直接的关系/表数据库。

所以我问：面向文档和面向列的 DB 有什么不同，以及它们的区别（与 RDBMS 不同）是什么？它们最适合解决哪些问题，使它们在某些情况下优于关系数据库？提前致谢！

NoSQL 术语有 4 个类别。

1. 键\值存储
2. 面向文档
3. 图形
4. 面向列。

从我的角度来看，所有这些数据建模都有相同的定义，有什么区别？

Key\value 数据库以类似于 OOP 中的对象的结构维护数据。访问数据是基于唯一键。

面向列是一种类似于键\值的方法！但是在 key\value 中，您无法通过查询访问 value。我的意思是，查询是基于键的。

比较 2 个不同类别的第一张和第二张图片。

面向文档将数据存储在集合中，例如行。访问数据是基于唯一键。集合存储数据，如键\值。但是，您可以按值访问数据。

如您所见，在这 3 个类别中，我们定义了一个唯一键以指定唯一对象和一些键\值对以获取更多信息

图 db 有点不同。

那么，定义和现实世界有什么区别？

我在 Infobright 中有一个包含大约 4000 万行的事实表。在该表上运行查询（如下所示）需要 10 多分钟。

任何想法为什么以及如何调整这个？

顺便说一句，硬件规格是 AWS m1.large。所以抛开网络延迟不谈，这仍然是一个重要的时间间隔。

我正在对 4 种类型的 NoSQL 数据库进行深入比较：键/值、文档、图形和面向列。

主要是我比较他们基于：

• 并发
• 查询
• 交易
• 架构
• 复制
• 缩放

应该在此比较中添加哪些内容？

您能否为我提供好的博客、论文、书籍和视频来帮助我获得所需的信息？

从这个 wiki 页面： http ://en.wikipedia.org/wiki/Column-oriented_DBMS

我的印象是，面向列的数据库比索引的面向行的数据库更快地检索满足特定条件的记录的原因是由于映射。

也就是说，列的索引存储如下： 1：bot 2：human 3：bot

另一方面，面向列的数据库存储如下所示的列：bot：1,3 human：2

那么，为什么面向行的数据库不能像面向列的数据库那样做索引呢？