Quantcast
Channel: MongoDB | Blog
Viewing all articles
Browse latest Browse all 2423

How MongoDB Could Have Changed Star Wars and Saved the Jedi

$
0
0

May the 4th be with you! Here at MongoDB, lots of us love Star Wars. It got us thinking about how the events that unfolded throughout the movie franchises could have been different had MongoDB products and features been available. So to celebrate Star Wars Day, this article will take a light(side)-hearted look at exactly that!

MongoDB Atlas: How has nobody heard of the Jedi?

One of the questions that was asked a lot by fans when Star Wars: Episode VII – The Force Awakens was released was how Rey, Finn, and many others in the Star Wars universe didn’t know that the Jedi were real, let alone still existed.

This can be explained by Emperor Palpatine ensuring that all Jedi Knights, temples, and traces of the Jedi were erased. But what if this information had been stored in MongoDB Atlas, our application data platform in the cloud?

One of the core features of MongoDB Atlas is a document database-as-a-service (DBaaS), which allows for storing data as JSON-like documents in collections in the cloud, accessible from anywhere with a connection to the internet.

Under the hood, this database supports high availability using replica sets, which are sets of nodes (the minimum and default value is three nodes), with one acting as the primary node and two or more as secondary nodes. The data is replicated across these three nodes, with availability handled by Atlas automatically. If the primary node goes down, the replica sets promote a secondary node to primary.

A MongoDB Replica Set showing a primary node and two secondary nodes

Imagine if, following Emperor Palpatine and Darth Vader destroying evidence of the Jedi Order, the data could have recovered itself thanks to the high availability of clusters on Atlas.

Atlas cloud recovery would have also helped prevent deleting of data in the Jedi Archives. In Star Wars: Episode II – Attack of the Clones, Obi Wan-Kenobi visits the Jedi Archives on Coruscant to locate the planet Kamino, where they expect to find answers on who attempted to assassinate Senator Padmé Amidala. However, Obi Wan-Kenobi finds himself having to call for the help of the librarian, Jocasta Nu, because he cannot find any traces of the planet in the archives. She famously says that if the planet is not in the archives then it simply does not exist.

Atlas’ database gives the ability to store data in the cloud, available anywhere as long as you can access it. Therefore, you could also argue that the information in the archives would have been available from anywhere, not just in the one server within the Jedi Archives. Luminous beings we might be, but database specialists, the Jedi were not.

Security: You don't belong here!

In a world with ever more data being consumed and stored, people are becoming more aware of how secure their data is (or is not). When looking to use MongoDB Atlas, developers are often concerned about how safe their data is in the cloud.

MongoDB Atlas comes with a lot of security features pre-configured from the start. This includes isolation, authorization, and encryption.

Security stack showing Isolation, Authorization and Encryption
Security stack showing Isolation, Authorization and Encryption

We firmly believe that your data should be private and only visible to those with the rights to see it.

In Star Wars: Episode VI – Return of the Jedi, the Alliance learns of the construction of a second Death Star and discovers that an energy shield generator to protect the new Death Star is on the forest moon planet Endor. Leia, Han Solo, Chewbacca, R2-D2, C-3P0, and the Ewoks fight in the Battle of Endor for access to the bunker containing the generator.

Thanks to R2-D2 and C-3P0 drawing away the Imperial Army, the enemy is attacked by the Ewoks. Chewbacca is then able to steal an AT-ST and rescue his allies, who are attempting to hack into the bunker.

They successfully gain entry to the bunker, plant explosives, and expose the new Death Star, allowing it to be destroyed by the Rebel Fleet.

However, if MongoDB security had been involved, the rebels wouldn’t have gained access to the bunker and the energy shield protecting the Death Star would have remained, meaning the Empire could have won. Death Star II was able to travel across the galaxy and strike fear into the hearts of many, and perhaps this might have prevented the creation of Starkiller Base in The Force Awakens and its destruction of the entire Hosnian system, saving millions of lives. While the Empire could have wiped out the Alliance and taken control of the galaxy with the second Death Star, it would have had to remain within range of its shield generator on the forest moon of Endor, unable to terrorize the galaxy at large as Starkiller Base eventually did. The First Order and Kylo Ren may never have risen to power. Luke Skywalker may not have escaped the Emperor or redeemed his father. Life would probably look very different for those millions of lives saved in the Hosnian system. We may have, in fact, seen Darth Vader and Luke Skywalker rule the galaxy as father and son. Scary thought!

Data API: Bye-Bye, R2-D2

MongoDB Atlas Data API is a new feature, currently in preview, that allows developers to access their Atlas hosted database cluster via HTTP calls over the web using just a unique endpoint URL and an API key. This opens up the possibility of using the power of the MongoDB document database model in more ways and more scenarios.

You might choose to use it because you don’t want the overhead of installing and using a driver for your chosen language or platform. This could be because you are prototyping or just prefer the API approach. You may not even have a driver for that scenario but can make HTTP requests. One example of this scenario is the Internet of Things (IoT), where you often won’t have a driver as an option but can easily make calls over the web. Another scenario is from a SQL stored procedure. That might sound controversial, but what if you want to push data to both a relational database and an Atlas cluster at the same time to help with migrating over to the most popular non-relational database in the world?

A driver is a programming interface, allowing for use with whatever the driver is intended for. The MongoDB driver, available for multiple programming languages, allows communication with a MongoDB database via a connection string. It simplifies that process and handles the communication so developers don’t have to write complicated low-level code.

In the Star Wars universe, you can think of droids as an interface to the data in the world around them. R2-D2 is an astromech droid, whose primary function is to provide navigational abilities but is able to do far more, including interfacing with other computers via a SCOMP link, disabling autopilot on the Naboo starfighter, picking up distress signals, locating Emperor Palpatine on Grievous’s ship, and, of course, sharing the Death Star plans with the Alliance.

So, if there was MongoDB Atlas Data API in the Star Wars universe, what might that look like? This could be a simple data pad, similar to a smartphone. Instead of relying on R2-D2, BB-8, or Chopper to act as an interface to the information in different computers around the galaxy, the data pads could do this instead, providing the ability to access the data stored in Atlas.

Using MongoDB, the Death Star plans might have been added to a collection in the database and accessible to all those who were authorized. This would have prevented some of the danger seen at the start of Star Wars: Episode IV – A New Hope, when Princess Leia had to upload the plans into R2-D2.

Of course, R2-D2 would still have proved useful in other situations, such as in battle, putting out fires in the Millenium Falcon, or throwing Luke his lightsaber during a battle in Star Wars: Episode VI – Return of the Jedi. But some of the key roles he played could have been made redundant if the Data API–enabled data pad had been available instead.

Sharding: Where art thou Anch-to

Speaking of R2-D2, another event he was involved in could have been different had there been a feature of MongoDB in the Star Wars universe, sharding.

When you have a really large data set, like, I don’t know, all the information in the galaxy’s HoloNet, you might want to break it down into smaller pieces in order to make it faster and easier to search through.

Sharding is a perfect example of this in action. Sharding works by segregating your data into smaller pieces based on a field in your document. A common real-world comparison would be a library. In a library, books aren’t all just thrown on a shelf in the order they were acquired by the library. They are instead broken down into different shelves, sorted by author surname. The equivalent of this in the database world is a sharding key, which tells you exactly where to head first, saving you time and effort.

In Star Wars: Episode VII – The Force Awakens, the Alliance including Rey want to find Luke Skywalker. If the galaxy information had been sharded, it would be possible for it to have been searched to find Luke’s location much faster, without the need to find a particular map to fill out a local data set. Access to Ahch-to, the location of the ancient Jedi Temple and the galaxy’s only green-milk-producing thala-sirens, would be just a query away..

This also ties in nicely to the previous section about the Data API. Without the need to use R2-D2 for the missing piece but instead use a data pad to query all the known information on the galaxy, the Alliance may have found Luke much sooner — especially if they were able to use MongoDB’s powerful query language to perform complex queries on the data using the aggregation pipeline.

MongoDB is a non relational database that can be used by all living things. It surrounds docs, penetrates analytics, and binds the galaxy together.

There we have it, a trip through the galaxy and the events of Star Wars to see how the timeline might have been different had MongoDB been around.

MongoDB is a non-relational database that can be used by all living things. It surrounds documents, penetrates analytics, and binds the Galaxy together.

  • The knowledge of the Jedi wouldn’t have been erased and their reputation tarnished had MongoDB Atlas and its high availability been available.

  • The energy shield generator on Endor would have survived, meaning Death Star II may never have been destroyed, allowing the Empire to take full control of the galaxy but thwarting the rise of the First Order.

  • R2-D2 might not have been so important had MongoDB Atlas Data API been available on data pads, allowing direct access over the internet to the data instead of requiring a driver.

  • Luke Skywalker may have been found much sooner had sharding been available alongside powerful querying functionality such as the aggregation pipeline to bypass the need to find a map and get the missing piece from R2-D2.

How can you use the power of MongoDB Atlas today to change your own universe? Get started today with our free forever M0 tier.

MongoDB World returns this June to NYC and in honor of May the Fourth we are offering tickets at only $400 May4-6. Register now and join us for announcement packed keynotes, hands on workshops, and more June 7-9.


Viewing all articles
Browse latest Browse all 2423

Trending Articles