Live data from Hacker News

PostgreSQL as Schemaless Database [pdf]

wiki.postgresql.org

51–60 of 90 posts

Re: PostgreSQL as Schemaless Database [pdf]

#51
post #17

Earlier quoted context omitted.

Don't remember exactly when, probably is was in time when multicore hosting servers becomes relatively cheap. We made measurement MySQL vs PostgreSQL and surpisely found that PG is visible faster. Don't remember exactly numbers. So even if team never push server as supa-pupa-fast on the market they was neat choice for people who know. But the same time, even if PG documentation can be used as textbook for RDB theory…

Right, so MongoDB goes back to my pet theory about how reward schedules shape technology selection. It takes very little upfront to get data into or out of a MongoDB instance. Import the relevant module, name the server, persist. Blam, done, no need to worry about how to map an object model to a relational model or vice versa. Here kid, have a dopamine hit. Meanwhile, a relational database imposes a schema on you upf…

I think you missed a word. "Strict systems punish you now to prevent POTENTIAL future punishment". and that makes a big difference.

Re: PostgreSQL as Schemaless Database [pdf]

#52

Earlier quoted context omitted.

Yes, but why bother? There are already so many good SQL clients out there, like SQLAlchemy.

there are many apps built around mongodb that it would be interesting to do a drop-in swap with postgres (assuming protocol compatibility). hell, ill personally pay a lot to have a mysql compliant interface just for WordPress!

I see, that motivation makes more sense to me :-)

I guess it should be possible to write a wrapper that executed at isolation level "single".

Re: PostgreSQL as Schemaless Database [pdf]

#53

Earlier quoted context omitted.

Depends what you mean by "NoSQL". MongoDB is pretty terrible overall, so don't even bother. Systems like Dynamo/Riak/Cassandra sacrifice consistency (most of the time) for performance, largely because a distributed setup (sharding in particular) is easier when you don't guarantee consistency. Note that none of them sacrifice durability. It is possible to have a distributed and consistent database, but you either have…

Thanks for your reply. But I have one more question, if I need to manage bank account, then the database must be consistent. Lets say that I just need to keep balance and social security number for the account, and only need to query the balance. Can No-SQL like redis have better performance than relational database? (assume same on logs and transactions).

Redis is consistent, it's just less durable than Postgres. A query cache is a very good usage for it. It's also likely to be faster than Postgres for the simple operations it is capable of.

The only downside is that (for now at least) it is single node, with optional replica slave(s).

Re: PostgreSQL as Schemaless Database [pdf]

#54

Earlier quoted context omitted.

Hot Standby in postgres is pretty damn good for replication (like you said making failover occur properly takes a little bit of effort but its not too hard). Also pgpool2 helps a lot with partitioning and parallel queries. For a relational db, postgres does a pretty good job at distribution and fault tolerance.

Postgres won't let you perform any sufficiently long (read-only) queries on slaves. For example, I was unable to run pg_dumpall on a slave to have DB snapshots. This is [well-explained]( http://www.postgresql.org/message-id/201102272005.00234.jens... ), but still inconvenient. This way, slaves are only useful for failover and possibly offloading very short read-only transactions, which is pretty limited.

This used to be the case, but it's not anymore. You can run long-living queries, run pg_dump, etc on slaves.

Re: PostgreSQL as Schemaless Database [pdf]

#55
post #18
post #9

Earlier quoted context omitted.

Do you have any thoughts on expression indexes? Assumed I would have to pull out fields from the document to index reasonably on pgsql, but this presentation at least shows that simple expression indexes perform well. I wonder about compound, nested, etc.

I'm not too familiar with the current schema, but I do know we make extensive use of partial indexes ( WHERE (vnnk IS NOT NULL) , WHERE (fhs > 0) etc...) and compound indexes in btree. In GIN, for example, this isn't possible, but GIN itself works reasonably well for partial matches (since it's also btree) so it's not too much of a deal. We use a combination of hstore, GIN, conventional fields and multiple indexes wi…

In addition to this, we have found that the JSON field - PLV8 - JavaScript user-defined function - function-based index combination to work and perform really well. As the parent said, is not as fast as a full relational schematic but it's entirely acceptable. We try to stick to relational where speed and/or referential integrity is crucial and just use JSON fields for everything else.

Re: PostgreSQL as Schemaless Database [pdf]

#59
post #44

Earlier quoted context omitted.

PostgreSQL hasn't spent 18 years pitching itself as a pure performance play, though. It started as a research project into the object-relational model and was adapted to be a safe and featuresome database first and performant second. Mongo's performance will converge downwards as people demand more features and safety guarantees. If however you want the original premise -- memory-only, schemaless, auto-sharded docume…

"1. overestimate the size of your data, (especially since relational models by design squeeze out all duplicated statements of data)" Of course, this is opt-in in a SQL world, more's the pity. I've seen some nightmarish ActiveRecord spawned Postgres monstrosities. I wonder how much of the attraction of schema-less DBs comes from the lack of friction between the largely guarantee-free idea of data storage precipitated…

Here's a question for people who prefer to put their guarantees (i.e. unique/check constraints, foreign keys etc) in their database. How do you present these constraints to the user? How do you show when they've been violated? Just present them with the PG error message? Maintain a mapping of PG errors to more domain specific messages? Bite the bullet and just code them twice (once for the DB, and once for the user)?

Re: PostgreSQL as Schemaless Database [pdf]

#60

Earlier quoted context omitted.

Postgres won't let you perform any sufficiently long (read-only) queries on slaves. For example, I was unable to run pg_dumpall on a slave to have DB snapshots. This is [well-explained]( http://www.postgresql.org/message-id/201102272005.00234.jens... ), but still inconvenient. This way, slaves are only useful for failover and possibly offloading very short read-only transactions, which is pretty limited.

This used to be the case, but it's not anymore. You can run long-living queries, run pg_dump, etc on slaves.

Do you have a reference in which pg version this got fixed? We still pg_xlog_replay_pause() our slaves, it would be nice to drop that.
Post reply on HN