
OrientDB? - reconstrukt
Any advice from folks who have deployed OrientDB alongside MongoDB for networked document search?
======
anonwarnings
OrientDB is snakeoil and anyone deploying it has not done their due diligence.
The real world performance is very different to their claims and many features
just don't work. Do yourself a favor and read through their bug tracker some
time, you'll be scared.

~~~
lvca
An account created 3 hours ago with just this comment? Smell like a troll.

~~~
anonwarnings
Not trolling, but for various reasons I don't want my employer linking these
comments to my real account.

We spent a lot of time and money trying to get OrientDB working and we ran
into so many problems that it was impossible for us to continue with it. It is
buggy beyond belief, distributed mode is deeply flawed, transactions are not
transactional, it's super easy to hang the database and the explain keyword
straight up lies, the backup strategy is non-existent, the documentation
incredibly poor and riddled with typos and outright mistakes. When we finally
thought we'd got over these issues, we imported our data and the system ground
to a halt, just weeks before a major product launch.

Luckily we were able to move to Postgres pretty quickly, but choosing OrientDB
nearly sank the company, choosing it was an inaffordable mistake.

Also, look at this list of issues closed as "invalid/wontfix", it seems like
you're a lot keener to close issues than to actually fix them -
[https://github.com/orientechnologies/orientdb/issues?utf8=%E...](https://github.com/orientechnologies/orientdb/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Ainvalid)

~~~
lvca
Your angry comments remain anonymous. I'd like to know more about your
experience and why it has been a so big failure, if this is really true.

Also generic comments like "backup strategy is not existent" when OrientDB
supports backup/restore and export/import let me think you want just trolling
this topic. Seriously, if you had a real bad experience on using OrientDB,
please let us know by motivating all the statements above. Just drop an email
to info at the company web site. Thanks.

~~~
anonwarnings
I think you already know about this situation because the CTO was in contact
with you about it. And it's not really anger, more disappointment.

About backups - OrientDB does not backup indexes, it recreates them on restore
- but creating indexes is the most expensive operation! For us it meant an
unacceptable level of downtime during a restore.

The impression I got when I was working with OrientDB is that you focus a lot
on features, and OrientDB definitely has a lot of them. So anyone that does a
naive point by point comparison with other products will naturally be blown
away by OrientDB. But many of these features are not well thought out, or are
broken in obvious or subtle ways - e.g. you support Lucene for full text
search but it's unusable for anything but the most simple use case.

It takes a lot of development time before it becomes apparent just how broken
the product is, and that is the problem - if it'd let us down in the first few
weeks I wouldn't be writing this. Instead we encountered a constant stream of
strange bugs and edge cases, and to be fair to you, you fixed a lot of these
problems quickly, but we'd always find new ones, and it became a case of death
by a thousand tiny cuts. Nevertheless, because of launch pressure we got into
a position where we thought we had something that would suffice, but when we
tested it with real world data we got constant lockups and OOM problems. When
we realised that one of the most fundamental features - transaction support -
was broken, we decided we had no choice but to change data stores and rethink
our entire architecture, and to have to do that so late in the game was
extremely painful and risky.

~~~
lvca
Ok, I understand who you are, but it's not fair saying the problems was on
OrientDB product: we have a lot of clients running in production without such
problems.

You used experimental parts like ETL (was still in development) and you guys
were aware of this. Furthermore your roadmap was completely unreal, specially
managing a new technology that nobody in your company was skilled on. If I was
the CTO of your company I'd hire somebody skilled on OrientDB if this would
become the foundation of my infrastructure. And you guys didn't model a Graph,
but just kept the old model trying hard to let it working with OrientDB.

Last but not least, you never paid the renewal and in order to help you we
provided support for FREE for 2 months. Sorry, but the main problem there
wasn't the product, but the person that worked on this migration.

Maybe you lost your job because you wasn't able to do this migration, but
please don't put mud on OrientDB.

~~~
anonwarnings
We didn't use the ETL, we rolled our own, and I'm still with the company, so I
think you have me confused with someone else. We hired someone who's an
OrientDB expert to solve these problems because we assumed that the problem
was a lack of skills on our part. Since they were also unable to fix the
problems, and since we did run into very real bugs virtually every day, I'm
confident that the problem is with the product and not ourselves. We did
everything we could to make this work because OrientDB should have been an
exact fit for our use case.

~~~
lvca
Ok, so at this point you wasn't a client and you never hire a real expert?

1) I don't know where did you find this expert. Plugin/driver authors couldn't
be certified. Was this expert certified? And why didn't you ask for a
certified guy to the Orient Technologies company?

2) Did you ever purchased any professional support from Orient Technologies
company?

~~~
anonwarnings
I think you're more interested in finding out who I am or who I work for and
trying to discredit my claims than you are with addressing the issues I
raised, so I'm going to decline to answer your questions. This was not an
attack on you, although you've taken it as such, I was relating my experiences
with your product.

------
arisAlexis
OrientDB can do documents, why do you need mongo for

~~~
reconstrukt
OrientDB (apparently, though I'm now skeptical considering above comments)
does a good job of storing relationships between disparate documents. When
you're searching for relationships (and not meta on the doc itself) we're
curious if OrientDB provides a better solution.

------
quipp
Use the force, Luke.

