New SelecTViews –
Not your ordinary web show, Watson! You may have seen him on Jeopardy! – Stephen Baker joins us on the show today talking about what was learned with the project. Stephen Baker wrote the book (literally) on the Watson project and all that it entailed – do not miss this show…
[Watch the show here, free]
New Terms for Web-Scale Persistence
We have been looking at different persistence techniques the last couple of newsletters. Today Michal adds a new term to the discussion, “polyglot persistence”.
I looked it up on Google and was not able to find a single specific definition. It appears that it can have different perspectives (feel free to bring me up to speed on this).
In the simplest form, a Polyglot Persistence model is one where there is more than one data storage point. It can be on one or more servers.
A more extreme form would be data storage in multiple machines, perhaps even using different storage techniques.
At the core of the issue is the need to add processors, memory and spindles (disk) without scaling up…adding more servers; not bigger. Most contemporary Relational databases are not typically built around this concept (I’d be interested to hear from our Oracle readers using Oracle Grid Technology to see how it fits into scale out capabilities).
SQL Server touches on the need for different types of storage by including BLOB, XML and the ability to shred it, or filestreams and the ability to include files in transactions. But we still have the issue of scale. Some mention Parallel Data Warehouse as scaling out. However, that is targeted at warehouse databases not OLTP.
Are we that far apart in our requirements for persistence? Can we have speed with ACID capabilities? What about database engines such as Cache that tries to be an Object Database and a Relational database all in one? It’s hard to say where our polyglot will take us. One thing is for sure; they’re here to stay.
Michael Writes:
Hey Ben,
…Thought I’d share my perspective w/ you directly
Caveat: I’m a Software Architect interloping in the DB world!
The approach you’re describing has been dubbed polyglot persistence in the industry at large. I believe it to be a very powerful concept.
Though I don’t feel the concept is necessarily centered on ‘web scale’ as much as the mantra of “fit the store to the form”. As we know, there are many forms of data that RDBMS simply don’t ‘do’ well. When the store fits the form, the performance, scalability, etc metrics are orders of magnitude greater than shoehorning the data into a relational model.
The form that fascinates me currently is data ‘entities’ w/ a high number of ‘complex’ inter-relationships. RDBMS just don’t/can’t easily handle this. Enter the Graph DB.
Another ‘form’ that an RDBMS doesn’t handle well, is de-normalization, necessary for broad searching.
A third form is the ‘document’ storage paradigm, of which you’ve provided a few examples, some leveraging RDBMS. While these are all valid approaches, it can be shown that ‘native’ doc DBs have different value characteristics than using an RDBMS for the same purpose.
I’ve been meditating on the following equation for some time:
Federated RDBMS + Doc Db + Graph Db + Search Engine + STS + SOA = 1 kickass Arch
(Of course only applied when needed and used responsibly 😉
Get into the conversation by sending your comments to me. It would be interesting to hear from those responsible for the integrity of data either using or not using noSQL with a perspective of how this impacts your mandate. Drop me a note at facebook, twitter, or email at btaylor@sswug.org.
Cheers,
Ben
Featured Article(s)
T-SQL Features of SQL Server 2005 (Part 1 of 3)
Many new T-SQL features were added with the release of SQL Server 2005. Developers and DBAs may not be taking advantage of them. Learn how to use new features like Common Table Expressions, ranking functions, the output clause, and more.
Featured White Paper(s)
Essential Performance Tools for SQL Server DBAS
Optimizing SQL Server performance can be a daunting task. Especially so for an increasing number of reluctant DBAs faced with… (read more)