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

Question

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

我们现在有许多关于下一步处理负载的传统选择：

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

在许可和硬件或时间方面，所有这些都是昂贵的。因此，我想通过将整个系统移动到 nosql 引擎 cassandra 承诺的可扩展解决方案来添加另一个选项。

然而，我不确定也没有使用 noSQL 数据库的经验，所以我需要了解“非结构化”数据的结构。

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

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

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

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

更新：我们存储任何形式的表格。所以，基本上我们存储“文件”。然而，我们必须准备并通过任何值、排序等来搜索这些表单。数据访问控制为数据库增加了另一层复杂性。

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

这种“字典”之类的数据集会更好地存储在 noSQL 数据库中吗？我们会从中获得性能优势吗？cassandra 会将这些 head+KVP 建模为一个数据集吗？查看 cassandra 网页和一些教程，我的印象是，我们的 RDBMS 和 cassandra 在数据组织方面没有太大区别——如果您想选择 5 个 KVP，那么我们的连接数量也相同对于每一行的列表。

欢迎启蒙，也可以提供解释问题的论文的指针。

Answer 1

尽管 noSQL 数据库是主流，恕我直言，采用这种技术的决定应该根据存储的信息所需的成就做出，而不仅仅是关注您当前拥有的性能。这意味着也许您最好的选择是坚持使用 SQL 数据库并改进您的硬件。

但另外我在你的问题中读到了一些让我思考的东西。关于您的数据库的当前状态并没有太多，但是您的句子“我们基本上将用户以各种方式输入的数据存储为“键值”列表”让我思考问题是否不是糟糕的数据模型而不是缺乏物质资源。我管理过非常大的表（+100 亿行），在“传统”SQL 数据库中具有令人难以置信的性能。

我并不是说这是错误的，只是因为当然我无法在正确的数据模型中评估您，而有关您当前解决方案的信息很少，但请考虑重新访问您的数据模型作为其他选项以及其他选项，因为您可能会在那里找到一些线索。

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

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

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

希望这会有所帮助，或者至少拓宽可能性并开辟新的调查路线。

Answer 2

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

结构化数据是应用程序预先知道其接收到的每个字节的含义的数据。一个很好的例子是传感器的测量。相比之下，Twitter 流是非结构化的。模式是关于将多少结构传达给 DBMS 以及如何要求执行此操作。它控制 DBMS 解析其存储的数据的数量。需要模式的 DBMS（例如 SQL Server）可以存储未解析的数据 (varbinary) 或可选解析的数据 (xml) 以及完全解析的数据（列）。

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

优点是您可以通过单次顺序读取检索完整的数据集。这很快。一个缺点是，您（应用程序程序员）现在永远对所有数据完整性和向后兼容性问题负责，对接触此数据存储的每一位代码负责。这可能很难做到正确。此外，你对数据的看法也被锁定在一种观点上。如果您按订单号键入行，则如何报告一种特定产品、地区或客户的销售情况？