.net - 体系结构-为.NET应用程序选择NoSQL

Question

这个问题是关于选择“正确”类型的NoSQL数据库的，我希望甚至可以根据我将在下面列出的一些需求/用例以及当前正在使用的传统RDBMS解决方案，讨论特定的数据库以及它们为什么适用。地点。时间长了一点，但我认为任何有关此主题的讨论对于尝试学习新范式的人们都将真正有益。关于NoSQL的讨论很多，但据我所知-大多数都是高级的，对新手没有足够的了解。

因此，它来了:

在我的编程生涯的大部分时间(15年)中，我一直在使用传统的RDBMS / SQL系统进行开发，并且拥有丰富的经验。最近，关于NoSQL及其实用性的话题引起了广泛关注-因此，我很想了解NoSQL的好处。我所描述的系统比我所见过的平均TODO或Calender示例要复杂一些，因此可以进行很好的讨论。

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

系统的用法(用例)如下:
0.解析数据(进入数据容器层次结构)并将其加载到关系数据库(通常从​​大约2GB的XML文件中)

查看属性(例如“选择table1中的field1，field2，其中的ID在()中”)并以表格式

查看

跟踪更改(今天和昨天之间的更改-谁的值已更改并添加/删除了实例的参数

检查业务规则:

可以很简单(SELECT idField1 ... idFieldN，paramValue FROM表，其中paramValue <> default”

或更复杂-检查关系-例如x等的子代数

检索类的所有层次结构-选择特定的类实例，其子级，有时还选择该实例或其子级使用的类

对类实例进行更改，然后推回网络(然后看到它确实已执行-更改的验证)。通常需要根据类的层次结构生成一些XML文件。

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

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

该系统在大多数情况下都能正常运行，但有时速度太慢(尤其是在4个系统中)。速度缓慢与从数据库中检索数据有关，但仅与某些部署有关，可能与维护不良或硬件不足(或编程不良)有关，为什么它在其他部署中也能正常工作？

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

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

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

我读到对于动态模式或无模式的NoSQL是自然的
选择。

我阅读了图形数据库，非常适合建模“网络”
(或类似网络)，因此这可能是一个解决方案(node = class，edge
=包容或用法(在边缘具有属性)。

也许使用某些文档数据库并仅部分解析XML并按层次结构访问它？

如何从特定的类中选择特定的字段-我必须为此生成令人讨厌的XPath查询吗？

也许是对象数据库？

，但是-我必须保持1000个或更多POCO的(膨胀)模型吗？序列化/反序列化有多容易？

除了上述内容之外，我还使用.NET技术进行开发，因此，如果有人有特定的想法-更好的想法适合该生态系统，或者至少可以使用.NET开发(例如REST / THRIFT接口(interface)和匹配的.NET API)

如果您读了那么远-我非常感激，如果您愿意加入，我会非常感激;-)

Answer 1

好的，所以这只是我的拙见，但通常来说，RDBMS的功能是人们认为理所当然的功能，直到他们离开它们，然后讨厌他们切换到的NoSQL产品，因为他们从一开始就不应该切换地点。通常，基于炒作进行切换始终是一个错误。还请记住，与RDBMS相比，NoSQL db通常非常有限且专门，因此您倾向于放弃的更多。抱歉，就是这样。最后，关系数据库管理系统往往擅长优化事物，以至于很难找到间歇性的性能问题，但至少您并没有自己进行所有优化。

因此，阅读完所有内容后，您可能会认为我认为您应该排除NoSQL，但事实并非如此。我的意思是您应该对此保持谨慎。通常，NoSQL db对非常小的生态位进行了很好的优化，因此在通用任务上的执行效果很差。另一方面，这种优化有时会使它们有用。

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