On Wed, Sep 15, 2010 at 10:05:00PM -0400, Tom Lane wrote:
> Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:
> > On 16/09/10 13:22, Tom Lane wrote:
> >> What exactly do those get you that an ordinary index, or at worst an
> >> index-organized table, doesn't get you?
>
> > It is pretty rare to see key value stores vs relational engines
> > discussed without a descent into total foolishiness, but this Wikipedia
> > page looks like a reasonable summary:
> > http://en.wikipedia.org/wiki/NoSQL
>
> That doesn't do anything at all to answer my question. I don't want
> to debate NoSQL versus traditional RDBMS here. What I asked was:
> given that PG is a traditional RDBMS, what exactly are you hoping
> to accomplish by putting a key-value storage mechanism in it? And
> if you did, how would that be different from an index-organized table?
One thing it would get is integration with existing infrastructure that
makes up many critical apps. Many horizontal apps use things like memcached
or redis to provide a distributed data layer for developing their applications.
Sometimes that becomes the middle layer for an enterprise. Being able to hook
into that middle layer is very handy. Shared login or session information is
a good example of data that one might want put in a KVS. Also, many enterprises
are full of different departments, orgs, teams, systems, etc ... KVS are simple
and limited enough they might make a good choice for standardizing on how to share
data in some places.
Isn't this what SQL/Med is about?
Garick
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
