Hi guys, A few years ago, before the raising of Titan, the same Marko Rodriguez provided this definition:
1. 49. <http://image.slidesharecdn.com/krdb-graphdb-2010-100918034109-phpapp01/95/graph-databases-trends-in-the-web-of-data-49-728.jpg?cb=1284814035>Defining a Graph Database A graph database is any storage system that provides index-free adjacency. 2. 3. 23 There is no “official” definition of what makes a database a graph database. The one provided is my definition (respective of the influence of my collaborators in this area). However, hopefully the following argument will convince you that this is a necessary definition. Given that any database can model a graph, such a definition would not provide strict enough bounds to yield a formal concept (i.e. ). 4. 24 There is adjacency between the elements of an index, but if the index is not the primary data structure of concern (to the developer), then there is indirect/implicit adjacency, not direct/explicit adjacency. A graph database exposes the graph as an explicit data structure (not an implicit data structure). http://www.slideshare.net/slidarko/graph-databases-trends-in-the-web-of-data/49 My 2 cents are that index-free adjacency makes huge difference against regular join if: 1. Datasets doesn't fit in RAM: if everything can be in RAM there is no difference. 2. Datasets is not distributed. On distributed systems other factors could play a bigger role: how the graph is distributed, the latency between servers, network speed, etc. Best Regards, Luca Garulli Founder & CEO OrientDB <http://orientdb.com/> On 26 October 2015 at 18:52, <[email protected]> wrote: > You are right. > > Please add a link if you find one that truly is :) > > On Monday, 26 October 2015 16:53:02 UTC, Craig Trader wrote: >> >> >>> *About the Authors*Ian Robinson is the co-author of REST in Practice >>> (O'Reilly Media, 2010). Ian is an engineer at Neo Technology, working on a >>> distributed version of the Neo4j database. Prior to joining the engineering >>> team, Ian served as Neo's Director of Customer Success, managing the >>> training, professional services, and support arms of Neo, and working with >>> customers to design and develop mission-critical graph database solutions. >>> Ian came to Neo Technology from ThoughtWorks, where he was SOA Practice >>> Lead and a member of the CTO's global Technical Advisory Board. Ian >>> presents frequently at conferences worldwide on topics including the >>> application of graph database technologies, and RESTful enterprise >>> integration. >> >> Dr. Jim Webber is Chief Scientist with Neo Technology, where he >>> researches novel graph databases and writes open source software. >>> Previously, Jim spent time working with big graphs like the Web for >>> building distributed systems, which led him to being a co-author on the >>> book REST in Practice (O'Reilly Media, 2010). Jim is active in the >>> development community, presenting regularly around the world. His blog is >>> located at http://jimwebber.org and he tweets often @jimwebber. >>> Emil Eifrem is CEO of Neo Technology and co-founder of the Neo4j >>> project. Before founding Neo, he was the CTO of Windh AB, where he headed >>> the development of highly complex information architectures for Enterprise >>> Content Management Systems. Committed to sustainable open source, he guides >>> Neo along a balanced ... >> >> >> Not exactly an unbiased source. >> >> On Mon, Oct 26, 2015 at 11:58 AM, Stefán <[email protected]> wrote: >> >>> 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] >>>> > <mailto:[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. >>> >> >> -- > > --- > 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.
