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

Question

关于是否将我的数据存储到SQL或表存储中以及存储它们以提高效率的最佳方法，我有很多疑问。

用例：

我有大约500万行目前存储在mysql数据库中的对象。目前，元数据仅存储在数据库中。 （Lat，Long，ID，Timestamp）。关于未使用太多的对象的其他150列被移动到表存储中。

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

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

• 目前需要时间来抓取许多轨迹数据。在我们的案例中，表存储似乎相当慢。我想提高获取的性能。数据是否应存储在每个对象的轨迹为1行，并且所有XYZ以JSON格式存储在1列中？而不是要获得300行，它只需要获得1行。
• 表存储是存储所有这些数据的最佳位置吗？如果我想在某个测量深度获得X，Y，Z，我将必须得到整行并通过JSON解析。这可能是一种权衡。
• 在sql数据库中获得轨迹数据，读数等是否可行，其中可以有（5,000,000 x 300行）轨迹数据。这也是有关物体的一些信息（5,000,000 x 20,000行）。对于SQL数据库来说，这可能太多了，而且必须在Azure CLoud存储中。如果是这样，JSON选项会是最好的吗？权衡的是，如果我想要一个1000行的部分，我将不得不得到整个表，但是，并不比查询20,000行更快。我可以将数据拆分成1000行，并使用sql作为元数据，以便从云存储中找出我需要的数据集。

我很难理解如何将数据分组并将其格式化为Azure Cloud Tables，以便在为我的应用程序获取数据时高效快捷。

以下是我的数据示例以及我如何获取数据：http://pastebin.com/CAyH4kHu

Answer 1

作为表存储的替代方法，您可以考虑使用Azure SQL DB Elastic Sc​​ale在多个Azure SQL DB之间传播轨迹数据（和关联的对象元数据）。这允许您克服单个数据库的容量（和计算）限制。您将能够有效地执行特定于对象的查询或插入，并具有跨多个数据库执行查询的选项 - 假设您正在使用.Net应用程序层。您可以查看http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

了解更多信息