Hey Steven, We're here to help you. First question: what version are you using? Have you upgraded OrientDB following all the enhancement on durability?
Lvc@ On 12 June 2014 19:22, StevenTomer <[email protected]> wrote: > 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. > -- --- 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.
