Document Databases
A document DB is a type of NoSQL DB and is very much an extension of a key–value DB. A document database has all the points of key–value DBs except that a document DB stores a document, which is a collection of fields. Fields can store a simple value or complex elements, such as lists or parent child hierarchy. Document DBs come in a variety of forms, such as JSON, BSON, XML, YML, and .txt.
A second difference is that the fields in the document enable an application to query and filter data by the values in those fields. A document DB does not require that all documents have the same structure. The structure of encoded data is semi-structured and can allow for complicated queries. This freeform approach provides a great deal of flexibility. Applications can store different data in documents as business requirements change. The data in a document can be stored in multiple forms, such as lists, collections, and so forth, and are retrieved by unique keys, such as a customer number or an order number.
Documents do not need to have the same structure as the way they are stored in RDBMS. Data applications can handle multiple structures of data in document DBs as business requirements change. There are multiple factors that are critical to decide when opting for a document database. Document DB can be easily partitioned and is distributable across multiple nodes, so it is highly scalable and high-performing. Because of the lack of rigid format structure, these DBs can store semi-structured and unstructured data and handle the changing schema from a data-modeling perspective.
Such databases can be helpful in scenarios where users need to work with binary data and perform low-level operations, like putting encryption algorithms on these binary bits within data. Document DBs have myriad business use cases for personalization engines, content management, games, IOT applications, and more. One of example of a document database is MongoDB.
MongoDB stores data as JSON/BSON documents to provide more flexibility for scaling and querying data as an application evolves. Mongo means “humungous,” which means it is built for large volumes of data. MongoDB provides flexibility in terms of being schemaless when updating linked applications. This means we can start creating documents without needing to first establish a fixed structure. It provides features like GridFS, sharding, indexing, JavaScript interface to MongoDB, and rich query language. There are features for search flexibility, like graph search, geo-search, map-reduce queries, and text search.
However, before simply choosing MongoDB, we need to look at both its strengths and its weaknesses before deciding which platform to use or which approach to use; e.g., while setting up concurrent locations, updating a consistent field in several locations can cause lags in performance compared to a relational database as there will be a delay in data write operations. Also, like in other NoSQL languages, there can be a steeper learning curve for developers who are familiar with other databases because queries are written with a JSON syntax, instead of SQL.
