NoSQL：什么是非结构化数据？

目前，我们基于mssql服务器的解决方案正在资源边缘运行。

现在，关于下一步解决负载的问题，我们有许多传统的选择：

• 购买更快的CPU和IO
• 拆分一些客户以分离服务器
• 将数据库移到群集

就许可和硬件或时间而言，所有这些都是昂贵的。因此，我想通过将整个系统移至nosql引擎cassandra承诺的可伸缩解决方案中来添加另一种选择。

但是，我不确定noSQL数据库也没有使用过SQL数据库，因此我需要了解“非结构化”数据的结构。

在我们的应用程序中，我们基本上将用户以各种方式输入的数据存储为“键值”列表。有一个父表，它包含head元素（如Order），还有一个子表，其键值对包括该订单的内容（如Order_Lines）。

在业务方面，Order和OrderLines是一个单位。但是由于RDBMS，它们存储在表中，并且必须一直连接。

在操作过程中，有时我们选择只加载顶部，但是在大多数情况下，我们加载头行+一些KVP以显示一些有用的信息。

例如，在概述列表中，我们在每行的列中显示头标识符+一些值。

更新：我们存储任何形式的表格。因此，基本上我们存储“文档”。但是，我们必须按任何值，排序等来准备和搜索这些形式。数据访问控制在数据库上增加了另一层兼容性。

您可能会猜到，某些KVP的数量和可用性因对象而异。没有有效的可能性为每种对象创建单个表，因为我们必须为不同的数据组合创建数千个表。

这种“字典”之类的数据集会更好地存储在noSQL数据库中吗？并从中获得性能收益吗？卡桑德拉会将这些head + KVP建模为一个数据集吗？看看cassandra网页和一些教程，我的印象是，在数据组织方面，我们的RDBMS和cassandra之间并没有太大的区别-如果您要选择5个KVP，我们将拥有大量的连接为每一行的列表。

欢迎启蒙，也可以使用指向这些问题的论文的指针。

有几个概念需要区分。一个是关于结构，另一个是关于模式。

结构化数据是应用程序预先知道其接收的每个字节的含义的数据。一个很好的例子是来自传感器的测量。相反，Twitter流是非结构化的。模式是关于如何要求结构强制将其传递给DBMS的。它控制DBMS解析其存储的数据量。需要模式的DBMS（例如SQL Server）可以存储未解析的数据（varbinary）或可选解析的数据（xml）和完全解析的数据（列）。

NoSQL DBMS位于从无解析（键值存储）向上的范围内。在这方面，Cassandra提供了相对丰富的功能。它们与关系存储明显不同的地方在于数据的一致性。定义表格后，只有与该定义相匹配的数据才可以保存在那里。但是，在Cassandra中，即使定义了列和族，也不需要同一表中的任何两行看起来彼此相似。由应用程序设计师来决定一行中有多少行（也称为文档）以及由指针链接的单独存放的内容。实际上，您想要多少非正规化。

好处是您可以通过一次连续读取来检索全部数据。很快 不利之处在于，作为应用程序程序员，您现在将永远对涉及此数据存储的每一段代码负责所有数据完整性和向后兼容性。很难做到这一点。同样，您被锁定在数据的一种观点上。如果按订单号键入行，您如何报告某一特定产品，地区或客户的销售情况？

尽管恕我直言，noSQL数据库已经成为主流，但采用这种技术的决定还是要根据存储的信息所需的成就来做出，而不仅要考虑您当前的性能。这意味着您最好的选择是坚持使用SQL数据库并改善您的硬件。

但是此外，我在您的问题中读到一些让我思考的东西。数据库的当前状态不是很多，但是您的句子“我们基本上将用户以各种方式输入的数据存储为“键值”列表”使我思考问题是否不是不良的数据模型，而不是缺乏物理资源。我已经在“传统” SQL数据库中以不可思议的性能管理了非常大的表（超过100亿行）。

我并不是说这是错误的，只是，因为我当然不能用很少的有关您当前解决方案的信息来评估您在正确的数据模型中的情况，而只是考虑将数据模型作为其他选择来重新考虑，因为您可能会在这里发现一些线索。

通常，当您无法在模型的最终状态下实现模型时（因为您不知道将要面对的不同键，或者当您需要其中一种可能的值时），权衡列表可以作为一种折衷方案某个元素的键。但是在实施后，我通常会在您收集了足够的信息以识别常见的使用情况并确定数据模型决策是否为最佳后的一段时间后，重新考虑此类决策。如果您知道您将拥有一定数量的键，请尝试使用传统方式对常规表进行一些基准测试

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

...并添加相应的索引。尝试一下，并用两种方法衡量执行计划。如果一次收集多个密钥，您可能会特别感到惊讶，因为除其他优点外，数据块大小应减小，从而可以提高性能。

希望这有助于或至少扩大了可能性，并开辟了新的调查范围。