Database 选择*vs在Cassandra中选择特定列

在RDBMS中，通常建议根据供应商选择特定列，但是Cassandra呢

从表中选择*； vs 从表中选择名称

---

请记住，您可能有50列（仅作为一个示例）。

在某些情况下，这可能会有所帮助，但在大多数情况下，这只是一个很小的改进。我建议用基准测试你的案例

---

用Cassandra选择*，其实没什么大不了的。如果您不将所有有用的内容传输到客户端，这将意味着更少的序列化/反序列化。特别是当你有大量的列，比如50列的时候。数据的布局方式可能会读取所有列以从磁盘中提取行。与调整分区大小、最小化逻辑删除、系统/堆设置或正确使用压缩策略相比，这是一个更小的优化。

您确定

它可能会读取所有列以从磁盘中提取行吗？你能提供一些参考来支持这一点吗？我确信SSTable是按键和列进行索引的，并且期望对特定列的查询只从磁盘中获取这些列。不是吗？sstable索引标记sstable中每个分区的开始。在读取时，它将对此索引文件的摘要进行二进制搜索（每个X分区，X是动态的）。它将从最接近的摘要中扫描索引文件，直到找到要启动的分区，然后在数据文件中查找（可能的压缩元数据转换）。从这里开始，它根据读取的类型读取分区。这在较旧的引擎和当前的3.0引擎中有一点不同，但是每排序一个（可配置的）字节就有一个行索引。因此，它可以通过二进制搜索找到最近的块并进行扫描。在缓存未命中和较大的数据集上，可以看到行索引位置，这可能会主导读取成本。但是从这里可以筛选出更多未获取的列，因为必须进行反序列化才能提升迭代器。据我所知，RowIndexEntry只包含索引数据（而不是实际数据），之后将获取所需的列。那么，为什么说所有列都会被提取呢？另外，看一看——似乎总是获取所有列有一个问题，但在3.4中解决了。正如我所说的，我建议对您的用例进行基准测试，看看是否有多大影响。在有些数据模型中，它会起到更大的作用，或者是无法测量的。即使使用CASSANDRA-10655，默认情况下，行索引也位于匹配的群集键+-64kb的开头，而不是特定的单元格。迭代器遍历该点的每个单元格，columnfilters包含的内容只允许序列化助手跳过内容，而不是完全反序列化内容（这取决于单元格类型，可能与读取成本无关）。