We’re heading East for our next examination of a noSQL DBMS. Oddly enough, OrientDB’s roots are not in the orient. The boot-shaped country of Italy is where this noSQL database was born. Before diving in to what makes OrientDB unique, you may want to check out our last trip (featuring MongoDB) and some supporting material that discusses noSQL’s relevance. After all, the worst part about traveling is being unprepared and forgetting your toothbrush, important electronics, and/or clean underwear.
Like MongoDB, OrientDB boasts scalability as one of its key features. Alongside scalability, this noSQL database also claims an astonishing 150,000 writes per second on "common hardware" (Dell Notebook model XPS M1530 with Intel(r) Core Duo T7700 2.40Ghz, 3 GB RAM and 5400 rpm HDD). Impressive. Some other brags include its extremely light footprint (approximately 1MB for the full server and no dependencies or libraries needed) and a SQL layer that provides a stepping stone of sorts for relational database programmers to make the conversion.
My favorite part of OrientDB, however, is its ability to both be a document database and a graph database. As a document database, OrientDB can take on a schemaless mode similar to that of MongoDB. Although OrientDB’s implementation does not seem to be as complete as MongoDB’s version, the addition of relationships give OrientDB an completely additional realm of functionality. With relationships, OrientDB also becomes a graph database. Graph database are key when developing social-like websites, as they intuitively can represent relationships such as "Bob and Fred are friends" or "Bob follows Fred". Although these types of relationships can be represented in standard relationship database management systems, graph databases speed up these types of structures and provide much faster implementations of functions commonly performed on graph databases.