Hot answers tagged

3

I found one way to do it. On config server: > db.serverCmdLineOpts().parsed.sharding.clusterRole configsvr On shard server: > db.serverCmdLineOpts().parsed.sharding.clusterRole shardsvr Have to be careful as db.serverCmdLineOpts().parsed.sharding.clusterRole is not always defined.


3

Strictly speaking, _id fields are as unique as you make them. As you have discovered, the default values for _id are ObjectIDs but you can populate the field with any data you wish. Therefore, for example, you could use a UUID as I have done in this sharding example and then the chances of a collision across collections would essentially be whatever the ...


3

You feel like they should be separated because that makes perfect sense in the relational world. But as you said in the NoSql world and in MongoDB in particular, you want to group like-items together. I've not done extensive research on Mongo, but have spent some time with the online classes and I believe the answer is to store them together. You probably ...


2

The config servers only hold metadata about which chunk is stored on which cluster, no actual data. There is no such thing called a "master server" in mongoDB, but I think what you are talking about is the shard router (mongos). When that is the case, then that server doesn't store any data at all. So the total capacity of the cluster is the sum of the ...


1

You need to use sudo service to start MongoDB as a service, check the documentation for further details: sudo service mongod --auth --port 27017 --dbpath /var/lib/mongodb


1

Unless you are actively archiving those LVM snapshots and copying them off the servers, having two live nodes doing snapshotting is not overkill. The alternative would be having a single node that would hold all of your snapshots, meaning you would not be able to restore to a previous state if anything happened to that machine. One important thing to ...


1

The MongoDB server actually does not search any locations for config files, and there is (as at MongoDB 3.2) no way to specify multiple config files or include config file fragments. There was a feature suggestion for includes discussed (see: SERVER-14911 in the MongoDB issue tracker), but it was decided that includes are not part of standard YAML and ...


1

The real answer is it depends, but most of the time this probably isn't a good idea. SELECT while it is less nefarious than other the other CRUD commands still carries risk. Why this is probably a bad plan Most applications with databases have some concept of an authenticated user vs a non-authenticated user. If I have unrestricted SELECT only access to ...


1

I happen to work for an IoT\M2M company and we have been using SQL Server just fine for years... Much of the architecture is all event\transaction driven and process based on an \time\event\status and have denormalized the data for multi-purpose uses. Now, ideally when you experience the type of growth that we have over the last few years with millions of ...


1

I won't tell you what are the differences as there are too many. I would recommend to go with SQL databases unless NoSQL tightly fits to your use case. SQL has much more standardized interface and is much easier to integrate and query. The most easiest to deal with and very performant database from R is sqlite. Package RSQLite ships sqlite libraries so ...



Only top voted, non community-wiki answers of a minimum length are eligible