CouchDB scenario - steering advise please

[pete huerter <pe...@gmail.com>]

Hi All,

I am new here, and am writing to ask your advise on whether CouchDB is a
good fit for my needs. (*)  Thanks in advance for considering my case below.

I want to create a web-site where survivors of childhood abuse can come and
share with other survivors what has helped them recover and lead gainful
happy lives. (+)

In terms of scalability I am hoping a few hundred people would contribute,
possibly later into the thousands - simultaneously... hopefully that is.

This is all totally non-profit.  I have a technical background but in
compilers and debuggers to this area is pretty new to me.  If you are short
of time don't hold back I will pick through your response and figure it out.

The plan:

I am exploring the use of the CONCEPT MAP as the user interface.  By using
a concept map I hope to boil away most of the language issues and just get
to nouns (NODES) and pronouns, connectors, verbs (EDGES).  It needs to be
simple and easy to use.  I am not married to the concept map idea but I see
no other way of aggregating the experiences of many people in an intuitive
visualization that is easy for others to contribute to.

So imagine a DIRECTED GRAPH with nouns as nodes and pronouns,connectors,
verbs as edges.  I spent months wrestling with the semantics and I have
concluded that it should really stop thinking about it :)  The starter node
for everyone would be "I".  A node-edge-node would be "I"-"am
a"-"survivor". "survivor" could be refined to a particular form of abuse
(e.g. "i-am a-survivor-of-childhood xxxx abuse", and so on...  Each (new)
user would follow along in the graph adding his/her membership to each path
that is applicable to him her by clicking on that path (like breadcrumbs) -
but when that path no longer describes his/her personal experience they
could add their own sub graph to refine it to match their experience.  This
sub-graph would then be visible to all participants, who could in turn join
or refine as needed.  The system must remember what members belong to each
node and edge, also who pioneered that edge and likely other logging info.

So the graph mirrors consensus.  The goal is a graph that can be appended
and queried by many people at once.  The experience I am going for is "you
are not alone, and this is what has helped me in my particular case", and
"full recovery is possible".


My plan is to use D3.js to visualize the thing and I am wondering if a
CouchDB backend would work for me??  It needs to be simple otherwise I
probably will not get it done :)

Back to the idea of using a document store:

So I imagine a big document where nodes and edges are sub-documents.  Each
sub-document is itself a node/edge and records the membership and other
info in it.  So each sub-document would be updated with membership each
time a survivor clicks to "join" that node/sub-path, each document would
also be updated with new edges/nodes spanning from it.  A many-to-many
situation.  This is the data-intensive part.  The eventually consistent
aspect of CouchDB seems a good fit here as collisions will be common.

Later there may need to be features like editing node/edge data but not
initially.

Does CouchDB allow for many users to append to a document with reasonable
responsiveness?  Is there an append mode or something?

After filling 13 note books about how to make this fast and eliminate data
redundancy I am going back to what one of my profs said 15 years ago now:
"first make it work, then make it fast".  Actually the user interface may
be a complete flop so I need to work on that before worrying about
scalability.

As I approach this project again after shelving it I am hopeful there are
some users who are understanding and knowledgeable who can take a min or
two to help steer me in any way they think may help.

Sincerely,
Pete.

(*)  A minute of your expert time would be greatly appreciated as in the
past I have learned that one email can often fend off weeks of unnecessary
work :)  Actually I have already gone around in circles for a few months so
this is me doing what I should have done months ago :)

(+) Of course this can be generalized, but I am using this domain as a
proof of concept.

Re: CouchDB scenario - steering advise please

[Luca Morandini <lm...@ieee.org>]

On 09/01/14 04:21, pete huerter wrote:
> Hi All,
>
> I am new here, and am writing to ask your advise on whether CouchDB is a
> good fit for my needs. (*)  Thanks in advance for considering my case below.
...
> As I approach this project again after shelving it I am hopeful there are
> some users who are understanding and knowledgeable who can take a min or
> two to help steer me in any way they think may help.

As I understand, you plan to have a single document, which would probably end up 
being unwieldy: why not to break it up into constituent sub-documents (nodes and 
edges) ?

However, I have some experience in storing graphs in CouchDB as a collections of 
nodes and edges documents (with Views to query them), but it ended up not a pretty 
sight: have you already looked into a proper graph database (like Neo4J) as 
persistence mechanism ?

You may also be interested in RDF data stores (OpenRDF ?).

Regards,

Luca Morandini
Data Architect - AURIN project
Melbourne eResearch Group
Department of Computing and Information Systems
University of Melbourne
Tel. +61 03 903 58 380
Skype: lmorandini