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:
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.