使用MongoDB而不是MS SQL Server的优点和缺点 [英] Pros and Cons of using MongoDB instead of MS SQL Server

问题描述

我是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）专家提出的以下问题的建议：

1. 说明MongoDB是否适合持有这样的数据，最终将查询时间范围（例如，在特定时间内检索特定摄像机的所有图像）？关于我的案例的基于文档的模式设计的任何建议？




2. 服务器（CPU，RAM，磁盘）的规格应该是什么？任何建议？




3. 我应该考虑这种情况下的Sharding /复制（同时考虑到同步复制集的写作性能）？




4. 在同一台机器上使用多个数据库有什么好处，所以一个数据库可以保存所有相机当前的图像，第二个将用于归档前一天的图像？我正在考虑在分开的数据库上分割读写操作。因为所有读请求可能由第二个数据库提供，并写入第一个。会不会有益？如果是，那么任何想法，以确保两个数据库总是同步。

欢迎任何其他建议。 p>

解决方案

我自己是NoSQL数据库的启动器。所以我以牺牲潜在的投票为代价来回答这个问题，但对我来说这将是一个很好的学习经历。

之前尽我所能来回答你的问题我应该说，如果MS
SQL Server正在为你工作，那么坚持下去。你没有
提到任何有效的理由为什么你想使用MongoDB，除了你知道它作为面向文档的数据库的事实
。此外，我看到
，您几乎与每个摄像机
捕获的几乎相同的元数据集，即您的模式是动态的。

告诉MongoDB是否适合持有这样的数据，最终会根据时间范围进行查询（例如，在指定的时间内检索特定的摄像机的所有图像）？任何关于我的案例的基于文档的模式设计的建议？

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

• 服务器（CPU，RAM，磁盘）的规格应该是什么？任何建议？

所有NoSQL数据库都是根据商品硬件横向扩展构建的。但是按照您提出的问题，您可能会考虑通过扩展改善性能。您可以从合理的机器开始，随着负载的增加，您可以继续添加更多的服务器（扩展）。您不需要计划和购买高端服务器。

• 我应该考虑使用Sharding /同步复制集）？

MongoDB 将整个数据库锁定为单个写入（但为其他操作生成），并且适用于具有比写入更多读取的系统。所以这取决于你的系统如何。有多种分片方式，应该是域名具体的。一般的答案是不可能的。然而，一些例子可以按照地理，分行等分类。

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

更新为评论sharding

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

• 您的数据设置方法或超过系统中单个节点的存储容量。


• 系统的活动工作集的大小将很快超过您系统的最大RAM容量。 / li>
  
• 您的系统具有大量写入活动，单个MongoDB实例无法快速写入数据以满足需求，而所有其他
  方法尚未减少争用。

所以基于最后一点是的。自动分片功能是为了缩放写入而构建的。在这种情况下，您每个 shard 有一个写入锁定，而不是每个数据库。但我是一个理论上的答案。我建议你从10gen.com集团咨询。

I am new to NoSQL world and thinking of replacing my MS Sql Server database to MongoDB. My application (written in .Net C#) interacts with IP Cameras and records meta data for each image coming from Camera, into MS SQL Database. On average, i am inserting about 86400 records per day for each camera and in current database schema I have created separate table for separate Camera images, e.g. Camera_1_Images, Camera_2_Images ... Camera_N_Images. Single image record consists of simple metadata info. like AutoId, FilePath, CreationDate. To add more details to this, my application initiates separate process (.exe) for each camera and each process inserts 1 record per second in relative table in database.

I need suggestions from (MongoDB) experts on following concerns:

1. 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?

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

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

4. 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? I am thinking on this with respect to splitting reads and writes on separate databases. Because all read requests might be served by second database and writes to first one. Will it benefit or not? If yes then any idea to ensure that both databases are synced always.

Any other suggestions are welcomed please.

解决方案

I am myself a starter on NoSQL databases. So I am answering this at the expense of potential down votes but it will be a great learning experience for me.

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.

• 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 being a document oriented db, is good at querying within an aggregate (you call it document). Since you already are storing each camera's data in its own table, in MongoDB you will have a separate collection created for each camera. Here is how you perform date range queries.

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

All NoSQL data bases are built to scale-out on commodity hardware. But by the way you have asked the question, you might be thinking of improving performance by scaling-up. You can start with a reasonable machine and as the load increases, you can keep adding more servers (scaling-out). You no need to plan and buy a high end server.

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

MongoDB locks the entire db for a single write (but yields for other operations) and is meant for systems which have more reads than writes. So this depends upon how your system is. There are multiple ways of sharding and should be domain specific. A generic answer is not possible. However some examples can be given like sharding by geography, by branches etc.

Also read A plain english introduction to CAP Theorem

Updated with answer to the comment on sharding

According to their documentation, You should consider deploying a sharded cluster, if:

• 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.

So based upon the last point yes. The auto-sharding feature is built to scale writes. In that case, you have a write lock per shard, not per database. But mine is a theoretical answer. I suggest you take consultation from 10gen.com group.

这篇关于使用MongoDB而不是MS SQL Server的优点和缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！