3

这个问题是关于选择“正确”类型的 NoSQL 数据库，我希望甚至可以根据我将在下面列出的一些要求/用例以及目前在地方。这有点长，但我认为关于这个主题的任何讨论都对那些试图学习新范式的人非常有益。有很多关于 NoSQL 的讨论，但据我所见 - 它们中的大多数都是高级别的，并没有为新手提供足够的洞察力。

所以，它来了：

在我的大部分编程生涯（15 年）中，我一直在针对传统的 RDBMS/SQL 系统进行开发，并且在这方面有很好的经验。最近，关于 NoSQL 及其有用性的话题引起了轰动——所以我很想了解它如何带来好处。我描述的系统比我见过的普通 TODO 或日历示例要复杂一些，因此可以进行很好的讨论。

该系统与相对复杂的蜂窝网络有关——在这样的网络中大约有 300 个“类”（并且“完全部署”可以有多个网络，并且可以增长到 1000 个或更多类）具有不同数量的实例（每个 100,000 - 10 秒）。每天（有时一天几次）将其加载到数据库中以驱动系统。类之间的关系要么是包含，要么是“使用”。领域变化相对较快（网络软件更新之间大约 3 个月，每次通常意味着向现有类添加参数并添加一些（10-20）个新类）。

系统的使用（用例）如下： 0. 解析数据（进入数据容器层次结构）并将其加载到关系数据库（通常来自大约 2GB 的 XML 文件）

  1. 查看属性（如“select field1, field2 from table1 where ids in ()”并以表格格式查看
  2. 跟踪变化（今天和昨天之间的变化 - 参数谁的值已更改和添加/删除实例
  3. 检查业务规则：
    • 它可以很简单（SELECT idField1...idFieldN, paramValue FROM table where paramValue<>default”
    • 或更复杂 - 检查关系 - 例如 x 类型的子项数量等
  4. 检索类的所有层次结构 - 选择特定的类实例、其子级，有时还选择实例或其子级使用的类
  5. 对类实例进行更改并推回网络（然后查看它确实已执行 - 验证更改）。这通常需要根据类的层次结构生成一些 XML 文件。

在 RDBMS 解决方案中，为了克服这些要求，我将数据映射到关系表（每个表都有一个类），然后保存一个元数据和关系字典。此外，为数据检索任务创建了一个通用数据容器（类类型名称 + 键值（或值））或使用可以合并到视图或文件中的 DataTables。

这种架构（平台）意味着在升级时我所要做的就是更新/创建表（更改/创建表）并更新元数据和关系 - 其余代码是“通用的”并由元数据驱动。唯一的例外是上面的 (4)，有时需要我进行硬编码（将子级添加到数据检索层次结构中），尽管最终我也概括了这个过程（分层数据检索 - 基于父级的 id 获取子元素等）等级制度）。

该系统在大多数情况下运行良好，但有时速度太慢（尤其是在 4 中）。缓慢与从数据库中检索数据有关，但仅在某些部署中，它可能与维护不善或硬件不足（或编程不当，但为什么它在其他部署中运行良好？-）有关

我要补充一点，由于域是一个网络，每个实例都有一个不同的名称 - 通常由它的层次结构组成（实例及其父级，例如“Node=ER222,Subrack=3,Slot=5”或“Node=ER222,Equipment =1,Sector=2,Carrier=C2") 并且每个类的层次结构通常是相同的（尽管有些类可以出现在多个层次结构中（例如具有不同的祖先）

通常系统上的负载并不多——可能多达 50 个活跃用户，但通常要少得多。在更大的网络中，这可能会增长到 300-400 个用户。

现在我想开发一个具有类似要求的系统，并且正在考虑 NoSQL 可能带来的优势：

  • 我读到动态模式或无模式 NoSQL 是一个自然的选择。
  • 我读到图形数据库非常适合建模“网络”（或类似网络），所以也许这可能是一个解决方案（节点=类，边缘=包含或使用（在边缘具有属性））。
  • 也许使用一些文档数据库并只保留部分解析的 XML 并通过层次结构访问它？
    • 如何从特定类中选择特定字段 - 我是否必须为此生成可怕的 XPath 查询？
  • 也许是一个对象数据库？
    • 但是然后 - 我是否必须保留 1000 个或更多 POCO 的（臃肿）模型？序列化/反序列化有多容易？

除了上述之外，我正在使用 .NET 技术进行开发，所以如果有人有特定的想法 - 更好的适合这个生态系统或者至少可以使用 .NET 开发（例如 REST/THRIFT 接口和匹配的 .NET API）

如果你读得那么远——我非常感激，如果你愿意加入——更是如此；-)

4

2 回答 2

2

好的，这只是我的拙见，但一般来说，RDBMS 是具有人们认为理所当然的功能的工具，直到他们离开它们然后讨厌他们切换到的 NoSQL 产品，因为他们不应该首先切换地方。一般来说，根据炒作切换总是错误的。还要记住，与 RDBMS 相比，NoSQL 数据库通常非常有限和专门化，因此你往往放弃的比你得到的要多。对不起，事情就是这样。最后，关系数据库管理系统往往非常擅长优化事情，以至于间歇性性能问题可能很难追踪，但至少您并没有自己进行所有优化。

因此，在阅读了所有您可能认为我认为您应该排除 NoSQL 的内容后，但我不是。我的意思是你应该谨慎对待它。NoSQL 数据库通常针对非常小的领域进行了很好的优化，因此在通用任务上往往表现不佳。另一方面，这种优化有时会让它们变得有用。

而不是用 NoSQL 数据库替换您的关系数据库，问题可能是您是否可以使用一些 NoSQL 数据库作为存储/缓存/预处理的辅助引擎，从而避免您当前遇到的一些问题。在这个观点中，NoSQL 数据库属于传统关系处理系统的附属品。我将在这里查看图形和文档数据库，作为关系数据库的预处理。

于 2012-10-03T07:42:11.563 回答
1

正如 Chris 所说，您应该记住，在 RBMS 世界中您认为理所当然的许多事情在 NoSQL 数据库中经常缺失。您应该记住的另一件事是，NoSQL 是一个涵盖许多技术的非常广泛的术语，因此从这个意义上说，您的问题缺乏焦点。

您在 .NET 中进行开发，因此具有良好集成的 NoSQL 数据库并不多见。您可以考虑的文档数据库是RavenDB。它是用 .NET 编写的（您可以将索引和查询编写为 Linq），它是事务性的（就更新数据而言——尽管索引最终是一致的）并且它是面向文档的（即无模式）。

您可以在此处查看如何在 RaveDB 中处理关系，但请注意，如果您的大多数查询都是图遍历，则您可能需要一个图数据库

于 2012-10-03T08:00:27.960 回答