Microsoft opens trenchcoat, reveals 'in-memory' Big Data column If there’s one thing scarier than the big data tsunami, tech vendors tell us, then it’s tech vendors getting left out of the big-data conversation. Microsoft is the latest software maker to crowbar itself into the debate on big data, this time claiming a place at the table on in-memory databases. According to a blog here and …
... someone asked for a "sqlite-type nosql" solution. Because, you know, databases are hot shit. Or because the data was all about nested objects and such. But for how much data? "50-100 objects". Ah. Use the built-in serialisation and drop the result in a file, there's a good developer.
We have computing power that approaches "free", there's yet another database hype going on, and this time we have so much data it's not funny any longer. What it all means? Most of it is crud; how much truly interesting stuff is there to be found on facebook, google+, and so on? Not that much. But we like to believe that with enough massaging the lead turns into gold.
How many users of various "alternative databases" actually need that? Quite a lot fewer than're actually trying to use the things. Nothing wrong with using whatever tool works and doesn't have nasty side effects like subtly corrupting your data, but that doesn't automatically make for a "best" or even "good enough" solution. Sometimes it's good to remember that there's still problems around best solved by using a key/value store without any additional "NoSQL" or "XML" or other buzzword-du-jour layers. What was it again, the master shows in the choosing?
There are no alternative databases here... just researching/exploiting (decades later) alternative storage and indexing structures. Think of it: the columnar storage in SQL Server 2012 is built on top of regular row-oriented structures but exploits column compression along with smart ordering. For this new thing just try to be a bit more creative: in memory databases doesn't necessarily have drop any ACID property, nor they have to use b-trees...
Typical NoSQL thingamajigs simply want to store-fast-think-later. It's not that by storing things by keys/values make the conceptual data model disappear. Sooner of later people will have to analyze the stored data and being so close and tied to a (simple) storage mechanism immediately fires back. They'll have to understand the real data model behind property bags and they'll need a powerful language to be able to make requests. Maybe a language that combines the power of algebra and calculus. So they'll end up building new MaybeSQL fads until they realize that it would have been better to start off with a proper RDBMS, and learn about Data Dependent Routing techniques, instead of using map-reduce to do basic things like hash-joins.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
