OrientDB 用于在磁盘或内存中为每个文档查找（和解析）属性 个名称的算法的算法复杂度是多少？
What is the algorithmic complexity of the algorithm that OrientDB uses to look up (and parse) property names on disk or in memory for each document?
提供一点背景知识。我目前正在寻找一种潜在的数据库解决方案来存储和处理大量卫星和其他天气数据。 OrientDB 已经拥有一些非常有趣的特性，使其成为我的顶级竞争者之一。
其中包括：
- 灵活的文档结构（部分模式方法）
- 缺少 table 连接（恒定时间遍历）
- 低成本 PIVOT 操作。
- 地理空间函数
OrientDB 设计师干得好！一段时间以来，我一直在告诉我的朋友和同事，这些是可能的并且在数据库中看到的可能非常有趣的属性。
我唯一担心的是，其中一些房产可能带有隐性成本。在传统的关系数据库中，列（大致相当于属性）以固定的 column/property 名称存储，因此只需查找一次名称，然后当数据存储在磁盘或内存中时引用它在数据中使用固定偏移量，从而导致对值位置的查找时间大致恒定。对于基于文档的数据库，我的理解是每个 属性 名称都与每个文档一起重复存储。我认为这将意味着额外的开销为每个文档重复查找和解析每个 属性 名称的位置。
因此，我的问题主要是在额外的算法复杂性方面会涉及什么样的开销？此外，是否可以或已经采取任何措施来减轻数据库本身内部的这种开销？例如，直接指向值的索引，或将值存储在固定的 locations/offsets 中，用于在我们的模式中声明为强制性的属性。
提前致谢！
- 克里斯
如果您在模式中声明属性，OrientDB 会通过避免存储 属性 名称来优化记录的 reading/writing，而是存储作为 属性 id 的数字。
OrientDB 存储带有 header 的记录，其中包含记录中所有字段和值的位置（指针）。在最坏的情况下，如果一条记录（文档、顶点或边）有 50 个属性，而您正在寻找最后一个，OrientDB 将通过跳过正确属性之前的 49 来查找最后一个 属性。
幸运的是，这项任务非常快，因为它在未编组和压缩的字节 [] 上运行，现代处理器可以轻松将其保存在 L1/L2 缓存中。
这提供了很大的灵活性，因为您可以在 schema-less、schema-full 和混合模式下工作，您可以在模式中只定义其中的一部分，其余的在 [=22= 中管理] 模式。
我希望这能回答你的问题。
提供一点背景知识。我目前正在寻找一种潜在的数据库解决方案来存储和处理大量卫星和其他天气数据。 OrientDB 已经拥有一些非常有趣的特性，使其成为我的顶级竞争者之一。
其中包括：
- 灵活的文档结构（部分模式方法）
- 缺少 table 连接（恒定时间遍历）
- 低成本 PIVOT 操作。
- 地理空间函数
OrientDB 设计师干得好！一段时间以来，我一直在告诉我的朋友和同事，这些是可能的并且在数据库中看到的可能非常有趣的属性。
我唯一担心的是，其中一些房产可能带有隐性成本。在传统的关系数据库中，列（大致相当于属性）以固定的 column/property 名称存储，因此只需查找一次名称，然后当数据存储在磁盘或内存中时引用它在数据中使用固定偏移量，从而导致对值位置的查找时间大致恒定。对于基于文档的数据库，我的理解是每个 属性 名称都与每个文档一起重复存储。我认为这将意味着额外的开销为每个文档重复查找和解析每个 属性 名称的位置。
因此，我的问题主要是在额外的算法复杂性方面会涉及什么样的开销？此外，是否可以或已经采取任何措施来减轻数据库本身内部的这种开销？例如，直接指向值的索引，或将值存储在固定的 locations/offsets 中，用于在我们的模式中声明为强制性的属性。
提前致谢！ - 克里斯
如果您在模式中声明属性，OrientDB 会通过避免存储 属性 名称来优化记录的 reading/writing，而是存储作为 属性 id 的数字。
OrientDB 存储带有 header 的记录，其中包含记录中所有字段和值的位置（指针）。在最坏的情况下，如果一条记录（文档、顶点或边）有 50 个属性，而您正在寻找最后一个，OrientDB 将通过跳过正确属性之前的 49 来查找最后一个 属性。
幸运的是，这项任务非常快，因为它在未编组和压缩的字节 [] 上运行，现代处理器可以轻松将其保存在 L1/L2 缓存中。
这提供了很大的灵活性，因为您可以在 schema-less、schema-full 和混合模式下工作，您可以在模式中只定义其中的一部分，其余的在 [=22= 中管理] 模式。
我希望这能回答你的问题。