On Wed, Oct 16, 2013 at 10:30 AM, CS DBA <cs_dba@consistentstate.com> 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
