Azure 关于在SQL或表存储中存储数据的问题

我对是否将数据存储到SQL或表存储以及存储它们以提高效率的最佳方式有很多疑问

用例：

我有大约500万行对象当前存储在mysql数据库中。目前元数据仅存储在数据库中。（Lat、Long、ID、时间戳）。关于该对象的其他150列（使用不多）被移动到表存储中

• 在表存储中，是否应该将所有这些列存储在一行中，而不是将所有150列存储在一列中，而不是多行中

对于数据库中这500万个对象中的每一个，都有关于它们的特定信息（温度读数、轨迹等）。轨迹数据过去存储在SQL中（~300行/对象），但为了节省成本，将其移动到表存储中。目前，它们以关系方式存储在表存储中，每一行看起来都像（PK:ID，RK:ID Depth Date，X，Y，Z）

• 目前，获取许多轨迹数据需要时间。在我们的例子中，表存储似乎相当慢。我想提高GET的性能。数据应该存储在每个对象有一行作为其轨迹，所有XYZ以JSON格式存储在一列中的位置吗？它只需要得到一行，而不是300行
• 表存储是存储所有这些数据的最佳位置吗？如果我想得到某个深度的X，Y，Z，我必须得到整行并通过JSON进行解析。这可能是一种权衡
• 在sql数据库中保存轨迹数据、读数等是否可行，其中轨迹数据可以有（5000000 x 300行）。还有一些关于对象所在位置的信息（5000000 x 20000行）。对于SQL数据库来说，这可能太多了，必须在Azure云存储中。如果是这样，JSON选项会是最好的吗？折衷的办法是，如果我想要一个1000行的部分，我必须得到整个表，然而，这并不比查询20000行快多少。我可能可以将数据分成1000行的集合，并使用sql作为元数据来确定我需要从云存储中获取哪些数据集合

我很难理解如何将数据分组并将其格式化到Azure云表中，以便在为我的应用程序获取数据时高效快速

---

这是我的数据的一个例子，我是如何得到的：

< P>作为表存储的替代，您可以考虑使用Azure SQL DB弹性标度来扩展多个Azure SQL DBS的轨迹数据（和相关的对象元数据）。这允许您克服单个数据库的容量（和计算）限制。您将能够高效地执行特定于对象的查询或插入，并且可以选择跨多个数据库执行查询——假设您使用的是.Net应用层。您可以通过查看

了解更多有关使用三种数据库引擎和类型之一的建议：MySQL（关系型）、表存储（键/值）和DocumentDB（文档）。您正在询问关于如何布局数据行等的建议。这将产生您的意见，因为没有单一的正确答案。所以，不幸的是，这种类型的问题不适合StackOverflow。@DavidMakogon我要问一个一般性的问题，关于为了提高效率，azure表中应该存储多大的数据。我将取消documentDB，并从sql数据库部分转移到一个非常合适的问题。这将有助于提供更多上下文。。。您能否提供示例数据以及读/写模式是什么（例如前1-3个查询）？我很高兴能就此进行更深入的讨论。。。为什么有这么多列-每行都填充了吗？这是为了说明每行填充哪些字段的可变性吗？你必须查询这些字段吗？@aliuy这里有一个我的数据示例以及我是如何获得它的：。我有这么多额外的列，因为还有很多与对象相关的数据，这些数据似乎与其他任何东西都不相关。。。这里有一些提示1）表是一个键值存储；仅查询键以避免扫描（速度慢）。如果您想查询给定深度W/O日期的单个条目，请考虑从行键2中删除日期。利用查询投影仅得到X、Y、Z 3。如果由于具有大数据集，性能开始滞后，则考虑跨多个SQL DBS的分区。4） 如果您决定需要一个具有更多可查询性的NoSQL存储（它会自动对json文档中的所有属性进行哈希索引），请查看DocDB。