On Wed, Oct 16, 2013 at 10:30 AM, CS DBA <cs_dba@xxxxxxxxxxxxxxxxxxx> wrote: > All; > > One of our clients is talking about moving to Mongo for their reporting/data > mart. I suspect the real issue is the architecture of their data mart > schema, however I don't want to start pushing back if I can't back it up. > > Anyone have any thoughts on why we would / would not use Mongo for a > reporting environment. > > what are the use cases where mongo is a good fit? > what are the drawbacks long term? > is mongo a persistent db or simply a big memory cache? > does mongo have advantages over Postgres hstore? > etc... Couple random thoughts: *) I think the real feature to be looking at is postgres json improvements. One of the reasons people migrate off relational technology difficulty with mapping data to client side structures. JSON is doing what xml failed to do: provide a standard way of doing that. Postgres sql+json features allow this to be done in query itself which is a huge simplification vs standard techniques although it will require above average SQL skills to do it right. *) All databases are 'in memory' databases essentially. The real trade off is what consistency guarantees you give up in order to to get faster writing and/or multi-master replication. My understanding of mongo is that you give up a lot. This puts a lot of effort on the programmer to manage data conflicts that SQL basically does for you. That might be a good tradeoff in some cases. *) Moving away from relational technology has a lot of hidden costs that are hard to see until you finish the project. In my experience, exotic backends tend to be correlated with project problems or even failure. But really what we need to know is what is prompting your client to make the move. The rebuttal argument (should it be necessary to make one) will depend a lot on what the reasoning is. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
