OrientDB用于在每个文档的磁盘或内存中查找（和解析）属性名称的算法的算法复杂度是多少？

Question

给出一点背景知识。我目前正在寻找一种潜在的数据库解决方案来存储和处理大量的卫星和其他天气数据。 OrientDB已经拥有一些非常有趣的属性，使其成为我的顶级竞争者之一。

这些包括：

1. 灵活的文档结构（部分架构方法）
2. 缺少表连接（恒定时间遍历）
3. 低成本PIVOT操作。
4. 地理空间功能

OrientDB设计师干得好！我一直在告诉我的朋友和同事，这些是可能的一些属性，在数据库中可能会非常有趣。

我唯一担心的是，其中一些属性可能会带来隐藏成本。在传统的关系数据库中，列（大致相当于属性）以固定的列/属性名称存储，因此只需要查找名称一次，然后当数据存储在磁盘上或内存中时，使用固定偏移到数据中，导致值的位置大致恒定的时间查找。对于基于文档的数据库，我的理解是每个属性名称都与每个文档重复存储。我认为这将意味着额外的开销，为每个文档重复查找和解析每个属性名称的位置。

因此，我的问题主要是在额外的算法复杂性方面会涉及什么样的开销？另外，如果有什么可以或已经完成以减轻数据库本身内部的这种开销？例如，直接指向值的索引，或者将值存储在已在模式中声明为必需的属性的固定位置/偏移量中。

提前致谢！ - 克里斯

Answer 1

如果在模式中声明属性，OrientDB会通过避免存储属性名称来优化记录的读取/写入，而是存储属性id的数字。

OrientDB存储记录，其中包含所有字段的标题以及记录中值的位置（指针）。在最坏的情况下，如果记录（文档，顶点或边缘）有50个属性而您正在寻找最后一个属性，OrientDB将通过跳过右边的49来查找最后一个属性。

幸运的是，这项任务非常快，因为它适用于一个非编组和压缩的字节[]，现代处理器可以很容易地保存在L1 / L2缓存中。

这样可以提供极大的灵活性，因为您可以在无模式，模式完整和混合模式下工作，您只需在模式中定义其中几个模式，其余模式在无模式模式下进行管理。

我希望这能回答你的问题。