Anybody using this with rails? https://github.com/softa/activerecord-postgres-hstore
I built this gem for ActiveRecord hstore serialization. Uses ActiveRecord 3.1+ custom serializer hooks.
The key value store we ignored (Postgresql)
41–50 of 65 posts
Re: The key value store we ignored (Postgresql)
#42@chrismealy.. http://croak.eu/rTBVKX
Quit spamming this bullshit here. HN is a text-based discussion forum.
Re: The key value store we ignored (Postgresql)
#43The 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…
The trick is, you wouldn't necessarily. If your workload can be handled with one beefed-up lots-of-RAM-and-solid-state-drives server, you could spend your money on two of these instead of having 10 smaller servers, and be perfectly happy with it. I don't care about what sells NoSQL products to enterprise users - there are lots of workloads where the data fits in RAM (for some reasonable quantity of RAM that money can…
Each database worth its salt will use as much memory as you allow it to use in order to avoid physical IO.
Your point is valid of course. I just wanted to point it out for people that think each action in a RDBMS results in a costly IO operation.
Re: The key value store we ignored (Postgresql)
#44Earlier quoted context omitted.
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 You bring up an interesting point. At what data size do the companies using the various NoSQL DBs feel they have to move beyond a traditional RDBMS? I work with some traditional RDBMS stores now that are >500GB in size with tables that add 20M-30M rows/month and querying still isn't an issue. A…
I can sustain this claim. I work with a system implemented almost entirely in Oracle PL/SQL. Some tables in the system are nearing 800-900 columns, their size often exceeds 600 GB per table (not many of such large tables though). Querying isn't a problem at all. Large schema changes are also mostly painless. The only point at which one has to be really careful is when a schema change requires actual calculations base…
A lot of criticisms I read about the immutable limits of RDBMSes turn out, upon closer inspection, to be criticisms of MySQL. Oracle sort of sails past these limitations like a superliner: expensively and gracefully.
Not that I particularly like Oracle as a programmer. I have to check my calendar every time I hit the 32-character limit for names or once again have to write
some_field_expressing_truth varchar2(1);
constraint "y_or_n" check some_field_expressing_truth in ('Y','N');
Re: The key value store we ignored (Postgresql)
#45Earlier quoted context omitted.
I can sustain this claim. I work with a system implemented almost entirely in Oracle PL/SQL. Some tables in the system are nearing 800-900 columns, their size often exceeds 600 GB per table (not many of such large tables though). Querying isn't a problem at all. Large schema changes are also mostly painless. The only point at which one has to be really careful is when a schema change requires actual calculations base…
A lot of criticisms I read about the immutable limits of RDBMSes turn out, upon closer inspection, to be criticisms of MySQL. Oracle sort of sails past these limitations like a superliner: expensively and gracefully. Not that I particularly like Oracle as a programmer. I have to check my calendar every time I hit the 32-character limit for names or once again have to write some_field_expressing_truth varchar2(1); con…
Well PostgreSQL does scale to millions of simple read-only transactions per minute, at least in some benchmarks. And in PostgreSQL 9.2 it will scale much better, in the synthetic benchmark it reached about 13 million per minute at high concurrency (compared to about 2.5 million for 9.1).
http://rhaas.blogspot.com/2011/09/scalability-in-graphical-f...
Re: The key value store we ignored (Postgresql)
#46I agree with the author that hstore is very interesting, but the data structures are not the key selling point in the NoSQL space in my opinion. The most overlooked advantage to things like Cassandra and Riak are the fact that you have no single point of failure in the system. If an individual node fails, there is no operational impact. Postgres does have (finally!) a nice replication story, so you have data protecti…
Agreed, but of course the massive write parallelism and fault tolerance of DBMS like Cassandra comes at the cost of dropping ACID, which may cause a lot of complexity elsewhere in the system. It also comes at the cost of limiting the types of queries you can perform without resorting to procedural code (at least in the case of column family based architectures). In other words, it comes at the cost of productivity. S…
Codd emphasised the relational model as being able to change the underlying storage representation without breaking apps.
Will this eventually be a problem for NoSQL? Or, is the scalability worth the sacrifice?
Or, does NoSQL typically have only one (main) app, so making it work with a specific storage representation is not a big deal? The relational use-case was many different apps, with different versions, needing different access paths to the data. But if you just have one known set of access paths (like a REST URI), you can just design the DB for that. Hierarchical databases worked well when just one DB, one app; they just weren't very flexible.
Hierarchical databases are fast and simple but inflexible as the relationship is restricted to one-to-many, only allowing for one parent segment per child. http://it.toolbox.com/wiki/index.php/Hierarchical_Database
Re: The key value store we ignored (Postgresql)
#47> ...database grew to a size of 239691780 bytes (Just 228MB) > ...gives me 14689 rows just under 360ms on average Uh, 360ms seems like an awfully long time to query such a small dataset.
I think that includes the time to transfer the data.
Re: The key value store we ignored (Postgresql)
#48Earlier quoted context omitted.
A lot of criticisms I read about the immutable limits of RDBMSes turn out, upon closer inspection, to be criticisms of MySQL. Oracle sort of sails past these limitations like a superliner: expensively and gracefully. Not that I particularly like Oracle as a programmer. I have to check my calendar every time I hit the 32-character limit for names or once again have to write some_field_expressing_truth varchar2(1); con…
Well PostgreSQL does scale to millions of simple read-only transactions per minute, at least in some benchmarks. And in PostgreSQL 9.2 it will scale much better, in the synthetic benchmark it reached about 13 million per minute at high concurrency (compared to about 2.5 million for 9.1). http://rhaas.blogspot.com/2011/09/scalability-in-graphical-f...
Hence "not yet".
It's been amazing watching the performance surge in postgres these past few years. I wonder if Red Hat or similar will try sponsoring a tilt at the TPC-C crown in future.
Re: The key value store we ignored (Postgresql)
#49The 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…
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.
That's just not true. Some NoSQL products (HDFS, Cassandra etc) sell on the ability to easily scale out. Other (CouchDB, MongoDB etc) focus on other features. CouchDB (for example) doesn't have a real scale-out story at all (beyond "manually shard your data", or try http://tilgovi.github.com/couchdb-lounge/), but that isn't really a problem because it has other features that sell themselves.
Re: The key value store we ignored (Postgresql)
#50Earlier quoted context omitted.
Well PostgreSQL does scale to millions of simple read-only transactions per minute, at least in some benchmarks. And in PostgreSQL 9.2 it will scale much better, in the synthetic benchmark it reached about 13 million per minute at high concurrency (compared to about 2.5 million for 9.1). http://rhaas.blogspot.com/2011/09/scalability-in-graphical-f...
Hence "not yet". It's been amazing watching the performance surge in postgres these past few years. I wonder if Red Hat or similar will try sponsoring a tilt at the TPC-C crown in future.
Back before Sun bought MySQL they started doing a lot of performance work on Postgres. They didn't go after TPC, but they did show it was only(?) 12% slower than Oracle for SpecjAppServer: http://www.informationweek.com/news/201001901