MongoDB is a JSON-style store. Just like JSON, we can nest objects within other objects, and also arrays of data within objects.
This then suggests the question or issue: how does one perform a query on nested objects? Index keys in nested objects? This is very important of course. The following doc page explains the method.
Databases and Predictability of Performance
A subject which perhaps doesn’t get enough attention is whether the performance of a database is predictable . What we are asking is: are there ever any surprises or gotchas in the time it takes for a db operation to execute? For traditional database management systems, the answer is yes. For example, statistical query optimizers can be unpredictable: if the statistics for a table change in production, the query plan may change. This could result in a big change in performance – perhaps better, perhaps worse – but it certainly wasn’t an expected change. Query plans and performance profiles that were never tested in QA may go into effect. Another potential issue is locking. A lock from one transaction may cause another operation that is normally very fast to be slow. If a system is simple enough, it is predictable. memcached is very predictable in performance: perhaps that is one reason it is so widely used. Yet we also need more sophisticated tools, and as they become more advanced, predictability is hard. A goal of the MongoDB project is to be reasonably predictable in performance. Note this is a goal: the database is far from perfect in this regard today, but we think it certainly moves things in the right direction. For example, the MongoDB query optimizer utilitizes concurrent query plan evaluation to assure good worst-case performance on queries, at a slight expense to average query time. Further, the lockless design eliminates unpredictability from locking. Other areas of the system could still use improvement: particularly concurrent query execution. That said, this is certainly considered an important area for the project and will only get better over time.
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .