{"id":41493,"date":"2015-07-06T10:00:19","date_gmt":"2015-07-06T07:00:19","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=41493"},"modified":"2023-12-05T16:37:08","modified_gmt":"2023-12-05T14:37:08","slug":"mysql-vs-mongodb","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html","title":{"rendered":"MySQL vs. MongoDB: Choosing a Data Management Solution"},"content":{"rendered":"
\n

Table Of Contents<\/h3>\n
\n
1. Introduction<\/a><\/dt>\n
2. The dominance of RDBM systems<\/a><\/dt>\n
3. A new era of NoSQL movement<\/a><\/dt>\n
4. Tables vs Documents vs Graphs vs Key\/Values<\/a><\/dt>\n
5. MySQL and MongoDB: Conscious Decision<\/a><\/dt>\n
\n
\n
5.1. Enforced Schema vs Schemaless<\/a><\/dt>\n
5.2. Normalization vs Duplication<\/a><\/dt>\n
5.3. Relations vs References<\/a><\/dt>\n
5.4. Transactions vs Atomic Updates<\/a><\/dt>\n
5.5. SQL vs JSON<\/a><\/dt>\n
5.6. Stored Procedures vs Scripting<\/a><\/dt>\n
5.7. GROUP BY vs Aggregations<\/a><\/dt>\n
5.8. Clustering and Sharding\/Partitioning<\/a><\/dt>\n
5.9. Full text search<\/a><\/dt>\n
5.10. Development<\/a><\/dt>\n
5.11. Monitoring & Diagnostics<\/a><\/dt>\n
5.12. Security<\/a><\/dt>\n
5.13. Trade-offs, not battles<\/a><\/dt>\n
5.15. MySQL or MongoDB?<\/a><\/dt>\n
5.16. MySQL and MongoDB: Nowadays<\/a><\/dt>\n<\/dl>\n<\/dd>\n
6. Conclusions<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Introduction<\/h2>\n

It would be fair to say that as IT professionals we are living in the golden age of data management era. As our software systems become more complex and more distributed, driven by myriads of scalability and availability requirements, the traditional solutions used for years began to fall behind.<\/p>\n

The goal of this tutorial is to provide a fair overview of the two data management solutions: mature and widely used relation database represented by MySQL<\/a> and a new kid on the block, MongoDB<\/a>, which in turn represents a new generation of data store. By no means is it a battle with a clear winner at the end. Instead, the intention is to help developers to make a choice and find a right fit for their applications by going through the features of MySQL<\/a> and MongoDB<\/a>, discussing the different guarantees and limitations each one has.<\/p>\n

<\/a>2. The dominance of RDBM systems<\/h2>\n

The history and evolution of data management software is not a particularly exciting topic to spend time on. For a quite some time relational database management systems took a leadership and for years the choice was obvious, either MySQL<\/a>, PostreSQL<\/a> or Oracle<\/a>, just to name a few. SQL<\/a> (and its vendor-specific dialects) was the de-facto standard for querying relational data stores and by definition every backend software developer had to learn and understand a least some basics of it. It worked surprisingly well until recently, when a whole family of new data management systems has emerged, the phenomenon also known as NoSQL<\/strong> (or Not Only SQL<\/strong>) movement.<\/p>\n

<\/a>3. A new era of NoSQL movement<\/h2>\n

The challenges which modern software systems are facing nowadays with respect to data volumes and requests\/transactions throughput requirements revealed that relational data stores often become a bottleneck, thus imposing the limits on overall system scalability. Traditionally, the way to solve this problem was just buying a bigger box (so called vertical scalability<\/a>), however at some point the price to pay becomes very, very high, making the whole system ridiculously expensive and impractical.<\/p>\n

The industry was actively looking into a cheaper ways to build complex distributed systems, making use of horizontal scalability<\/a> instead. It also meant to come up with alternatives to relation data stores, which could scale horizontally as well. That the moment, when NoSQL movement<\/a> has begun.<\/p>\n

<\/a>4. Tables vs Documents vs Graphs vs Key\/Values<\/h2>\n

A Relational data model<\/a> represents all data in terms of tuples and relations (better known as tables). The structured data fits this model very well and for a long time no other viable alternative existed. With the NoSQL movement<\/a>, many alternative data models were developed, giving a birth to a whole bunch of specialized data storage systems.<\/p>\n

The NoSQL<\/a> solutions could be classified in a few different categories. Document data stores<\/a> are designed for storing, querying and managing documents (semi-structured data). The more mature representatives of this category include CouchDB<\/a>, Couchbase<\/a>, MongoDB<\/a>, OrientDB<\/a> and HyperDex<\/a>. Key\/Value data stores<\/a> are designed for storing, querying and managing associative arrays (also known as dictionaries or hashes).<\/p>\n

The most widely used representatives of this category include DynamoDB<\/a>, FoundationDB<\/a>, HyperDex<\/a>, MemcacheDB<\/a>, Redis<\/a>, Riak<\/a>, Aerospike<\/a> and OrientDB<\/a>. Graph data stores<\/a> are designed for efficiently storing and operating graph structures. The well-known representatives of this category include Neo4J<\/a>, InfiniteGraph<\/a>, GraphBase<\/a> and OrientDB<\/a>. Last but not least, wide-column data stores<\/a> are taking a hybrid approach (combining some characteristics of key\/value data stores<\/a> and traditional relational data stores<\/a>). The most advanced representatives of this category include Accumulo<\/a>, Cassandra<\/a> and HBase<\/a>.<\/p>\n

Please notice that the list of different NoSQL<\/a> data stores presented above is far from being complete, it just contains the most well-known and widely used names, but there are a lot more out there.<\/p>\n

<\/a>5. MySQL and MongoDB: Conscious Decision<\/h2>\n

Enough with the introduction, so let us move on to more practical things. In this part of the tutorial we are going to take a look on all aspects of application development process using MySQL<\/a> and MongoDB<\/a>, also spending some time talking about deployment and monitoring. The goal is to discuss the trade-offs and design decisions that each of those data stores make and analyze how they are changing the way we develop applications. Also, another purpose this tutorial serves is to assist in making a decision when MongoDB<\/a> may be a better choice than MySQL<\/a> (and vice versa), taking into account application architecture, data access patterns and storage requirements.<\/p>\n

As we already now, MongoDB<\/a> is a document data store. It stores JSON-style documents which are grouped into collections. At the top of MongoDB<\/a> data model hierarchy is a database (please refer to official documentation<\/a> in order to get the comprehensive details). The current production ready version of MongoDB<\/a> is 3.0.4<\/strong>.<\/p>\n

From other side, MySQL<\/a> is relational data store. The data is stored in tables which contains columns. The tables are grouped into database (please refer to official documentation<\/a> in order to get the comprehensive details). The current production ready version of MySQL<\/a> is 5.6.25<\/strong>.<\/p>\n

MySQL<\/a> supports multiple storage engines<\/a>, each of them serves own purpose and has some features not available in other storage engines. Along this tutorial we assume that InnoDB<\/a> storage engine is used as it is the default and most general-purpose one which is recommended for use except for specialized use cases.<\/p>\n

<\/a>5.1. Enforced Schema vs Schemaless<\/h3>\n

MySQL<\/a> as a relation data store requires a strict schema for its data model: all tables should be created with columns defined. Only then the data could be stored and queried using the SQL<\/a> language. It somewhat complicates the development and deployment process as every time the modification of data model is required, the schema should be changed first and then data migrated. Here is an example of typical steps required to create new database, new table and insert one row into it using MySQL<\/a> shell and SQL<\/a> language:<\/p>\n

CREATE DATABASE tutorial;\nUSE tutorial;\nCREATE TABLE chapters (\n    id INT PRIMARY KEY AUTO_INCREMENT, \n    title VARCHAR(255) NOT NULL\n);\nINSERT INTO chapters (title) VALUES (\"MySQL and MongoDB: trade-offs, not battles\");\n<\/pre>\n
In contrast, MongoDB<\/a> does not impose any schema on the documents being stored in the collection. It becomes the responsibility of application to deal with that, the only thing MongoDB<\/a> restricts is the supported data types<\/a>. It significantly speeds up the development process as MongoDB<\/a> could be used right away to store JSON documents of any shape.<\/p>\n
The structure of the documents could evolve and change over time, and different generations of the documents may coexist in the same collection. It is up to application developer to decide how to perform data cleanup or migration if necessary. Let us take a look on how the same steps of creating new database, new collection and inserting one document into it could be done using MongoDB<\/a> shell:<\/p>\n
use tutorial\n\ndb.chapters.insert({ \n    \"title\": \"MySQL and MongoDB: trade-offs, not battles\" \n})\n<\/pre>\n
It is worth to mention that upcoming 5.7<\/strong> version of MySQL<\/a> (which is currently in release candidate phase) introduces the native JSON support. With the introduction of this new JSON data type it would be possible to combine enforced schema and schemaless data in MySQL<\/a>.<\/p>\n
<\/a>5.2. Normalization vs Duplication<\/h3>\n
Normalization<\/a> in the world of relational databases is the process of organizing tables to minimize data redundancy. It involves decomposing a table into less redundant (and smaller) tables without losing data. It also assumes defining foreign keys in the old tables referencing the primary keys of the new ones. For example, this is the way to create two tables in MySQL<\/a>, where the books<\/strong> table references the authors<\/strong> table:<\/p>\n
CREATE TABLE authors (\n    id INT PRIMARY KEY AUTO_INCREMENT, \n    name VARCHAR(255) NOT NULL\n);\nCREATE TABLE books (\n    id INT PRIMARY KEY AUTO_INCREMENT, \n    title VARCHAR(255) NOT NULL, \n    author_id INT NOT NULL, \n    FOREIGN KEY (author_id) REFERENCES authors(id)\n);\nINSERT INTO authors (name) VALUES (\"Michael Kofler\");\nINSERT INTO books (title, author_id) VALUES (\"The Definitive Guide to MySQL 5\", 1);\n<\/pre>\n
The normalization is obsolete for MongoDB<\/a>. Instead, careful data modeling and certain level of data duplication is the way to get most out of document data store. It also becomes the responsibility of the application to decide the level of data repetition and to keep all data fragments in sync in case of modifications. For example:<\/p>\n
db.books.insert( { \n    \"title\": \"The Definitive Guide to MySQL 5\", \n    \"author\": { \n        \"name\": \"Michael Kofler\" \n    }\n})\n<\/pre>\n
<\/a>5.3. Relations vs References<\/h3>\n
In the normalized database, a JOIN<\/strong> clause from the SQL<\/a> is usually used to combine records from two or more MySQL<\/a> tables (there are other techniques as well but by and large they essentially lead to the same results). For example:
 
<\/div> <\/div><\/p>\n
SELECT * FROM books b INNER JOIN authors a ON a.id = b.author_id;<\/pre>\n
MongoDB<\/a> supports document references but does not support joins: to resolve the reference, the additional query (or queries) should be executed (leading to infamous in relational world N+1 query problem). For example, in the snippet below we are inserting the reference to authors<\/strong> collection from the books<\/strong> collection instead of embedding author details:<\/p>\n
db.authors.insert({ \n    \"name\": \"Michael Kofler\", \n    \"_id\": 1  \n})\ndb.books.insert({ \n    \"title\": \"The Definitive Guide to MySQL 5\", \n    \"author\": { \n        \"$ref\": \"authors\", \n        \"$id\": 1 \n    }\n})\n<\/pre>\n
The necessary round-trips are the price to pay for the flexibility of going schemaless. However, as we already mentioned in section Normalization vs Duplication<\/a>, certain level of data duplication and careful analysis of data access patterns may mitigate the problem.<\/p>\n
<\/a>5.4. Transactions vs Atomic Updates<\/h3>\n
A transaction is a logical unit of work performed by data management system against its data. The importance of transaction is encapsulated into its foundational properties: transaction must be atomic<\/strong>, consistent<\/strong>, isolated<\/strong> and durable <\/strong>(also known as ACID<\/a> model). MySQL<\/a> is a fully transactional relation data store which makes it a perfect choice for the mission-critical applications that are not able to tolerate data lost or inconsistency. However, transactions are not free: they significantly limit the horizontal scalability of the data stores, and MySQL<\/a> is not an exception.<\/p>\n
MongoDB<\/a> does not support transactional guarantees. Instead, it supports atomic updates on the single document level. It means when a single update operation modifies multiple documents, the modification of each document is atomic, but the operation as a whole is not atomic and other operations may interleave. It worth mentioning that it is possible to implement transaction-like<\/strong> semantic on top of MongoDB<\/a> (using the two-phase commits<\/a> technique) but it requires quite complex implementations.<\/p>\n
<\/a>5.5. SQL vs JSON<\/h3>\n
SQL<\/a> is a special-purpose programming language designed for managing data held in a relational database management system. It is the only query language supported by MySQL<\/a>, enriched with a few vendor-specific extensions<\/a>. Despite its simplicity, SQL<\/a> is a very powerful language which essentially consists of two parts: a data definition language<\/a> (DDL) and a data manipulation language<\/a> (DML). We have seen quite a few examples already, but let us take a look on the simplest and probably most useful example of selecting rows from the table:<\/p>\n
SELECT * FROM books;\nSELECT * FROM books WHERE title LIKE \"%MySQL%\";<\/pre>\n
In MongoDB<\/a>, everything is a document, represented as JSON. MongoDB<\/a> does not have a dedicated language to manage the documents and takes very different approach instead. Document manipulation or querying is described using very rich set of operators<\/a>, composed with each other using JSON structure, as any other document. This unified representation is quite powerful, expressive and easy to understand, plus it does not require to learn yet another programming language. Most of the operators are self-explanatory and intuitive, for example:<\/p>\n
db.books.find();\ndb.books.find({\n    \"title\": { \n        \"$regex\": \"MySQL\" \n    }\n});\n<\/pre>\n
<\/a>5.6. Stored Procedures vs Scripting<\/h3>\n
A stored procedure is a special kind of routine available on the server side of relational data store. Stored procedures could be implemented in different programming languages however most of the time they are written using SQL<\/a> or its vendor-specific dialect, which is the case with MySQL<\/a>. Typically, stored procedures help increase the performance of the applications by executing some logic directly on the server, requiring less information to be sent between the server and the client. For example, here is a very simple MySQL<\/a> stored procedure:<\/p>\n
DELIMITER \/\/\nCREATE PROCEDURE find_books\n(IN pattern CHAR(255))\nBEGIN\n    SELECT COUNT(*) FROM books WHERE title LIKE pattern;\nEND \/\/\nDELIMITER ;\n\nCALL find_books(\"%MySQL%\");\n<\/pre>\n
MongoDB<\/a> supports server-side scripting in the form of executing JavaScript code on the server. Those server-side scripts may resemble stored procedures but the implementation goes beyond just simple scripting as it supports map\/reduce<\/a> paradigm, firstly populated by Google, and widely adopted for big data analytics. Essentially, by supplying the script to map\/reduce<\/a> command, it becomes possible parallelize the processing of a large and very large datasets across many MongoDB<\/a> data store instances. Let us take a look on very na\u00efve map\/reduce<\/a> script example which counts how many books have \u201cMySQL\u201d string in their title:<\/p>\n
db.runCommand( {\n    mapReduce: \"books\",\n    map: function() {\n        if (this.title.indexOf(\"MySQL\") >= 0) { \n            emit(\"MySQL\", 1);        \n        }\n    },\n    reduce: function(key, counters) {\n        count = 0;\n\n        for (var index = 0; index < counters.length; ++index) { \n            count += counters[index];                    \n        }\n\n        return count;\n    },\n    out: { inline: 1 }\n} )\n<\/pre>\n
Compared to the MySQL<\/a> stored procedure example, the MongoDB<\/a> one looks overly verbose and complicated. However once the concepts of the map\/reduce<\/a> paradigm become more clear, the example is going to look quite simple, opening a whole new frontier of applying many data processing, exploration and analysis techniques.<\/p>\n
<\/a>5.7. GROUP BY vs Aggregations<\/h3>\n
In data management domain, an aggregate function<\/a> is a function where the values of multiple data records are grouped together depending on certain aggregation criteria, as such producing a single value of more significant meaning or measurement. The SQL<\/a> language defines a set of specific clauses for performing aggregations: GROUP BY<\/strong> and HAVING<\/strong>. The set of standard grouping functions among many others include AVG()<\/strong>, COUNT()<\/strong>, MAX()<\/strong>, MIN()<\/strong>, STD()<\/strong>, SUM()<\/strong>. Let us take a look on GROUP BY<\/strong> example in MySQL<\/a> shell:<\/p>\n
CREATE TABLE orders (\n    id INT PRIMARY KEY AUTO_INCREMENT, \n    publisher VARCHAR(255) NOT NULL,\n    product VARCHAR(255) NOT NULL,\n    price NUMERIC (15,2) NOT NULL\n);\nINSERT INTO orders (product, publisher, price) VALUES \n    (\"The Definitive Guide to MySQL 5\", \"APress\", 37.36),\n    (\"MySQL Cookbook\", \"O\u2019Reilly\", 49.65),\n    (\"Learning MySQL\", \"O\u2019Reilly\", 29.48);\nSELECT publisher, SUM(price) FROM orders GROUP BY publisher;\n<\/pre>\n
MongoDB<\/a> offers a specialized set of aggregations operations which process documents and return computed (or aggregated) results. Aggregation operations group values from multiple documents together, and can perform a variety of operations on the grouped data to return a single result. Aggregations in MongoDB<\/a> could be done in two ways: using aggregation pipeline<\/a> or single purpose aggregation methods and commands<\/a>.<\/p>\n
Let us take a look on the same example we have prepared to demonstrate MySQL<\/a> aggregations, this time using MongoDB<\/a>\u2019s aggregation pipeline<\/a>:<\/p>\n
db.books.insert( { \n    \"title\": \"The Definitive Guide to MySQL 5\", \n    \"publisher\": \"APress\",\n    \"price\": 37.36\n})\ndb.books.insert( { \n    \"title\": \"MySQL Cookbook\", \n    \"publisher\": \"O\u2019Reilly\",\n    \"price\": 49.65\n})\ndb.books.insert( { \n    \"title\": \"Learning MySQL\", \n    \"publisher\": \"O\u2019Reilly\",\n    \"price\": 29.48\n})\ndb.books.aggregate([\n    { $match: {} }, \n    { $group: {\n        \"_id\": \"$publisher\", \n        \"price\": { \n            \"$sum\": \"$price\"\n        }\n    }}\n]);\n<\/pre>\n
The map\/reduce<\/a> command which we discussed in Stored Procedures vs Scripting<\/a> section could also be considered as a way to do aggregations.<\/p>\n
<\/a>5.8. Clustering and Sharding\/Partitioning<\/h3>\n
Nowadays, the data volumes are growing exponentially and the single physical instance of data store often is not able to persist and manage such a mass of data at acceptable pace. Clustering is technology that allows to bring many individual computing instances to work together. With respect to data storages, clustering goes side by side with data sharding\/partitioning, which is a technique to split large amount of data across multiple data store instances.<\/p>\n
For quite a while, MySQL<\/a> has been available in the MySQL Cluster<\/a> edition which claims to be a write-scalable, real-time, ACID<\/a>-compliant transactional data store. MySQL Cluster<\/a> is built on top of distributed, multi-master architecture, which supports auto-sharding\/partitioning and scales horizontally to serve read and write intensive workloads.<\/p>\n
Historically, MySQL Cluster<\/a> has a reputation of being too complex, quite hard to configure, monitor and maintain. In contrast to standalone MySQL<\/a> deployments, the data schema should be designed in such a way so to take data sharding \/ partitioning into account, otherwise the performance of the data store will suffer a lot. Lastly, MySQL Cluster<\/a> has many limitations comparing to the regular MySQL<\/a> distribution.<\/p>\n
MongoDB<\/a> document data store supports sharding\/partitioning out of the box using concept of sharded clusters<\/a>. The strong side of MongoDB<\/a> sharding\/partitioning is that it has simple and easy configuration. It scales horizontally pretty well but there are quite a few limitations<\/a> to be aware of.<\/p>\n
5.8.1. Replication<\/h4>\n
Replication is an essential technique to keep data safe (by replicating it across many data store instances) and in many cases to improve scalability and fault-tolerance of the applications dealing with this data. MySQL<\/a> supports traditional master\/slave replication<\/a>, which by default is asynchronous but semi-synchronous and delayed replication modes are also possible.<\/p>\n
MongoDB<\/a> approaches replication by introducing replica sets. Basically, it is master\/slave replication but MongoDB<\/a> uses a little bit different terminology. The master, called the primary<\/strong>, receives all write operations and slaves, called secondaries<\/strong>, apply operations from the primary. The one of the greatest features supported by replica sets is automatic failover<\/a>: when a primary does not communicate with the other members of the replica set, the replica set will attempt to select another member to become the new primary.<\/p>\n
To be fair, it is possible to configure MySQL<\/a> master\/slave replication with automatic failover<\/a> as well but there are some concerns and discussions about this feature in MySQL<\/a> community.<\/p>\n
<\/a>5.9. Full text search<\/h3>\n
Since a long time MySQL<\/a> has support for full-text indexing and searching that is implemented using special type of the index. It is important to mention that full-text indexing support became available on the InnoDB<\/a> storage engine only since MySQL<\/a> 5.6<\/strong> release branch.<\/p>\n
Interestingly, full-text search in MySQL<\/a> is possible using natural language search (phrase search), boolean search (terms search) where the words to search for might be marked as \u201cmust be present\u201d or \u201cmust be absent\u201d, and query expansion search (a slight modification of a natural language search). However, at the moment full-text indexing is not supported in clustered MySQL<\/a> deployments (see please Clustering and Sharding\/Partitioning<\/a> section for a brief discussion about MySQL Cluster<\/a>). Let us take a look on quick example:<\/p>\n
CREATE TABLE products (\n    id INT PRIMARY KEY AUTO_INCREMENT, \n    product VARCHAR(255) NOT NULL,\n    description VARCHAR(255) NOT NULL,\n\n    FULLTEXT product_description (product, description)\n);\nINSERT INTO products (product, description) VALUES \n    (\"The Definitive Guide to MySQL 5\", \"This book shows readers how to connect to MySQL via all of the major APIs, including PHP, Perl, Java, JSP, and C#\"),\n    (\"MySQL Cookbook\", \"Ideal for beginners and professional database and web developers\"),\n    (\"Learning MySQL\", \"Book travels far into MySQL's subtleties, including complex queries and joins\");\nSELECT * FROM products \n    WHERE MATCH (product, description)\n    AGAINST ('database guide' IN NATURAL LANGUAGE MODE);\n<\/pre>\n
Full-text search support was introduced in MongoDB<\/a> not so long ago. Similarly to MySQL<\/a>, it is implemented using special type of the index on the string content (or array of strings). MongoDB<\/a> also supports phrase search, terms search and boolean search as a combinations of those. It is easy to use and elegantly implemented feature but not without limitations. Unfortunately, at the moment MongoDB<\/a> gives no control to specify the subset of fields to perform full-text search against: it is always matches all the fields included in the full-text index. Let us take a look on MongoDB<\/a> full-text search in action:<\/p>\n
db.products.insert({\n    \"product\": \"The Definitive Guide to MySQL 5\",\n    \"description\": \"This book shows readers how to connect to MySQL via all of the major APIs, including PHP, Perl, Java, JSP, and C#\"\n})\ndb.products.insert({\n    \"product\": \"MySQL Cookbook\",\n    \"description\": \"Ideal for beginners and professional database and web developers\"\n})\ndb.products.insert({\n    \"product\": \"Learning MySQL\",\n    \"description\": \"Book travels far into MySQL's subtleties, including complex queries and joins\"\n})\ndb.products.createIndex({\n    product: \"text\",\n    description: \"text\"\n})\ndb.products.find({\n    $text: { \n        $search: \"database guide\" \n    } \n})\n<\/pre>\n
<\/a>5.10. Development<\/h3>\n
When it comes to development, MySQL<\/a> provides a wide set of connectors<\/a> which could be used to communicate with the server from most of the mainstream programming languages of your choice. With respect to Java development, MySQL<\/a> includes a JDBC driver which conforms to the JDBC 3.0 and JDBC 4.0 specifications.<\/p>\n
Although it is quite rare to encounter the code which uses straight JDBC interfaces to communicate with relation data store (many frameworks have been built to facilitate that), it is good to know what is involved. Let us take a look on following code snippet which connects to MySQL<\/a> and executes a single SELECT<\/strong> statement:<\/p>\n
try {\n    connection = DriverManager.getConnection(\"jdbc:mysql:\/\/localhost\/tutorial\");\n\n    Statement statement = null;\n    ResultSet resultSet = null;\n\n    try {\n        statement = connection.createStatement();\n        resultSet = statement.executeQuery(\"SELECT * FROM books\");\n\t\t\t\t\n        while (resultSet.next()) { \n            \/\/ Now do something with the ResultSet .... \n        }\n    } catch (SQLException ex) {\n        \/\/ Log exception\n    } finally {\n        if (resultSet != null) {\n\t    try { resultSet.close(); } catch ( SQLException ex) { \/* ignore *\/ }\n        }\n\n        if (statement != null) {\n\t    try { statement.close(); } catch ( SQLException ex) { \/* ignore *\/ }\n        }\n    }\n} catch (SQLException ex) {\n    \/\/ Log exception\n} finally {\n    if (connection != null ) {\n        try { connection.close(); } catch( SQLException ex ) { \/* ignore *\/ }\n    }\n}\n<\/pre>\n
It looks quite verbose and full of exception handling. MongoDB<\/a> in turn has a rich ecosystem of drivers<\/a>, which aside from mainstream languages includes drivers for Erlang<\/a>, Go<\/a>, Node.js<\/a> and Scala<\/a>. Having a freedom to come up with own specifications, MongoDB<\/a> is in the process of development of the next generation drivers<\/a> and quickly adapting the existing implementations to the latest trends in the industry (the good example of that is ReactiveMongo: Reactive Scala Driver for MongoDB<\/a>).<\/p>\n
As an example, let us take a look on one of the way to connect to MongoDB<\/a> using Java and Morphia<\/a> driver (assuming we have Book and Author data model classes):<\/p>\n
final MongoClient client = new MongoClient( \"localhost\", 27017 );\nfinal Datastore dataStore = morphia\n    .map( Book.class, Author.class )\n    .createDatastore( client, \"tutorial\" );\n\nfinal Query< Book > query = dataStore.createQuery( Book.class ).\nfinal List< Book > books =  query.asList();        \n<\/pre>\n
Historically, JSON support in Java was quite good because of rich set of the community supported libraries, thus making conversions of JSON documents to Java classes (and back) no brainer.<\/p>\n
It would be unfair not to mention that Java community has developed quite a lot of different object-relational mapping<\/a> frameworks (ORM<\/a>s) to abstract from low-level JDBC interfaces, which essentially allow to write the code as concise as MongoDB<\/a>\u2019s example. However, it is important to understand that they add quite a lot of complexity into existing applications.<\/p>\n
5.10.1. Deployment<\/h4>\n
Both MySQL<\/a> and MongoDB<\/a> are available on most of the major operating systems. In most cases MySQL<\/a> is being installed from platform-specific packages and requires privileged access to the system. Although the downloadable archives are also available, depending on the operating system, configuration and edition (for example, MySQL Cluster<\/a>), the installation may get quite complex and non-intuitive (however may not require privileged access to the system).<\/p>\n
Contrary, MongoDB<\/a> in most cases is distributed as downloadable archive which could be unpacked and used right away. The sensible defaults play the great role here by requiring minimum configuration, just run the MongoDB<\/a> server and start filling data store with documents.<\/p>\n
It will be fair to mention that with containerization and Docker<\/a>, the landscape of deployment procedures (we so get used to) is changing very rapidly. Moving from traditional package-based distributions to preconfigured containers flatten the installable packages and download-unpack-run models: everything becomes an image, run as isolated container, available in milliseconds.<\/p>\n
Not to mention that many cloud providers (AWS<\/a>, Cloud Foundry<\/a>, Open Shift<\/a>, just to name a few) have software-as-a-service offerings for MySQL<\/a> and\/or MongoDB<\/a>, taking care of all configuration, infrastructure and scalability details.<\/p>\n
<\/a>5.11. Monitoring & Diagnostics<\/h3>\n
Clearly, monitoring is a critical component of any data store administration procedure. There is quite a number of commercial solutions for monitoring data store of your choice but let us discuss the ones available as part of the MySQL<\/a> and MongoDB<\/a> distributions.<\/p>\n
MySQL<\/a> has a several ways to perform monitoring and diagnostics. First of all, it is SHOW ENGINE <ENGINE> STATUS<\/a> command. Secondly, MySQL<\/a> supports performance schema<\/a> which is a feature for monitoring MySQL<\/a> server execution at a low level. And lastly, MySQL<\/a> supports DTrace probes<\/a> (not supported by every operating system) which are designed to provide information about the execution of queries within MySQL<\/a> server and the different areas of the system being utilized during that process.<\/p>\n
MongoDB<\/a> distribution includes a number of command line utilities that allow to quickly retrieve statistics about the performance and activity of each data store instance. Not only that, every running MongoDB<\/a> instance also provides a web interface that exposes diagnostic and monitoring information through a simple web page. And lastly, MongoDB<\/a> includes a number of commands to get the insights about the state of the database by connecting to it through the shell.<\/p>\n
<\/a>5.12. Security<\/h3>\n
MySQL<\/a> uses privilege-based security model. The primary function of the MySQL<\/a>\u2019s privilege system<\/a> is to authenticate a user and to associate that user with privileges on a particular database (such as CREATE<\/strong>, DROP<\/strong>, SELECT<\/strong>, INSERT<\/strong>, UPDATE<\/strong>, DELETE <\/strong>and others<\/a>).<\/p>\n
As of now, there are few things that are not supported by MySQL privilege system<\/a>: inability to explicitly specify that a given user should be denied access and inability to specify that a user has privileges to create or drop tables in a database but not to create or drop the database itself. On the transport layer, MySQL<\/a> supports secure (encrypted) connections between clients and the server using the SSL (Secure Sockets Layer) using the TLS v1.0 protocol.<\/p>\n
MongoDB<\/a> security features include authentication, authorization and auditing. Its foundation is a role-based access control with flexible set of privileges. It worth to mention that MongoDB<\/a> provides a basis for user-defined roles by defining a set of build-in roles. It is also possible to use TLS\/SSL (Transport Layer Security\/Secure Sockets Layer) to encrypt all of MongoDB<\/a>\u2019s network traffic to ensure that it is only readable by the intended client.<\/p>\n
<\/a>5.13. Trade-offs, not battles<\/h3>\n
As we have seen, MySQL<\/a> and MongoDB<\/a> both serve same common goal: be a comprehensive data management solution for its users. However, the ways each of them approaches this goal are very, very different. From one side, we see quite mature and battle-tested relational data store. From other side, we met young but quickly maturing document data store, so suitable for certain classes of modern web applications.<\/p>\n
As was stated several times along this tutorial, it is not a battle and we are not looking for a winner. Rather, we are looking for solution which better fits to the needs of your applications. Even more, heterogeneous data storage infrastructure becomes rather a norm than an exception nowadays: for example, MongoDB<\/a> may perfectly fit into analytics and reporting demands, whereas MySQL<\/a> may store billing transactions. Luckily, with the help of this tutorial you will be able to pick the right tool to do the job.<\/p>\n
In many respects it would be fair to say that MongoDB<\/a> was built for web: embracing JSON, very short learning curve, foundation of rapid development, new features added every release. MySQL<\/a> is battle-tested, conservative and old fashion, however things are changing very fast as relation data stores try to adapt themselves to meet modern application needs.<\/p>\n
<\/a>5.15. MySQL or MongoDB?<\/h3>\n
A lot have been already said about MySQL<\/a> and MongoDB<\/a>. It would be good to finish the discussion with the set of recommendations when MongoDB<\/a> is preferred than MySQL<\/a> and vice-versa.<\/p>\n
First of all, if your data is critical to your business, very likely MySQL<\/a> is a safer choice: ACID<\/a> properties are there for a reason. But every application is different. Content management systems, logs management, analytics, forums and blogs, events stores, product catalogs, inventory management, those kinds of applications may benefit from MongoDB<\/a> as a data store.<\/p>\n
Schemaless data model is an enabler for rapid development: just introduce new properties as you go without a need to perform schema evolutions and data migration. Arguably, but MongoDB<\/a>\u2019s style of manipulating documents and running queries is much more developer-friendly (moreover, it does not require any language to learn, like SQL<\/a>). Configuring MongoDB<\/a>\u2018s replica sets and sharded clusters is really easy and fast, comparing to MySQL Cluster<\/a> configuration (and management).<\/p>\n
Modern architectural patterns are promoting to split application\u2019s read and write paths (for example, Command and Query Responsibility Segregation<\/a> or just CQRS<\/a>). With that, applications could be designed in a way where write path is served by MySQL<\/a> but MongoDB<\/a> could be a data storage for read path, where data pieces are composed into meaningful documents.<\/p>\n
<\/a>5.16. MySQL and MongoDB: Nowadays<\/h3>\n
It is worth mentioning that two companies, Twitter<\/a> and Facebook<\/a>, successfully operate some of the largest MySQL<\/a> deployments out there. They happily share their experience though the numerous blog posts: MySQL at Twitter<\/a>, Another look at MySQL at Twitter and incubating Mysos<\/a>, How Twitter Stores 250 Million Tweets a Day Using MySQL<\/a>, WebScaleSQL: A collaboration to build upon the MySQL upstream<\/a>, and more.<\/p>\n
From other side, adoption of MongoDB<\/a> is growing every day with more and more companies<\/a> deploying it at a larger and larger scale. For example, eBay<\/a> shared How We Built eBay\u2019s First Node.js Application<\/a>, while Craigslist<\/a> followed up with MongoDB at Craigslist: 1 Year Later<\/a>. No doubts, we are going to see more wide adoption in the future.<\/p>\n
<\/a>6. Conclusions<\/h2>\n
In this short tutorial we tried to take a look on two very popular data stores, traditional relation database represented by MySQL<\/a> and document data store represented by MongoDB<\/a>. We briefly walked through most important features and data guarantees each of those has, trying to assess how applications scalability and availability might be affected. We have omitted a lot of low-level intrinsic details as both MySQL<\/a> and MongoDB<\/a> worth several books alone. Instead, we did a high-level overview, picking the most interesting and important areas.<\/p>\n","protected":false},"excerpt":{"rendered":"
Table Of Contents 1. Introduction 2. The dominance of RDBM systems 3. A new era of NoSQL movement 4. Tables vs Documents vs Graphs vs Key\/Values 5. MySQL and MongoDB: Conscious Decision 5.1. Enforced Schema vs Schemaless 5.2. Normalization vs Duplication 5.3. Relations vs References 5.4. Transactions vs Atomic Updates 5.5. SQL vs JSON 5.6. …<\/p>\n","protected":false},"author":141,"featured_media":2386,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[662,112,43,113,244],"class_list":["post-41493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-development","tag-databases","tag-mongodb","tag-mysql","tag-nosql","tag-sql"],"yoast_head":"\nMySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks<\/title>\n<meta name=\"description\" content=\"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\/Values5. MySQL and\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks\" \/>\n<meta property=\"og:description\" content=\"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\/Values5. MySQL and\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html\" \/>\n<meta property=\"og:site_name\" content=\"Java Code Geeks\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/javacodegeeks\" \/>\n<meta property=\"article:published_time\" content=\"2015-07-06T07:00:19+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-05T14:37:08+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"150\" \/>\n\t<meta property=\"og:image:height\" content=\"150\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Andrey Redko\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@javacodegeeks\" \/>\n<meta name=\"twitter:site\" content=\"@javacodegeeks\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Andrey Redko\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html\"},\"author\":{\"name\":\"Andrey Redko\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#\\\/schema\\\/person\\\/771a6504862edc45322776832cbce413\"},\"headline\":\"MySQL vs. MongoDB: Choosing a Data Management Solution\",\"datePublished\":\"2015-07-06T07:00:19+00:00\",\"dateModified\":\"2023-12-05T14:37:08+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html\"},\"wordCount\":4407,\"commentCount\":11,\"publisher\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2012\\\/10\\\/software-development-2-logo.jpg\",\"keywords\":[\"Databases\",\"MongoDB\",\"MySQL\",\"NoSQL\",\"SQL\"],\"articleSection\":[\"Software Development\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html\",\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html\",\"name\":\"MySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2012\\\/10\\\/software-development-2-logo.jpg\",\"datePublished\":\"2015-07-06T07:00:19+00:00\",\"dateModified\":\"2023-12-05T14:37:08+00:00\",\"description\":\"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\\\/Values5. MySQL and\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#primaryimage\",\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2012\\\/10\\\/software-development-2-logo.jpg\",\"contentUrl\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2012\\\/10\\\/software-development-2-logo.jpg\",\"width\":150,\"height\":150},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/2015\\\/07\\\/mysql-vs-mongodb.html#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.javacodegeeks.com\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Software Development\",\"item\":\"https:\\\/\\\/www.javacodegeeks.com\\\/category\\\/software-development\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"MySQL vs. MongoDB: Choosing a Data Management Solution\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#website\",\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/\",\"name\":\"Java Code Geeks\",\"description\":\"Java Developers Resource Center\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#organization\"},\"alternateName\":\"JCG\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.javacodegeeks.com\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#organization\",\"name\":\"Exelixis Media P.C.\",\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2022\\\/06\\\/exelixis-logo.png\",\"contentUrl\":\"https:\\\/\\\/www.javacodegeeks.com\\\/wp-content\\\/uploads\\\/2022\\\/06\\\/exelixis-logo.png\",\"width\":864,\"height\":246,\"caption\":\"Exelixis Media P.C.\"},\"image\":{\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/javacodegeeks\",\"https:\\\/\\\/x.com\\\/javacodegeeks\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.javacodegeeks.com\\\/#\\\/schema\\\/person\\\/771a6504862edc45322776832cbce413\",\"name\":\"Andrey Redko\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g\",\"caption\":\"Andrey Redko\"},\"description\":\"Andriy is a well-grounded software developer with more then 12 years of practical experience using Java\\\/EE, C#\\\/.NET, C++, Groovy, Ruby, functional programming (Scala), databases (MySQL, PostgreSQL, Oracle) and NoSQL solutions (MongoDB, Redis).\",\"sameAs\":[\"http:\\\/\\\/aredko.blogspot.com\\\/\",\"http:\\\/\\\/ca.linkedin.com\\\/in\\\/aredko\"],\"url\":\"https:\\\/\\\/www.javacodegeeks.com\\\/author\\\/andrey-redko\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"MySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks","description":"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\/Values5. MySQL and","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html","og_locale":"en_US","og_type":"article","og_title":"MySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks","og_description":"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\/Values5. MySQL and","og_url":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html","og_site_name":"Java Code Geeks","article_publisher":"https:\/\/www.facebook.com\/javacodegeeks","article_published_time":"2015-07-06T07:00:19+00:00","article_modified_time":"2023-12-05T14:37:08+00:00","og_image":[{"width":150,"height":150,"url":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg","type":"image\/jpeg"}],"author":"Andrey Redko","twitter_card":"summary_large_image","twitter_creator":"@javacodegeeks","twitter_site":"@javacodegeeks","twitter_misc":{"Written by":"Andrey Redko","Est. reading time":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#article","isPartOf":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html"},"author":{"name":"Andrey Redko","@id":"https:\/\/www.javacodegeeks.com\/#\/schema\/person\/771a6504862edc45322776832cbce413"},"headline":"MySQL vs. MongoDB: Choosing a Data Management Solution","datePublished":"2015-07-06T07:00:19+00:00","dateModified":"2023-12-05T14:37:08+00:00","mainEntityOfPage":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html"},"wordCount":4407,"commentCount":11,"publisher":{"@id":"https:\/\/www.javacodegeeks.com\/#organization"},"image":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#primaryimage"},"thumbnailUrl":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg","keywords":["Databases","MongoDB","MySQL","NoSQL","SQL"],"articleSection":["Software Development"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html","url":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html","name":"MySQL vs. MongoDB: Choosing a Data Management Solution - Java Code Geeks","isPartOf":{"@id":"https:\/\/www.javacodegeeks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#primaryimage"},"image":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#primaryimage"},"thumbnailUrl":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg","datePublished":"2015-07-06T07:00:19+00:00","dateModified":"2023-12-05T14:37:08+00:00","description":"Table Of Contents 1. Introduction2. The dominance of RDBM systems3. A new era of NoSQL movement4. Tables vs Documents vs Graphs vs Key\/Values5. MySQL and","breadcrumb":{"@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#primaryimage","url":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg","contentUrl":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2012\/10\/software-development-2-logo.jpg","width":150,"height":150},{"@type":"BreadcrumbList","@id":"https:\/\/www.javacodegeeks.com\/2015\/07\/mysql-vs-mongodb.html#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.javacodegeeks.com\/"},{"@type":"ListItem","position":2,"name":"Software Development","item":"https:\/\/www.javacodegeeks.com\/category\/software-development"},{"@type":"ListItem","position":3,"name":"MySQL vs. MongoDB: Choosing a Data Management Solution"}]},{"@type":"WebSite","@id":"https:\/\/www.javacodegeeks.com\/#website","url":"https:\/\/www.javacodegeeks.com\/","name":"Java Code Geeks","description":"Java Developers Resource Center","publisher":{"@id":"https:\/\/www.javacodegeeks.com\/#organization"},"alternateName":"JCG","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.javacodegeeks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.javacodegeeks.com\/#organization","name":"Exelixis Media P.C.","url":"https:\/\/www.javacodegeeks.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.javacodegeeks.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","contentUrl":"https:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","width":864,"height":246,"caption":"Exelixis Media P.C."},"image":{"@id":"https:\/\/www.javacodegeeks.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/javacodegeeks","https:\/\/x.com\/javacodegeeks"]},{"@type":"Person","@id":"https:\/\/www.javacodegeeks.com\/#\/schema\/person\/771a6504862edc45322776832cbce413","name":"Andrey Redko","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/16419ce8394173028eddaeb992859862bab50cfcf74589fa9bb9a3dd8bb27518?s=96&d=mm&r=g","caption":"Andrey Redko"},"description":"Andriy is a well-grounded software developer with more then 12 years of practical experience using Java\/EE, C#\/.NET, C++, Groovy, Ruby, functional programming (Scala), databases (MySQL, PostgreSQL, Oracle) and NoSQL solutions (MongoDB, Redis).","sameAs":["http:\/\/aredko.blogspot.com\/","http:\/\/ca.linkedin.com\/in\/aredko"],"url":"https:\/\/www.javacodegeeks.com\/author\/andrey-redko"}]}},"_links":{"self":[{"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/posts\/41493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/users\/141"}],"replies":[{"embeddable":true,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/comments?post=41493"}],"version-history":[{"count":0,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/posts\/41493\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/media\/2386"}],"wp:attachment":[{"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/media?parent=41493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/categories?post=41493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.javacodegeeks.com\/wp-json\/wp\/v2\/tags?post=41493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}