这个问题是关于选择＆＃34;权利＆＃34; NoSQL数据库的类型，我希望甚至可以讨论具体的和它们适合的原因，根据我将在下面列出的一些要求/用例以及当前的传统RDBMS解决方案。这有点长，但我认为任何关于这个主题的讨论都可能对试图学习新范式的人真正有益。有许多关于NoSQL的讨论，但是从我所看到的 - 大多数是高级别的，并没有给新手提供足够的见解。
所以，它来了：
在我的大部分编程生涯（15年）中，我一直在针对传统的RDBMS / SQL系统进行开发，并且拥有良好的使用经验。最近，NoSQL有一个很大的嗡嗡声，它是多么有用 - 所以我有兴趣了解它是如何有益的。我描述的系统比我所见过的平均TODO或Calender例子复杂一点，因此可以进行很好的讨论。
该系统与相对复杂的蜂窝网络有关 - 大约有300个＆＃34;类＆＃34;在这样的网络中（和＃34;完全部署＆＃34;可以有几个网络在一起，并且可以增长到1000个以上的类），每个实例具有不同数量的实例（100,000-10s）。每天（有时是一天几次）将其加载到数据库以驱动系统。类之间的关系是包含或＆＃34;用法＆＃34;。域名变化相对较快（网络软件更新之间约3个月，每个通常意味着向现有类添加参数并添加一些（10-20）新类）。
系统的用法（用例）如下： 0.解析数据（进入数据容器层次结构）并将其加载到关系数据库（通常来自大约2GB的XML文件）
在RDBMS解决方案中，为了克服这些要求，我将数据映射到关系表（每个类的一个类），然后保存元数据和关系字典。此外，对于数据检索任务，创建了一个通用数据容器（类类型名称+键值（或值））或使用可以合并到视图或文件中的DataTables。
这个架构（平台）意味着在升级时我所要做的就是更新/创建表（alter / create table）并更新元数据和关系 - 其余代码是＆＃34; generic＆＃34 ;并由元数据驱动。唯一的例外是上面的（4）有时需要我硬编码（将子项添加到数据检索层次结构），尽管我最终也推广了这个过程（分层数据检索 - 基于父级的id获取子元素，依此类推层次）。
在大多数情况下，系统运行良好，但有时太慢（尤其是4）。缓慢与从数据库中检索数据有关，但仅在某些部署中，它可能与维护不良或硬件不足（或编程错误有关，但为什么它在其他部署中运行良好？）
我将补充说，由于域是一个网络，每个实例都有一个不同的名称 - 通常由它的层次结构组成（实例和它的父级，例如＆＃34; Node = ER222，Subrack = 3，Slot = 5＆＃34;或＆＃34; Node = ER222，Equipment = 1，Sector = 2，Carrier = C2＆＃34;）并且每个类的层次结构通常是相同的（尽管某些类可以出现在几个层次结构（例如，有不同的祖先）
通常系统负载不大 - 可能多达50个活跃用户但通常少得多。在更大的网络中，这可能会增加到300-400个用户。
现在我想开发一个具有类似要求的系统，并考虑NoSQL可能给出的优势：
除了上述内容之外，我正在使用.NET技术开发，所以如果有人有特定的想法 - 更适合这个生态系统的想法或者至少可以用.NET开发（例如REST / THRIFT接口和匹配的.NET API） ）
如果你读得那么远 - 我非常感激，如果你愿意加入 - 甚至更多; - ）
答案 0 :(得分：2)
好的，所以这只是我的拙见，但一般来说，RDBMS是具有人们理所当然的功能的工具，直到他们离开他们然后讨厌他们切换到的NoSQL产品，因为他们从来没有切换过首先。一般来说，基于炒作切换总是是一个错误。另外请记住，与RDBMS相比，NoSQL数据库通常非常有限和专业，因此您倾向于放弃比您获得的更多。对不起，就是这样。最后，关系数据库管理系统往往非常善于优化，间歇性的性能问题很难被追踪，但至少你自己并没有进行所有的优化。
所以阅读了所有你认为我认为你应该排除NoSQL的内容，但我不是。我所说的是你应该谨慎对待它。 NoSQL db通常非常适合非常小的利基，因此在通用任务上往往做得很差。另一方面，这种优化有时会使它们变得有用。
问题可能是您是否可以使用某些NoSQL数据库作为存储/缓存/预处理的辅助引擎，从而避免您目前遇到的一些问题，而不是用NoSQL数据库替换您的关系数据库。在此视图中，NoSQL db属于传统关系处理系统的附件。我将在这里查看图形和文档数据库，作为关系数据库的预处理。
答案 1 :(得分：1)