On Aug 10, 2011, at 5:22 PM, John Sanda wrote:
Several thoughts....
First, that quote strikes me as misinformed. The "old school" database
be it oracle or (preferably) postgresql is perfectly capable of handling
large amounts of data with great performance.
I think the particular phrasing could have been better but there's a reason
non-relational databases are gaining popularity.
Relational databases can handle large amounts of data and remain performant assuming the
affordance to a row/value model is high. But consider time-series data, network graphs,
structured documents, binary content, etc… Those don't fit into a relational model
without a lot of twisting and you end up jumping through hoops trying to use a hammer to
put in a screw. It may fit after a great amount of struggle, but it's not going to be
pretty or as strong as if you'd just used a screwdriver.
My favorite analogy is the car and garage. Normalizing data is like taking your car apart
every night once it's in the garage and putting it back together when you leave.
It's a waste unless you need to do something like inventory all the parts every
night.
Secondly, as for other solutions like some of the ones mentioned, you
can very easily wind up with lousy performance, maybe even more so than
with a RDBMS. Some of these not so old school technologies are designed
to address specific problem spaces and are not nearly as general purpose
as a RDBMS.
This is exactly right and why it's important to look at what the databases is intended
to do. Time-series data is easier to manage, with less overhead in a non-relational
database. When push comes to shove someone can probably lose several hours worth of
performance metrics if a server goes down or disk dies, but I don't think that's
the case with inventory. i.e. with inventory you can still configure machines, watch for
availability changes, deploy apps, etc...
Third, if people want to manage an environment twice their current
size,
I think it is an oversimplification to simply say add more machines. It
is not an easy problem to solve, and in fact if we already have a good
solution here, I am aware of it.
I assume you left a word. But - even if you look inside JBoss you'll see that
infinispan does let you just add nodes (on the same machine or another) without impact to
the code, though it may require configuration.
The key thing to take away though is that
a flexible infrastructure is being put in place that allows users to
plug in different back ends with different performance and scalability
characteristics.
The unstated trade-off is what? manageability? Otherwise why not just go with only the
most performant, scalable option?
Alan Santos
JBoss Product Manager
617.818.7735
alan.santos(a)redhat.com