我是NoSQL世界的新手，并且正在考虑将我的MS Sql Server数据库替换为MongoDB。我的应用程序(用.Net C＃编写)与IP摄像头交互，并将来自Camera的每个图像的元数据记录到MS SQL数据库中。平均而言，我每天为每个摄像机插入大约86400条记录，并且在当前数据库模式中，我为单独的摄像机图像创建了单独的表，例如， Camera_1_Images，Camera_2_Images ... Camera_N_Images。单个图像记录由简单的元数据信息组成。像AutoId，FilePath，CreationDate。为了向此添加更多详细信息，我的应用程序为每个摄像头启动单独的进程(.exe)，每个进程在数据库的相对表中每秒插入1条记录。

我需要(MongoDB)专家就以下问题提出建议：

欢迎任何其他建议。

我自己是NoSQL数据库的先驱。所以我以牺牲潜在的选票为代价来回答这个问题，但对我来说这将是一次很棒的学习经历。

Before trying my best to answer your questions I should say that if MS
SQL Server is working well for you then stick with it. You have not
mentioned any valid reason WHY you want to use MongoDB except the fact
that you learnt about it as a document oriented db. Moreover I see
that you have almost the same set of meta-data you are capturing for
each camera i.e. your schema is dynamic.

• 判断MongoDB是否适合保存这些数据，最终将根据时间范围查询(例如，在指定的小时之间检索特定相机的所有图像)？关于我的案例的基于文档的架构设计的任何建议？

MongoDB是一个面向文档的数据库，擅长在聚合中查询(你称之为文档)。由于您已经将每个摄像机的数据存储在自己的表中，因此在MongoDB中，您将为每个摄像机创建一个单独的集合。以下是执行日期范围查询的方法。

• 什么应该是服务器(CPU，RAM，磁盘)的规格？有什么建议吗？

所有NoSQL数据库都是为了在商用硬件上进行横向扩展而构建的。但顺便问一下，你可能会考虑通过扩大规模来提高性能。您可以从合理的计算机开始，随着负载的增加，您可以继续添加更多服务器(向外扩展)。您无需计划和购买高端服务器。

• 我应该考虑为这种情况进行分片/复制(同时考虑写入同步副本集的性能)吗？

MongoDB将整个数据库锁定为单次写入(但是其他操作的产生)，并且适用于读取数多于写入数的系统。所以这取决于你的系统。有多种分片方式，应该是特定于域的。一般答案是不可能的。但是，可以给出一些例子，如地理分片，分支等。

另请阅读CAP定理的简明英文介绍

更新了对分片注释的回答

根据他们的文档，您应该考虑部署分片群集，如果：

• your data set approaches or exceeds the storage capacity of a single node in your system.
• the size of your system’s active working set will soon exceed the capacity of the maximum amount of RAM for your system.
• your system has a large amount of write activity, a single MongoDB instance cannot write data fast enough to meet demand, and all other
  approaches have not reduced contention.

所以基于最后一点是的。自动分片功能用于扩展写入。在这种情况下，每个分片都有一个写锁定，而不是每个数据库。但我的理论答案。我建议你咨询10gen.com小组。

to tell if MongoDB is good for holding such data, which eventually
will be queried against time ranges (e.g. retrieve all images of a
particular camera between a specified hour)?

这种静止对我来说太主观了。从众多SQL解决方案的个人经验(具有讽刺意味的不是MS SQL)，我会说如果做得对，它们都同样好。

也：

What should be the specs of server (CPU, RAM, Disk)? any suggestion?

取决于只有你知道的太多变量，但是一小部分商品硬件运行良好。我无法真正回答这个问题，这将归结为你的测试。

至于架构，我会找一个结构文件：

只要你没有深入嵌入，这应该很容易保持和更新，因为它可能会变得有点痛苦，但这取决于你的查询。

不仅如此，这应该对分片有好处，因为你在一个文档中拥有所需的所有数据，如果你在_id上进行分片，你可能会在这里获得完美的设置。

Should i consider Sharding/Replication for this scenario (while considering the performance in writing to synch replica sets)?

可能许多人认为他们需要进行分片，而实际上他们只需要更加智能地设计数据库。 MongoDB是非常自由的形式，所以有很多方法可以做错，但话虽如此，还有很多方法可以解决问题。我个人会记住分片。复制也非常有用。

Are there any benefits of using multiple databases on same machine, so that one database will hold images of current day for all cameras, and the second one will be used to archive previous day images?

即使MongoDBs写入锁定在DB级别(当前)，我会说：不。正确的文档结构和正确的分片/复制(如果需要)应该能够在单个基于文档的集合中处理这个问题。 D B。不仅如此，您还可以将群集中的写入和读取定向到某些服务器，以便在群集中的某些计算机之间创建并发情况。我会通过DB分离来促进MongoDBs并发功能的正确使用。

编辑

在再次阅读问题之后，我从我的解决方案中省略了您每天为每个摄像头插入80k +图像。因此，我实际上在一个名为images的集合中为每个图像创建一行，然后是一个camera集合，并像在SQL中一样查询这两个。

在camera_id上对images集合进行分片应该同样容易。

另外，请确保您的服务器考虑到您的工作。

to tell if MongoDB is good for holding such data, which eventually
will be queried against time ranges (e.g. retrieve all images of a
particular camera between a specified hour)? Any suggestions about
Document Based schema design for my case?

MongoDB可以做到这一点。为了获得更好的性能，您可以在时间字段上设置索引。

What should be the specs of server (CPU, RAM, Disk)? any suggestion?

我认为RAM和磁盘很重要。

• 如果您不想sharding到scale out，则应考虑更大的磁盘大小，以便将所有数据存储在其中。
• 您的热门数据应该可以放入您的RAM中。如果没有，那么你应该考虑更大的RAM，因为MongoDB的性能主要取决于RAM。

Should i consider Sharding/Replication for this scenario (while
considering the performance in writing to synch replica sets)?

我不知道你有多少相机，即使1000个插件/秒，总共1000个相机仍然应该很容易MongoDB。如果您关注插入性能，我认为您不需要进行分片(除非数据大小太大，您必须将它们分成几个机器)。

另一个问题是您的应用程序的读取频率。它非常高，那么你可以在这里考虑分片或复制。
如果您的查询仅在一个时间范围内的一台摄像机上，您可以使用(timestamp + camera_id)作为分片键。

Are there any benefits of using multiple databases on same machine, so
that one database will hold images of current day for all cameras, and
the second one will be used to archive previous day images?

您可以将表分成两个集合(archive和current)。如果只在archive上查询日期，则仅在archive上设置索引。如果没有索引创建的开销，current集合应该会受益于insert。

您可以编写每日程序将current数据转储到archive。