Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>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?</p> </blockquote> <p>MongoDB can do this. For better performance, you can set an index on your time field.</p> <blockquote> <p>What should be the specs of server (CPU, RAM, Disk)? any suggestion?</p> </blockquote> <p>I think RAM and Disk would be important.</p> <ul> <li>If you don't want to do <code>sharding</code> to <code>scale out</code>, you should consider a larger size of disk so you can store all your data in it.</li> <li>Your hot data should can fit into your RAM. If not, then you should consider a larger RAM because the performance of MongoDB mainly depends on RAM.</li> </ul> <blockquote> <p>Should i consider Sharding/Replication for this scenario (while considering the performance in writing to synch replica sets)?</p> </blockquote> <p>I don't know many cameras do you have, even 1000 inserts/second with total 1000 cameras should still be easy to MongoDB. If you are concerning insert performance, I don't think you need to do sharding(Except the data size are too big that you have to separate them into several machines).</p> <p>Another problem is the read frequency of your application. It it is very high, then you can consider sharding or replication here. And you can use (timestamp + camera_id) as your sharding key if your query only on one camera in a time range.</p> <blockquote> <p>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?</p> </blockquote> <p>You can separate the table into two collections(<code>archive</code> and <code>current</code>). And set index only on <code>archive</code> if you only query date on <code>archive</code>. Without the overhead of index creation, the <code>current</code> collection should benefit with insert.</p> <p>And you can write a daily program to dump the <code>current</code> data into <code>archive</code>.</p>
    singulars
    1. This table or related slice is empty.
    1. POPros and Cons of using MongoDB instead of MS SQL Server
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USStaeff
    1. USChien-Wei Huang
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the great reply, actually i was thinking on the same lines to split the data into two groups (today/current and archive/old). And my read frequency is on average 1 per 2-seconds. 1: For inserts i can assume that MongoDB v2.2 will have no issues at the rate of 1000/second, but what it will be doing with READ requests at the same time (will it not lock the reads)? How can i avoid this read locking when writes are always occurring. 2: What do you think if i make two separate databases/shards (current and archive) to have separate locks? Then always write to current shard..
      singulars
      1. PO
      1. UStheGeekster
    2. CO... then always write to current shard (with index on datetime) and at the day end move all the data of current shard to archive. The reads for current day will be served by current shard and for previous days will be served by archive shard. Here i can think of few concerns as well, 1) reads for the current days are still vulnerable to r/w locks, 2) have two shards on same machine might rise some Memory conflicts among both for writes and reads and indexes, 3) at day end if moving the data from current shard to archive take few minutes, should reads during that time goto current or archive?
      singulars
      1. PO
      1. UStheGeekster
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload