Related article : Indexing Tools for Microsoft SQL Server (You might want to read the article before this one to get a better picture)
The other indexing tool available in SQL Server is the Database Engine Tuning Advisor. This tool allows SQL Server to analyze a workload from a file, a table, or the plan cache. The output of the DTA can assist in providing recommendations for indexing and configuring partitions for the workload. The chief benefit of using the tool is that it doesn’t require a deep understanding of the underlying databases to make the recommendations.
While I was engaged in a conversation with our Marketing Manager about the differences between Bespoke Software versus Commercial Off the Shelf Software (AKA COTS), it occurred to me that “Bespoke” sounded like a very arcane word, almost alien yet it was popular in IT parlance and rhetoric. I personally found that people used the word to sound erudite and cultured. So I decided to do some digging.
Role of the Mongo Shell
The shell & MongoD server
The Shell in a nutshell
Your application talks to the MongoD server when it needs to read or write data. But what exactly are they doing? How is the Mongo server doing? Are the updates being committed to the server? Is the server configured correctly and performing well? All of these questions can be answered with the shell. A shell is nothing but a DOS prompt (in windows terms) like application that allows you to inspect and interrogate the server The shell uses the same wire protocol that your application would be using.
MongoDB Consistency Scenarios
Continuing from the previous Post
Data consistency is a big deal, so its worth taking a look at MongoDB handles consistency. In a single database scenario, if we have 2 observers A & B, and there is a document with a value X=’123′. At some point A decides to update the document with say ‘789’ , during that update B’s observation could either be 123 or 789 if it waited for the lock to be released.
When you scale out things become a little more involved, assume again 2 observers A & B with a primary database and a secondary database. Mongo only accepts writes into the primary database at a time. So lets say A updates the document and sets the value to 789, replication should also occur to take that value and populate it in the secondary database. Eventually the value will be replicated in the primary as well as the secondary database. But lets take a step backward, A may have updated the document, but B may not see that change yet because replication has not happened yet to the secondary database. This is what is called as Eventual Consistency. Eventually the document will make it over to the secondary database.