Most of my recent blogging has been done on the dbKoda website where I've been writing mostly about MongoDB performance tuning. If you are interested, here are links to a few of the more interesting posts:
The dbKoda team just released our third major version of dbKoda - the open source, fat free development and administration tool for MongoDB.
This release contains lots of bug fixes, the ability to view data as a chart or in tabular form, and the ability to convert mongodb shell commands into Node.js syntax. Check out the blog post outlining all the new features at https://www.dbkoda.com/blog/2017/11/06/New-Features-in-dbKoda0.8
An updated version of this blog post can be found at https://www.dbkoda.com/blog/2017/10/14/Optimizing-the-order-of-aggregation-pipelines
MongoDB does have a query optimizer, and in most cases it's effective at picking the best of multiple possible plans. However it's worth remembering that in the case of the aggregate function the sequence in which various steps are executed is completely under your control. The optimizer won't reorder steps into the optimal sequence to get you out of trouble.
Optimizing the order of steps probably comes mainly to reducing the amount of data in the pipeline as early as possible – this reduces the amount of work that has to be done by each successive step. The corollary is that steps that perfom a lot of work on data should be placed after any filter steps.
Please go to https://medium.com/dbkoda/optimizing-the-order-of-aggregation-pipelines-44c7e3f4d5dd to read the rest of this post
Like most database systems, MongoDB provides API calls that allow multiple documents to be inserted or retrieved in a single operation.
These “Array” or “Bulk” interfaces improve database performance markedly by reducing the number of round trips between the client and the databases – dramatically. To realise how fundamental an optimisation this is, consider that you have a bunch of people that you are going to take across a river. You have a boat that can take 100 people at a time, but for some reason you are only taking one person across in each trip – not smart, right? Failing to take advantage of array inserts is very similar: you are essentially sending network packets that could take hundreds of documents over with only a single document in each packet.
Read the rest of this post at https://medium.com/dbkoda/bulk-operations-in-mongodb-ed49c109d280
Specialized graph databases such as Neo4J specialize in traversing graphs of relationships – such as those you might find in a social network. Many non-graph databases have been incorporating Graph Compute Engines to perform similar tasks. In the MongoDB 3.3 release, we now have the ability to perform simple graph traversal using the $graphLookup aggregation framework function. This will become a production feature in the 3.4 release.
The new feature is documented in MongoDB Jira SERVER-23725. The basic syntax is shown here:
1: {$graphLookup:
2: from: <name of collection to look up into>,
3: startWith: <expression>,
4: connectFromField: <name of field in document from “from”>,
5: connectToField: <name of field in document from “from”>,
6: as: <name of field in output document>,
7: maxDepth: <optional - non-negative integer>,
8: depthField: <optional - name of field in output
9: documents>
10: }
Please go to https://medium.com/dbkoda/optimising-graph-lookups-in-mongodb-49483afb55c8 to read the rest of this article (updated for MongoDB 3.6)