Hi, I would at least try to rely on definitions, sources and/or specs that are not originated from a player in the field.
There are many articles that discuss this and here is one: https://www.safaribooksonline.com/library/view/graph-databases/9781449356255/ch01.html By stating this I'm not saying that Titan can not be fast and if you keep in mind that graphs are hard to shard, mostly because of this principle, then one could argue that using a column or key/value store underneath has merit. (over simplification) Regards, -Stefan On Monday, 26 October 2015 15:38:08 UTC, Pieter Martin wrote: > > Hi, > > Here is link that addresses the topic from a different angle. > > > http://thinkaurelius.com/2013/11/01/a-letter-regarding-native-graph-databases/ > > > Admittedly it is from the architect of titan on top of cassandra which > makes it perhaps more non native that other graph db's non nativeness. > Its a rather slippery slope to start arguing about nativeness. > > Cheers > Pieter > > On 26/10/2015 17:26, scott molinari wrote: > > That makes perfect sense. So, theoretically, a "pure" graph database > > with its own storage engine has intrinsic advantages over other graph > > databases, which rely on third party storage engines. That is good to > > know actually. > > > > Scott > > -- > > > > --- > > 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] <javascript:> > > <mailto:[email protected] <javascript:>>. > > 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.
