20160330

Wed Mar 30 07:57:03 EDT 2016 Slept from ten-something to around six. Sixty-three and mostly sunny today, but a chance of rain this afternoon. Goals: Work: - Ask CDW about CALs for 2012 R2 upgrade Done. Twenty minute walk at lunch. Pleasant temperature. Mostly cloudy. Saw a crap ton of robins. Spent some time reading about document-oriented databases (and key-value stores). http://docs.couchbase.com/developer/dev-guide-3.0/compare-docs-vs-relational.html https://msdn.microsoft.com/en-us/magazine/hh547103.aspx "The NoSQL and document databases provide an alternative to relational databases, not a replacement. Each has its place, and they simply provide you with more options from which to choose. But how to choose? An important gauge is the Consistency, Availability and Partition Tolerance (CAP) theorem. It says that when working in distributed systems, you can only have two of the three guarantees (the C, the A or the P), so you have to pick what’s important. If Consistency is the most critical, then you need to go with a relational database." "A term you’ll hear frequently is 'eventual consistency,' or as expressed on the RavenDB site: 'better stale than offline.' In other domains, eventual consistency is sufficient. It’s OK if data you’re retrieving isn’t up-to-the-millisecond accurate. Perhaps, then, it’s more important that some version of the data is available, rather than waiting for all of the transactions to catch up. This is related to the A (Availability) in CAP, which is focused on server uptime. Knowing that you’ll always have access to the database takes precedence and is a huge benefit to database performance (that is, document databases are fast!). You’ll find that the P, Partition Tolerance, is also important to the document databases, especially when scaling horizontally." http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ ^ A really good example of document-oriented database use case (for tv shows) "Once we started doing ugly MongoDB joins manually in the Diaspora code, we knew it was the first sign of trouble. It was a sign that our data was actually relational, that there was value to that structure, and that we were going against the basic concept of a document data store. Whether you’re duplicating critical data (ugh), or using references and doing joins in your application code (double ugh), when you have links between documents, you’ve outgrown MongoDB. When the MongoDB folks say “documents,” in many ways, they mean things you can print out on a piece of paper and hold. A document may have internal structure — headings and subheadings and paragraphs and footers — but it doesn’t link to other documents. It’s a self-contained piece of semi-structured data. If your data looks like that, you’ve got documents. Congratulations! It’s a good use case for Mongo. But if there’s value in the links between documents, then you don’t actually have documents. MongoDB is not the right solution for you. It’s certainly not the right solution for social data, where links between documents are actually the most critical data in the system." Home: - Work on static site generator Not much. - Work on D&D stuff Not much. - Although, if I get my replacement debit card today, I may spend time updating all my accounts. Sigh. The new card has not arrived yet. Went for another twenty minute walk after I got home from work. Apparently, it's that time of year again when I get the vague urge to buy a sailboat. Friendship sloops: http://www.fss.org/slphist.htm http://www.fss.org/

< ^ txt