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
