Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The key value store we ignored (Postgresql)

blog.creapptives.com

Post reply on HN
Print view View original

1–10 of 65 posts

Re: The key value store we ignored (Postgresql)

#2

Post by sqrt17 »

In my opinion, Postgresql + hstore + PLv8js (Javascript as a language for stored procedures, see http://code.google.com/p/plv8js/) could really rock the world if it became an accepted standard and got some people behind it.

It's not so great if you start using something and one year later see that the original authors lost interest and move on, leaving you with 10k lines of code that depend on a pray-for-no-bugs unsupported piece of software.

Re: The key value store we ignored (Postgresql)

#6

Post by henrikschroder »

The main selling point of the various NoSQL products out there today isn't the schemaless storage, instead it's the ability to grow beyond a single server that's compelling.

228MB of data is nothing, it fits in RAM of any machine. What would the examples in this blog post look like if it was 228GB of data spread across 10 servers instead? How would you grow/shrink such a cluster? How would you perform a query that cuts across servers and aggregates data from some of them? How would you replicate data across multiple servers?

Re: The key value store we ignored (Postgresql)

#8

Post by maxpert »

henrikschroder wrote: post #6

The main selling point of the various NoSQL products out there today isn't the schemaless storage, instead it's the ability to grow beyond a single server that's compelling. 228MB of data is nothing, it fits in RAM of any machine. What would the examples in this blog post look like if it was 228GB of data spread across 10 servers instead? How would you grow/shrink such a cluster? How would you perform a query that cu…

I think for schema-less storage systems we know 2 major competitors in market. MongoDB and CouchDB. - CouchDB by default has not ability to scale out except master master replication, solution? Sharding for distribution and Replication for reliability. Or you BigCouch with prayers that it won't trash out your data. - MongoDB is know to stand on its Sharding server mongos and you have to issue sharding commands whenever you scaleout and rebalance. So its again Sharding for distribution and Replication for reliability! - Postgres -> Reliable in storage than both if you do same Sharding and Replication yourself :).

I am in no way substituting or saying 228MB is enough data! I would rather hate MongoDB for being RAM hungry and storing same 115k tweets in Gigabytes of memory (256MB is just like a started of 100 Course meal for MongoDB). Again Facebook ultimately prefers his data to go to MySQL and they have largest 600 shard for a reason!

Re: The key value store we ignored (Postgresql)

#9

Post by jashkenas »

chrismealy wrote: post #3

Anybody using this with rails? https://github.com/softa/activerecord-postgres-hstore

Yes -- but not with that module. We're using it to tag documents (individual rows in Postgres and Solr) with user-defined metadata.

http://blog.documentcloud.org/blog/2011/05/arbitrary-metadat...

... which can then be used to power custom indexes of particular collections of documents, like this one:

http://www.nytimes.com/interactive/2011/12/02/us/oil-and-gas...

The fun bit being, that in both Postgres and Solr, you can still run a precise search (including joins for access control, sharing, and boolean full text clauses) with a single query because the HStore keys and values are indexed.

Post reply on HN