postgresql versus riak for a global exchange

On Mon, 5 Jan 2015 11:37:37 -0500
xu xiut <xiut.xu@gmail.com> wrote:

Hello, I am looking at creating a toy project which may turn into an actual
business if I'm lucky, the ideal is generally just an exchange for people
to trade some type of asset.

I'm looking at using either PostgreSQL or Riak, and I'm wondering if there
are opinions and suggestions that someone would be willing to share with me
when evaluating databases.

This is the first time I've actually considered something besides
PostgreSQL. Riak 2.0 now offers strong consistency and I really respect the
community and the work that has gone into the project. It seems like it
would be easy to replicate across multiple data centers.

The big difference between an RDBMS like Postgres and a document store like
Riak is data consistency. I'm talking about something completely different
than the "strong consistency" promise they are now making.

It's very easy to explain: Can you make foriegn keys in Riak? Check
constraints? Data type constraints (such as ensuring that a particular value
is a valid date)? PostgreSQL allows you to do all of these, and a properly
designed RDBMS will ensure that your data is always valid ... i.e. no orphaned
child records, or invalid dates, or negative numbers where there shouldn't be,
etc.

With Riak (or any other document store system I'm familiar with) the onus is
on the programmers to ensure this. It's certainly possible to write data
validation in the program logic to keep the data clean, but it's a lot more
work than doing it in the database. Furthermore, in my experience, software
developers don't do a good job of it -- but that's dependent on your software
team and the QA practices you enforce.

Summary: if data quality is important, PostgreSQL is probably the right choice.
If you are OK with some poor quality data, and really need the features of
Riak, then go that route.

--
Bill Moran
I need your help to succeed:
http://gamesbybill.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 1/5/2015 10:37 AM, xu xiut wrote:

Hello, I am looking at creating a toy project which may turn into an
actual business if I'm lucky, the ideal is generally just an exchange
for people to trade some type of asset.

I'm looking at using either PostgreSQL or Riak, and I'm wondering if
there are opinions and suggestions that someone would be willing to
share with me when evaluating databases.

This is the first time I've actually considered something besides
PostgreSQL. Riak 2.0 now offers strong consistency and I really respect
the community and the work that has gone into the project. It seems like
it would be easy to replicate across multiple data centers.

Thanks for letting me ask this here!

Never used Riak, no idea. BUT it would be awesome if you did it in both
and could post a comparison. It would be neat to see plus/minus lists
for the db's.

Your question is pretty light on details: "Trade some type of asset".

I'd be curious to see your layouts for both systems. Also the query
types you think you'll need. (One spot Riak might have a problem is
eventual consistency. If you only have 1 more foo, and two people post
buy requests, will Riak sell more than one?)

Riak seems to support distribution, replication, fail over, scale out,
etc. In the sense that Riak is using those words, PG doesn't have all
that stuff.

-Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

I’m familiar with both PostgreSQL and Riak (1.4, not 2.0).
I know that Riak 2.0 now offers strong consistency. Have not yet seen what that does to performance.
Big plusses for PostgreSQL:
- you can do both relational and NOSQL tasks (the Binary JSON in the latest PostgreSQL).
- well-tested consistency, ACID, etc.
- lots of adapters and support.
- big community

Big plusses for Riak:
- multi-master replication
- multi-data center replication
- easy to scale up

We use PostgreSQL in combination with Riak for data storage (we have a tokenization service).
We're currently using the EnterpriseDB multi-master PostgreSQL replication and are quite happy with it.
The replication runs periodically, not streaming, so there is at least a 1 second delay for replication to occur.
Riak replicates quicker — but then you don’t have the strong relational structure on top.

As mentioned earlier, ‘exchange…trade…asset’ is a bit vague.
In addition to just storing things, you’ll need to keep track of all sorts of log-in and contact info — perhaps not ideal for Riak.
Probably best to consider precisely what traits your planned application has and then look to match against the database storage.
May even end up with a mix of the two just as we have.

Your decision may also depend on which development language/framework you chose for the implementation.

—Ray

On Jan 5, 2015, at 11:37 AM, xu xiut <xiut.xu@gmail.com> wrote:

Hello, I am looking at creating a toy project which may turn into an actual business if I'm lucky, the ideal is generally just an exchange for people to trade some type of asset.

I'm looking at using either PostgreSQL or Riak, and I'm wondering if there are opinions and suggestions that someone would be willing to share with me when evaluating databases.

This is the first time I've actually considered something besides PostgreSQL. Riak 2.0 now offers strong consistency and I really respect the community and the work that has gone into the project. It seems like it would be easy to replicate across multiple data centers.

Thanks for letting me ask this here!

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

I’m familiar with both PostgreSQL and Riak (1.4, not 2.0).
I know that Riak 2.0 now offers strong consistency. Have not yet seen what that does to performance.
Big plusses for PostgreSQL:
- you can do both relational and NOSQL tasks (the Binary JSON in the latest PostgreSQL).
- well-tested consistency, ACID, etc.
- lots of adapters and support.
- big community

Big plusses for Riak:
- multi-master replication
- multi-data center replication
- easy to scale up

We use PostgreSQL in combination with Riak for data storage (we have a tokenization service).
We're currently using the EnterpriseDB multi-master PostgreSQL replication and are quite happy with it.
The replication runs periodically, not streaming, so there is at least a 1 second delay for replication to occur.
Riak replicates quicker — but then you don’t have the strong relational structure on top.

As mentioned earlier, ‘exchange…trade…asset’ is a bit vague.
In addition to just storing things, you’ll need to keep track of all sorts of log-in and contact info — perhaps not ideal for Riak.
Probably best to consider precisely what traits your planned application has and then look to match against the database storage.
May even end up with a mix of the two just as we have.

Your decision may also depend on which development language/framework you chose for the implementation.

—Ray

On Jan 5, 2015, at 11:37 AM, xu xiut <xiut.xu@gmail.com> wrote:

Hello, I am looking at creating a toy project which may turn into an actual business if I'm lucky, the ideal is generally just an exchange for people to trade some type of asset.

I'm looking at using either PostgreSQL or Riak, and I'm wondering if there are opinions and suggestions that someone would be willing to share with me when evaluating databases.

This is the first time I've actually considered something besides PostgreSQL. Riak 2.0 now offers strong consistency and I really respect the community and the work that has gone into the project. It seems like it would be easy to replicate across multiple data centers.

Thanks for letting me ask this here!

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

A very popular design I see is often this:

- PostgreSQL for account, inventory, transactional; and all writes
- NoSQL (Redis, Riak, Mongo, etc) for read-only index postgres (almost like a read-through cache) and assembled documents

On Jan 5, 2015, at 5:46 PM, Raymond Cote wrote:

I’m familiar with both PostgreSQL and Riak (1.4, not 2.0).
I know that Riak 2.0 now offers strong consistency. Have not yet seen what that does to performance.
Big plusses for PostgreSQL:
- you can do both relational and NOSQL tasks (the Binary JSON in the latest PostgreSQL).
- well-tested consistency, ACID, etc.
- lots of adapters and support.
- big community

Big plusses for Riak:
- multi-master replication
- multi-data center replication
- easy to scale up

We use PostgreSQL in combination with Riak for data storage (we have a tokenization service).
We're currently using the EnterpriseDB multi-master PostgreSQL replication and are quite happy with it.
The replication runs periodically, not streaming, so there is at least a 1 second delay for replication to occur.
Riak replicates quicker — but then you don’t have the strong relational structure on top.

As mentioned earlier, ‘exchange…trade…asset’ is a bit vague.
In addition to just storing things, you’ll need to keep track of all sorts of log-in and contact info — perhaps not ideal for Riak.
Probably best to consider precisely what traits your planned application has and then look to match against the database storage.
May even end up with a mix of the two just as we have.

Your decision may also depend on which development language/framework you chose for the implementation.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Hi Jonathan,
I'm really interested in the type of hybrid architecture you've mentioned.
How is the read-only index constructed in the design you're mentioning?
It'd be much appreciated if you could briefly describe the order of
writes/reads given postgres and non-postgres components of the
architecture. Another popular approach is to use Lucene for fast but not
necessarily real time indexing, similar to what you're describing but I'm
curious about the designs you've sene.

Best regards

On Tue, Jan 6, 2015 at 5:07 PM, Jonathan Vanasco <postgres@2xlp.com> wrote: