Moment toISOString date format

https://stackoverflow.com/questions/25725019/how-do-i-format-a-date-as-iso-8601-in-moment-js

moment.toISOString();


it will return 2018-06-27T05:55:46.055Z

mongodb auto increment

https://www.tutorialspoint.com/mongodb/mongodb_autoincrement_sequence.htm

Difference between Sharding And Replication on MongoDB

https://www.howtoforge.com/tutorial/deploying-mongodb-sharded-cluster-on-centos-7/

49down votefavorite

42

I am just confuse about the Sharding and Replication that how they works..According to Definition

Replication: A replica set in MongoDB is a group of mongod processes that maintain the same data set.

Sharding: Sharding is a method for storing data across multiple machines.

As per my understanding if there is data of 75 GB then by replication (3 servers), it will store 75GB data on each servers means 75GB on Server-1, 75GB on server-2 and 75GB on server-3..(correct me if i am wrong)..and by sharding it will be stored as 25GB data on server-1, 25Gb data on server-2 and 25GB data on server-3.(Right?)...but then i encountered this line in the tutorial

Shards store the data. To provide high availability and data consistency, in a production sharded cluster, each shard is a replica set

As replica set is of 75GB but shard is of 25GB then how they can be equivalent...this makes me confuse a lot...I think i am missing something great in this. Please help me in this.

74down voteaccepted

A Replica-Set means that you have multiple instances of MongoDB which each mirror all the data of each other. A replica-set consists of one Master (also called "Primary") and one or more Slaves (aka Secondary). Read-operations can be served by any slave, so you can increase read-performance by adding more slaves to the replica-set (provided that your client application is capable to actually use different set-members). But write-operations always take place on the master of the replica-set and are then propagated to the slaves, so writes won't get faster when you add more slaves.

Replica-sets also offer fault-tolerance. When one of the members of the replica-set goes down, the others take over. When the master goes down, the slaves will elect a new master. For that reason it is suggested for productive deployment to always use MongoDB as a replica-set of at least three servers, two of them holding data (the third one is a data-less "arbiter" which is required for determining a new master when one of the slaves goes down).

A Sharded Cluster means that each shard of the cluster (which can also be a replica-set) takes care of a part of the data. Each request, both reads and writes, is served by the cluster where the data resides. This means that both read- and write performance can be increased by adding more shards to a cluster. Which document resides on which shard is determined by the shard key of each collection. It should be chosen in a way that the data can be evenly distributed on all clusters and so that it is clear for the most common queries where the shard-key resides (example: when you frequently query by user_name, your shard-key should include the field user_name so each query can be delegated to only the one shard which has that document).

The drawback is that the fault-tolerance suffers. When one shard of the cluster goes down, any data on it is inaccessible. For that reason each member of the cluster should also be a replica-set. This is not required. When you don't care about high-availability, a shard can also be a single mongod instance without replication. But for production-use you should always use replication.

So what does that mean for your example?

                            Sharded Cluster             
             /                    |                    \
      Shard A                  Shard B                  Shard C
        / \                      / \                      / \
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+
|Primary| |Secondary|    |Primary| |Secondary|    |Primary| |Secondary|
|  25GB |=| 25GB    |    | 25 GB |=| 25 GB   |    | 25GB  |=| 25GB    |   
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+

When you want to split your data of 75GB into 3 shards of 25GB each, you need at least 6 database servers organized in three replica-sets. Each replica-set consists of two servers who have the same 25GB of data.

You also need servers for the arbiters of the three replica-sets as well as the mongos router and the config server for the cluster. The arbiters are very lightweight and are only needed when a replica-set member goes down, so they can usually share the same hardware with something else. But Mongos router and config-server should be redundant and on their own servers.

get current date and time with plain javascript and by using moment.

var moment=require('moment');

const currentDate = new Date();

const currentDateISOstring = currentDate.toISOString();

var data=moment.utc().format('YYYY-MM-DD[T]HH:mm:ss.SSS[Z]');

console.log(currentDateISOstring);

console.log(data);

git tutorial

`1 - git stash
2 - git checkout develop
3 - git pull
4 - git rebase develop <your branch>
5 - git stash apply


Please wait, that is for a situation where you're working on a branch and you've uncommited changes and you suddenly want to move to other branch for some work. Lets say you need to fix some bug (edited)
Git stash will stash your changes and once you come to the same branch and execute `git stash apply` it will provide you those changes

But lets say you don't have that situation, you're working as normal feature branch and you've done with your changes and planning to push a PR then you don't need any stash related commands
In that case you need, `git checkout develop`, `git pull`, `git rebase develop <your branch>`, `fix conflicts if any`, `git push origin your branch name` if failed then `git push --force origin your branch name`
got it?`

mongoDb query

collection -> table

use db mydb ->create database if not exist and switch to database
show dbs -> list database
create user

db.createuser({
user:"a",
pwd:"",
roles:["read",write]
})

collections
create collection
db.createCollection('cusomer');
insert data into collection
db.customer.insert({ojectof data});
see data customer collection

db.customer.find([{insert multipale data at a time }]);
create index for each record

update collection filed data
db.cllectionname.update({filename with value to update},{new object which replace existing})
it will update hole object

user $set key word with filed to just update the required filed.
db.collection.update({username:"pawn"},{$set:{gender:"male"});
increment the age with five use $inc:{age:5}

unset->remove an attributes from collection object
$unset:{age:50}

if not found then insert user third param {upset:true}
rename
db.collectionname.update({},{$rename:{"gender":"sex"}})

db.collectionname.remove({name:"Pawan"}) ;
delete one
db.collectionname.remove({name:"Pawan"},{justOne:"true"}) ;

db.collectionname.find($or[{name:"Pawan"},{name:"Sumit"}]) ;

Promise thanable example

https://stackoverflow.com/questions/21242441/avoiding-nested-callbacks-with-promises

blubird tutorial

http://www.supermean.org/examples/bluebird

moment. experiment

const moment = require('moment');

const _ = require('lodash');

const currentDateTime = moment();

const releseDateTime = moment("2018-06-07T10:49:16.672");

const seatingDateTime = moment("2018-06-04T10:49:16.672");

let currentPhase;

console.log("---current-----",currentDateTime);

console.log(releseDateTime);

console.log(seatingDateTime);

if (currentDateTime.isSameOrBefore(releseDateTime)) {

console.log("1");

} else if (currentDateTime.isAfter(releseDateTime) && currentDateTime.isSameOrBefore(seatingDateTime)) {

console.log("2");

} else {

console.log("3");

}

var constants= {

"PHASE_NO_DATES": 'nodates',

"PHASE_DATES": 'dates',

"PHASE_SEATING": 'seating'

}

Git commit message change

https://gist.github.com/nepsilon/156387acf9e1e72d48fa35c4fabef0b4