We've been running with OrientDB for a very long time now, and have deployed many software packages including it. We love the interface, and have written our own C++ library to talk to the server over the remote mode (Network Binary Protocol). We've invested a lot of time in it, and have found and reported quite a number of bugs over the years.
However, the database itself seems to be extremely brittle. I cannot count the number of times I have had to respond to service calls because the database was broken. In almost every case, the database was broken beyond repair, causing total data loss. In no case was this due to the use of the database - all use was through the given APIs, Select, Traverse, Record Load, and Transactions. We were hoping that the plocal / WAL upgrades would solve these problems, but they haven't. The current situation is untenable for us, as we're trying to ramp up our deployment of these software packages. Unfortunately, we have not discovered a trigger to the problems, which has made futile our attempts at determining where the problem lies. Sometimes it seems like the problems have been around power failures, but other times it just happens while in the course of normal operation / running. We've seen: - Record broken errors - Corrupt literal length - Serialization errors when reading a record - Can not restore 1 WAL master record for storage - Where the unique index becomes out-of-sync with the cluster, so items containing the same value are inserted, so a rebuild of the index fails, after which the database continues to accept new inserts of records with values already in the index - When a single record is broken, it shuts down queries across the entire cluster, eliminating access to any other data. Unfortunately, we can't send broken databases because of proprietary customer data and privacy concerns. I can't believe that our use case (think a 'forest' of tree hierarchies that change with some frequency), where we commit trees through transactions, and have several not unique and one unique index, is out of the norm. The database storage should be durable, the index should always be in sync with it, and data loss is just plain unacceptable. We would much prefer to fix the problems rather than try to find another solution (or even develop our own if we have to), but without a good way to reproduce the myriad of failure modes we've seen, we don't know how to report them to you in a way that you'll be able to do something about. I'd like to give my full recommendation to OrientDB, but can't. I would steer any current developers away from it. Durability, above all other considerations, should be the rule. A database must be bulletproof. Please, I'm begging you for suggestions on where to go from here. We really don't want to remove OrientDB from our products, but given the current direction, there really doesn't seem to be much choice. Thank you for your attention. Steven Tomer -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
