{"id":730,"date":"2015-05-29T13:15:06","date_gmt":"2015-05-29T13:15:06","guid":{"rendered":"https:\/\/ee.yelkdev.site\/?p=730"},"modified":"2023-09-22T17:51:38","modified_gmt":"2023-09-22T16:51:38","slug":"nosql-mongodb-and-the-importance-of-data-modelling","status":"publish","type":"post","link":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/","title":{"rendered":"NoSQL, MongoDB, and the importance of Data Modelling"},"content":{"rendered":"<p>It\u2019s a brave new NoSQL powered world out there, and companies are increasingly moving to new technologies for data storage and reporting. \u00a0And these solutions are indeed powerful \u2014 removing database features that people don\u2019t always need (stored procedures, schema enforcement by the db, etc.), in exchange for features that we do want (really easy replication and failover, easy horizontal scalability, better concurrency).<\/p>\n<p>But these systems aren\u2019t a magic bullet, as evidenced by the number of people that have trouble using them, and the number of people that actively complain about them.<\/p>\n<p>This is probably true for almost all NoSQL solutions, but in my experience it seems particularly true with MongoDB, probably for a few reasons:<\/p>\n<ul>\n<li>It\u2019s the NoSQL solution I have the most experience with, so it\u2019s the one I have the most opportunity to complain about.<\/li>\n<li>It\u2019s one of the most (if not the most) popular NoSQL DBs, so it\u2019s the solution most people try, often the first solution people try, and one of the solutions most likely to be used by <del>fanboys<\/del> relatively inexperienced developers.<\/li>\n<li>It is a document database, which offers the widest array of modelling options \u2014 for better and for worse.<\/li>\n<\/ul>\n<p>Data modelling is important no matter what persistence solution you use (yes, even in the SQL world, where there are endless courses, books, and articles available about basic modelling choices, like how to best represent a tree or graph\u00b9). But document databases provide maximum flexibility in how you persist a given bunch of data&#8230;so with good data modelling techniques you have the maximum ability to \u201cmodel your way out of trouble\u201d with performance and concurrency issues, but with bad modelling you have a lot of rope to hang yourself with.<\/p>\n<p>In my professional experience, I\u2019ve run into a number of situations where a poor developer experience with MongoDB was largely based on the way it was being used, and suboptimal data modelling.<\/p>\n<p>Let\u2019s look at two of those cases.<\/p>\n<h3>Example 1: A reservation system<\/h3>\n<p>This is one of the more recent cases I\u2019ve dealt with, a leading online restaurant reservation system developed by our friends at bookatable.com. <a href=\"http:\/\/www.bookatable.com\/\" target=\"_blank\" rel=\"noopener\">Bookatable<\/a> provides real-time reservation and marketing services for 13,000 restaurants across 12 countries, and they are very committed to delivering up-to-date table availability information to users of their consumer web and native apps. Their working data set is the set of available table reservations for each restaurant, and it covers many days in the immediate past and near future, with many different tables for each restaurant.<\/p>\n<p>Originally, the data was modelled with one document per possible reservation, with a structure something like this:<\/p>\n<pre>{\r\n  _id: <b>\/\/a unique MongoDB ObjectId<\/b>,\r\n  restaurantId: <b>\/\/int or long<\/b>,\r\n  date: <b>\/\/a date<\/b>,\r\n  time of day: <b>\/\/a time<\/b>,\r\n  <b>...<\/b>\r\n  <b>\/\/other details of the reservation<\/b>\r\n  <b>\/\/(table no, size, etc) <\/b>\r\n}<\/pre>\n<p>The developers at Bookatable are very sharp, had done a great job with general performance tuning of their app, and were following most of the published MongoDB guidelines. Even so, they were experiencing significant performance problems, to the extent that there was concern from management that MongoDB might not be the correct tool for the job. In fact, it can be quite suitable for this approach, and some relatively minor tweaks to the data model led to some dramatic improvements.<\/p>\n<h3>Tiny documents that are too finely grained:<\/h3>\n<p>MongoDB documentation regularly mentions the maximum document size (as of 2015 it\u2019s <a href=\"http:\/\/docs.mongodb.org\/v2.6\/reference\/limits\/\" target=\"_blank\" rel=\"noopener\">16MB<\/a>), but there\u2019s very little discussion of the <i>minimum<\/i> effective document size. It varies from setup to setup, and is best measured empirically, but in a discussion I had in a London pub with <a href=\"http:\/\/www.mongodb.com\/leadership\" target=\"_blank\" rel=\"noopener\">Dwight Merriman<\/a> once, his opinion was that the effective minimum size was about 4KB.<\/p>\n<p>This makes sense when you think about how MongoDB loads documents from disk. MongoDB files are organised into 4KB pages, and the DB always reads an entire page into memory at once\u00b2. Some of the data in that page will be the document you\u2019re looking for. However, MongoDB documents are <i>not<\/i> stored in any particular order (including _id order),\u00a0and a page contains random documents\u00b3. So it\u2019s usually best to work under the assumption that the rest of the page contains data completely unrelated to your query, and that having been loaded into memory, it will then be ignored.<\/p>\n<p>You don\u2019t need to worry about a small number of your documents being slightly smaller than the limit, but if you\u2019ve got a lot of documents that are <i>drastically<\/i> smaller than the page size then you are very likely throwing away a lot of the data your system spends precious IO retrieving.<\/p>\n<p>Documents larger than page size are no problem, as MongoDB does guarantee that a single document is always stored contiguously on disk, which makes it easy to return. So between 4KB and 16MB, smaller is better, but below 4KB smaller can be <i>really bad<\/i>.<\/p>\n<p>A document per individual reservation meant that almost all of the documents in the database were under the minimum effective document size\u2026often by an order of magnitude. The client was definitely experiencing the effects of all of that wasted IO.<\/p>\n<h3>Retrieving a large number of documents to satisfy common queries:<\/h3>\n<p>Related to the previous point, I generally use \u201cthe number of documents that need to be loaded\u201d as an easy-to-calculate approximation of \u201chow expensive is this query\u201d. It\u2019s far from exact, but it\u2019s usually pretty easy to figure out, and it can go a long way with a little bit of napkin math.<\/p>\n<p>For this client, a common query is \u201cfor a given restaurant, what are all of the times I can get a free table for X people in the next two days?\u201d. Because of how the data was organised (one document per potential reservation), one document had to be retrieved for each potential table with the right size, times the number of timeslots. In a large restaurant (say 50 tables) with 20 time-slots each day (open 10 hours a day with 2 possible timeslots per hour per table) up to 2,000 documents need to be returned for a 2 day span, and that means (give or take) 2,000 potential random IO operations. Consider the same operation across a set of restaurants in a city, and a very large amount of IO is required to answer queries.<\/p>\n<h3>How data modelling fixed the problem:<\/h3>\n<p>Changing the data model so that a single document contained all available reservations per restaurant per day solves almost all of these performance issues.<\/p>\n<p>The documents got larger, but because they were previously well under the 4KB limit, this doesn\u2019t negatively impact the IO requirements of the system at all. There are also far fewer documents &#8211; now just 1 document per restaurant per day. Satisfying common queries now requires retrieving far fewer documents &#8211; the common query \u201cfor a given restaurant, what are all of the times I can get a free table for X people in the next two days?\u201d &#8211; now requires exactly 2 documents to be loaded.<\/p>\n<p>This also has an effect on the number of writes that are required: Updating a restaurant\u2019s inventory for a day (or adding data for a new day) requires just one document write.<\/p>\n<h3>Example 2: Time series data &amp; calculating catchments<\/h3>\n<p>This is a slightly older example from a project Equal Experts worked on with Telef\u00f3nica Digital in 2012-2013, with a very interesting use case: Calculating catchment areas over time.<\/p>\n<p>Briefly, a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Catchment_area\" target=\"_blank\" rel=\"noopener\">catchment area<\/a> is the area where the people who visit a certain location live. As traffic varies a lot over the course of a year, the requirement was to calculate a catchment area over time: \u201cOver a 6 month period, where did the people who visited location X come from, and in what concentrations?\u201d<\/p>\n<p>The United Kingdom was divided into about 120,000 areas (\u201clocations\u201d) and for each day, traffic movement was described as \u201cX people who live in location Y visited location Z.\u201d The challenge was to be able to retrieve and aggregate that information in a timely fashion to generate a report.<\/p>\n<p>The product designer even provided a worst case \u201cnightmare query:\u201d Calculate the catchment for a collection of 80 destinations over a period of 6 months.<\/p>\n<p>Another consultancy\u2074 took the data, and modelled it in the most straightforward way they could think of, where each document was a tuple:<\/p>\n<pre>{sourceLocationId, destinationLocationId, date, visitors}<\/pre>\n<p>&nbsp;<\/p>\n<p>This didn\u2019t work. In fact, it didn\u2019t work so much that when we first got involved tuning this particular use case, the other consultancy determined that MongoDB was completely unsuitable for the task at hand, and shouldn\u2019t be used.<\/p>\n<p>The problem is that this tuple is significantly less than 4KB in size, at about 128 bits (plus key names) per tuple. And with 120,000 sources and destinations, up to 120k * 120k documents had to be loaded each day. That\u2019s 14.4 <i>billion<\/i> documents per day.<\/p>\n<p>Trying to insert that many documents every day completely overloaded the MongoDB cluster. The team involved tried everything they could think of to performance tune the cluster (more shards, more IO, more mongos instances).<\/p>\n<p>Worse, satisfying the \u201cnightmare query\u201d involved loading documents for 80 destinations * 120,000 potential sources * 180 days, or 1.7 billion documents, out of a potential 2.59 <i>trillion<\/i> documents in the database for the time period.<\/p>\n<p>It was at this point that Equal Experts first became involved in this particular feature. Our very first suggestion was to rethink the data model, and as it happened, changing the data model completely solved this performance problem.<\/p>\n<p>Our first modelling change was to use larger documents, where each document contained all of the traffic for 1 destination over 1 day:<\/p>\n<pre>{\r\n  _id: <b>\/\/an objectId<\/b>,\r\n  destinationLocationId: <b>\/\/int<\/b>,\r\n  date: <b>\/\/date<\/b>,\r\n  sources: {\r\n    sourceLocationId: visitors <b>\/\/both ints<\/b>,\r\n    <b>....<\/b>\r\n    <b>\/\/up to 120,000 of these<\/b>\r\n  }\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<p>This resulted in much larger documents, but still comfortably under the MongoDB document size limit.<\/p>\n<p>This immediately reduced the number of documents required each day from 14.4 billion to 120,000. And the number of documents required to satisfy the nightmare query was 80 destinations * 180 days = 14,400 documents.<\/p>\n<p>This was an improvement, but we were still unhappy with loading over 14 thousand documents to satisfy a query, so we further optimised the model.<\/p>\n<p>We stayed with a document per destination per day, but instead of just storing the visits for that day, we stored the visits for that day and the total visits so far that year:<\/p>\n<pre>{\r\n  _id: <b>\/\/an objectId<\/b>,\r\n  destinationLocationId: <b>\/\/int<\/b>,\r\n  date: <b>\/\/date<\/b>,\r\n  sources: {\r\n    sourceLocationId: {\r\n      dailyVisits: <b>\/\/int<\/b>,\r\n      ytd: <b>\/\/int<\/b>\r\n    },\r\n    <b>....<\/b>\r\n    <b>\/\/up to 120,000 of these<\/b>\r\n  }\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<blockquote><p>\u00a0At this point the documents were large enough that we were heavily optimising key names \u00a0to keep documents under control. I have omitted that here to keep things more readable.<\/p><\/blockquote>\n<p>Now to return the catchment for a date range, you query the document for the end of the range, and the document for the beginning of the range, and just subtract the two sets of totals from each other, and presto: you\u2019ve got the number of visits during the range.<\/p>\n<p>Inserting new data is still pretty easy: Just load yesterday\u2019s data, add today\u2019s numbers to it, and you\u2019ve got the new totals for so far this year.<\/p>\n<p>The number of documents that need to be loaded to satisfy the \u201cnightmare query\u201d is now 80 destinations * 2 days = 160 documents.<\/p>\n<p>That\u2019s a total of 10.8 million <i>times fewer<\/i> documents that theoretically would need to be retrieved\u2075. It\u2019s highly doubtful that any amount of physical tuning could ever provide a similar performance increase.<\/p>\n<h3>Conclusions<\/h3>\n<p>So, to recap:<\/p>\n<ul>\n<li>The number of documents that need to be read (or written) by a particular operation is often a useful approximation for much IO needs to be performed.<\/li>\n<li>Modelling is important. Changes to a data model can impact performance as much, or even more than regular performance tuning, physical tuning, or configuration changes.<\/li>\n<li>Document databases give you maximum flexibility for modelling, and therefore a lot of potential power, but also a lot of rope with which to hang yourself.<\/li>\n<li>A good data model design at the beginning of a project can be worth its weight in gold.<\/li>\n<\/ul>\n<p>&#8230;and&#8230;<\/p>\n<p><strong>If you want some advice about data modelling, (especially with NoSQL and MongoDB), we\u2019re available.<\/strong><\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<p>\u00b9 \u00a0when you can\u2019t just use <a href=\"http:\/\/neo4j.com\/\" target=\"_blank\" rel=\"noopener\">neo4j<\/a> \ud83d\ude09<br \/>\n\u00b2 \u00a0this IO strategy is also used by virtually every SQL database on the market.<br \/>\n\u00b3 \u00a0a single page will always contain documents from the same collection, but there are no other guarantees at all about which documents they will be.<br \/>\n\u2074 \u00a0in this case, names omitted to protect the very, very, guilty \u2014 as will shortly become clear<br \/>\n\u2075 \u00a0\u201ctheoretically\u201d mostly because the other company\u2019s implementation was never able to successfully answer a query<\/p>\n","protected":false},"excerpt":{"rendered":"<p>It\u2019s a brave new NoSQL powered world out there, and companies are increasingly moving to new technologies for data storage and reporting. \u00a0And these solutions are indeed powerful \u2014 removing database features that people don\u2019t always need (stored procedures, schema enforcement by the db, etc.), in exchange for features that we do want (really easy [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":731,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"location":[397],"class_list":["post-730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tech-focus"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v25.9 (Yoast SEO v25.9) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>NoSQL, MongoDB, and the importance of Data Modelling | Equal Experts<\/title>\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.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"NoSQL, MongoDB, and the importance of Data Modelling\" \/>\n<meta property=\"og:description\" content=\"It\u2019s a brave new NoSQL powered world out there, and companies are increasingly moving to new technologies for data storage and reporting. \u00a0And these solutions are indeed powerful \u2014 removing database features that people don\u2019t always need (stored procedures, schema enforcement by the db, etc.), in exchange for features that we do want (really easy [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\" \/>\n<meta property=\"og:site_name\" content=\"Equal Experts\" \/>\n<meta property=\"article:published_time\" content=\"2015-05-29T13:15:06+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-09-22T16:51:38+00:00\" \/>\n<meta name=\"author\" content=\"dorightdigital\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@EqualExperts\" \/>\n<meta name=\"twitter:site\" content=\"@EqualExperts\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"dorightdigital\" \/>\n\t<meta name=\"twitter:label2\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\"},\"author\":{\"name\":\"dorightdigital\",\"@id\":\"https:\/\/www.equalexperts.com\/#\/schema\/person\/3faccba812b830c6efa9053ecb9d231a\"},\"headline\":\"NoSQL, MongoDB, and the importance of Data Modelling\",\"datePublished\":\"2015-05-29T13:15:06+00:00\",\"dateModified\":\"2023-09-22T16:51:38+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\"},\"wordCount\":2041,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.equalexperts.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage\"},\"thumbnailUrl\":\"\",\"articleSection\":[\"Tech Focus\"],\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\",\"url\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\",\"name\":\"NoSQL, MongoDB, and the importance of Data Modelling | Equal Experts\",\"isPartOf\":{\"@id\":\"https:\/\/www.equalexperts.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage\"},\"thumbnailUrl\":\"\",\"datePublished\":\"2015-05-29T13:15:06+00:00\",\"dateModified\":\"2023-09-22T16:51:38+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage\",\"url\":\"\",\"contentUrl\":\"\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.equalexperts.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"NoSQL, MongoDB, and the importance of Data Modelling\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.equalexperts.com\/#website\",\"url\":\"https:\/\/www.equalexperts.com\/\",\"name\":\"Equal Experts\",\"description\":\"Making Software. Better.\",\"publisher\":{\"@id\":\"https:\/\/www.equalexperts.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.equalexperts.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.equalexperts.com\/#organization\",\"name\":\"Equal Experts\",\"url\":\"https:\/\/www.equalexperts.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\/\/www.equalexperts.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.equalexperts.com\/wp-content\/uploads\/2018\/08\/Equal_Experts_Logo_CMYK_Colour.jpg\",\"contentUrl\":\"https:\/\/www.equalexperts.com\/wp-content\/uploads\/2018\/08\/Equal_Experts_Logo_CMYK_Colour.jpg\",\"width\":719,\"height\":340,\"caption\":\"Equal Experts\"},\"image\":{\"@id\":\"https:\/\/www.equalexperts.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/x.com\/EqualExperts\",\"https:\/\/www.linkedin.com\/company\/equal-experts\/?viewAsMember=true\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.equalexperts.com\/#\/schema\/person\/3faccba812b830c6efa9053ecb9d231a\",\"name\":\"dorightdigital\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\/\/www.equalexperts.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/5fc44582a07d3eba2d5f99cc09e716f515d82ed73286ecda5e9db6a056dceed6?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/5fc44582a07d3eba2d5f99cc09e716f515d82ed73286ecda5e9db6a056dceed6?s=96&d=mm&r=g\",\"caption\":\"dorightdigital\"},\"sameAs\":[\"http:\/\/dorightdigital.wpengine.com\"]}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"NoSQL, MongoDB, and the importance of Data Modelling | Equal Experts","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.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/","og_locale":"en_GB","og_type":"article","og_title":"NoSQL, MongoDB, and the importance of Data Modelling","og_description":"It\u2019s a brave new NoSQL powered world out there, and companies are increasingly moving to new technologies for data storage and reporting. \u00a0And these solutions are indeed powerful \u2014 removing database features that people don\u2019t always need (stored procedures, schema enforcement by the db, etc.), in exchange for features that we do want (really easy [&hellip;]","og_url":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/","og_site_name":"Equal Experts","article_published_time":"2015-05-29T13:15:06+00:00","article_modified_time":"2023-09-22T16:51:38+00:00","author":"dorightdigital","twitter_card":"summary_large_image","twitter_creator":"@EqualExperts","twitter_site":"@EqualExperts","twitter_misc":{"Written by":"dorightdigital","Estimated reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#article","isPartOf":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/"},"author":{"name":"dorightdigital","@id":"https:\/\/www.equalexperts.com\/#\/schema\/person\/3faccba812b830c6efa9053ecb9d231a"},"headline":"NoSQL, MongoDB, and the importance of Data Modelling","datePublished":"2015-05-29T13:15:06+00:00","dateModified":"2023-09-22T16:51:38+00:00","mainEntityOfPage":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/"},"wordCount":2041,"commentCount":0,"publisher":{"@id":"https:\/\/www.equalexperts.com\/#organization"},"image":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage"},"thumbnailUrl":"","articleSection":["Tech Focus"],"inLanguage":"en-GB","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/","url":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/","name":"NoSQL, MongoDB, and the importance of Data Modelling | Equal Experts","isPartOf":{"@id":"https:\/\/www.equalexperts.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage"},"image":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage"},"thumbnailUrl":"","datePublished":"2015-05-29T13:15:06+00:00","dateModified":"2023-09-22T16:51:38+00:00","breadcrumb":{"@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/"]}]},{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#primaryimage","url":"","contentUrl":""},{"@type":"BreadcrumbList","@id":"https:\/\/www.equalexperts.com\/blog\/tech-focus\/nosql-mongodb-and-the-importance-of-data-modelling\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.equalexperts.com\/"},{"@type":"ListItem","position":2,"name":"NoSQL, MongoDB, and the importance of Data Modelling"}]},{"@type":"WebSite","@id":"https:\/\/www.equalexperts.com\/#website","url":"https:\/\/www.equalexperts.com\/","name":"Equal Experts","description":"Making Software. Better.","publisher":{"@id":"https:\/\/www.equalexperts.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.equalexperts.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"},{"@type":"Organization","@id":"https:\/\/www.equalexperts.com\/#organization","name":"Equal Experts","url":"https:\/\/www.equalexperts.com\/","logo":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/www.equalexperts.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.equalexperts.com\/wp-content\/uploads\/2018\/08\/Equal_Experts_Logo_CMYK_Colour.jpg","contentUrl":"https:\/\/www.equalexperts.com\/wp-content\/uploads\/2018\/08\/Equal_Experts_Logo_CMYK_Colour.jpg","width":719,"height":340,"caption":"Equal Experts"},"image":{"@id":"https:\/\/www.equalexperts.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/EqualExperts","https:\/\/www.linkedin.com\/company\/equal-experts\/?viewAsMember=true"]},{"@type":"Person","@id":"https:\/\/www.equalexperts.com\/#\/schema\/person\/3faccba812b830c6efa9053ecb9d231a","name":"dorightdigital","image":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/www.equalexperts.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/5fc44582a07d3eba2d5f99cc09e716f515d82ed73286ecda5e9db6a056dceed6?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/5fc44582a07d3eba2d5f99cc09e716f515d82ed73286ecda5e9db6a056dceed6?s=96&d=mm&r=g","caption":"dorightdigital"},"sameAs":["http:\/\/dorightdigital.wpengine.com"]}]}},"_links":{"self":[{"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/posts\/730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/comments?post=730"}],"version-history":[{"count":0,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/posts\/730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/media?parent=730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/categories?post=730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/tags?post=730"},{"taxonomy":"location","embeddable":true,"href":"https:\/\/www.equalexperts.com\/wp-json\/wp\/v2\/location?post=730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}