Folks;
in the process of evaluating alternatives to SQL/RDBMS solutions, I
seem to have ended up with CouchDB for a little longer, seeing that its
document centric approach does rather well reflect our data model
understanding in our current system, way better than the relational
approach we are using so far. This is, generally, what makes things
interesting to us, whereas features like replication aren' of that much
interest.
There are, however, two considerable questions before moving any
further, related to the amount and style of how data need to be stored
inside the db:
- In our environment, at the moment we have to handle something next to
2TB, consisting of both document metadata (at the moment stored in
the RDBMS) and binary file data (at the moment stored inside a
centralized file system provided by our application). This amount is
supposed to at the very least be doubled in the course of the next
two years, especially concerning file data. I have seen a pretty good
way of how CouchDB does deal with file data (the attachments approach
is exactly what we want/need), but I wonder whether there are any
limitations regarding the amount of (binary) data stored inside a
CouchDB database?
- Our current infrastructure runs atop NetApp filers, replicating
themselves between a production site (active) and a backup site
(passive). The production site filer so far is the only place for
storing data in our environment, and it is supposed to be exactly
like this in near future, so in terms of CouchDB it would be required
to have at least the database "files" hosted inside a NetApp CIFS
share. Does CouchDB support / allow for such a setup?
Both issues, in the end, also could be addressed using a "mixed mode"
solution I guess, keeping metadata inside the CouchDB and hosting files
on the CIFS share as we do by now, but I surely would prefer having all
the data in one place...
Thoughts, anyone?
Thanks in advance and all the best,
Kristian
|