{"id":7525,"date":"2014-11-05T17:10:11","date_gmt":"2014-11-05T17:10:11","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/pass-summit-14-dispatches-documentdb\/"},"modified":"2017-08-10T12:49:26","modified_gmt":"2017-08-10T12:49:26","slug":"pass-summit-14-dispatches-documentdb","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/pass-summit-14-dispatches-documentdb\/","title":{"rendered":"PASS Summit 14 Dispatches: DocumentDB"},"content":{"rendered":"<p>During the <a href=\"http:\/\/www.sqlpass.org\/summit\/2014\/Home.aspx\">PASS Summit 14<\/a> keynote, TK &#8220;Ranga&#8221; Rengarajan mentioned briefly Microsoft&#8217;s <a href=\"http:\/\/weblogs.asp.net\/scottgu\/azure-new-documentdb-nosql-service-new-search-service-new-sql-alwayson-vm-template-and-more\">DocumentDB<\/a>, a new NoSQL database. I was hoping to hear more. It&#8217;s an Azure-hosted JSON document data store and seems to be an attempt to marry the schema &#8216;flexibility&#8217; and  easy scalability that developers crave from their databases with the transactional capabilities of a relational database.<\/p>\n<p>Web or mobile applications often need to collect a lot of data, and the structure of this data can be ill-defined; the next &#8216;row&#8217; won&#8217;t necessarily look anything like the previous one. It calls for a more &#8216;flexible&#8217; and also more easily scalable data store than can be offered by a traditional relational database. Most NoSQL databases boast of being &#8220;schema-free&#8221; so have the requisite &#8216;flexibility&#8217;, and certainly aren&#8217;t burdened with the costs associated with such niceties as enforcing constraints, or maintaining keys. They also offer built-in horizontal scaling, replicating parts of the dataset across numerous &#8216;utility&#8217; machines and then using Map\/Reduce functionality to query it.<\/p>\n<p>Ranga&#8217;s point was that every device looks at some different part of the data and all must have &#8216;consistency&#8217; in the data they share, with this &#8216;consistency&#8217; enabled via cloud. <i>Eventually<\/i>, at least.<\/p>\n<p>Without ACID transactions, there is no guarantee one transaction won&#8217;t see the partial effects of another. If the data is only &#8216;eventually consistent&#8217;, a model employed by many NoSQL databases, then in theory a query could read invalid data values, because the full effects of a set of writes hasn&#8217;t yet propagated to all part of the distributed system. In practice, it&#8217;s usually not as bad as this sounds. In some NoSQL stores, it might mean queries read a correct, but stale data value, rather than the true current value. Also, some NoSQL systems do use distributed transactions to enforce ACID properties during modifications, which works <i>most<\/i> of the time. Neither proposition is ideal.<\/p>\n<p>DocumentDB tries to offer the answer to these apparently-conflicting requirements of flexibility and scalability versus data consistency. It is schema-free and designed to &#8216;scale linearly&#8217;. However, it also comes with many features comforting to the DBA. We can access data using a very SQL-like syntax. We can create stored procedures, triggers and user defined types, albeit in JavaScript (no groaning at the back).<\/p>\n<p>Crucially, it also seems to offer a high degree of control over the transactional consistency. We register a JavaScript stored procedure with a collection of documents, and DocumentDB will execute transactions using Snapshot isolation, across any documents in a collection (although not between collections).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>During the PASS Summit 14 keynote, TK &#8220;Ranga&#8221; Rengarajan mentioned briefly Microsoft&#8217;s DocumentDB, a new NoSQL database. I was hoping to hear more. It&#8217;s an Azure-hosted JSON document data store and seems to be an attempt to marry the schema &#8216;flexibility&#8217; and easy scalability that developers crave from their databases with the transactional capabilities of&#8230;&hellip;<\/p>\n","protected":false},"author":200703,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2,47125],"tags":[],"coauthors":[],"class_list":["post-7525","post","type-post","status-publish","format-standard","hentry","category-blogs","category-editorials"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/7525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/200703"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=7525"}],"version-history":[{"count":5,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/7525\/revisions"}],"predecessor-version":[{"id":72036,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/7525\/revisions\/72036"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=7525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=7525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=7525"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=7525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}