back to article Love lambda, love Microsoft's Graph Engine. But you fly alone

Much has changed at Microsoft since Steve Ballmer described Linux as "a cancer" in reaction to the open-source flag-flyer's threat to Redmond's money-spinning Windows business. Three years after Redmond's researchers published their whitepaper on distributed graph engine Trinity, Microsoft has announced that it has released …

  1. Tom 7

    I would rather drink bleach

    that try and explain how this works to an MBA earning 5 times what I do.

    1. Pascal Monett Silver badge
      Trollface

      No problem, you'll have to find a way to do what he thinks he wants and is actually impossible to do anyway.

      After all, he's paid 5 times more than you, so he knows 5 times better </sarcasm>.

    2. John Smith 19 Gold badge
      Trollface

      Re: I would rather drink bleach

      Nonsense, a 7YO child could understand this.

      Now all you need is a 7YO child.

      1. TeeCee Gold badge
        Coat

        Re: I would rather drink bleach

        Actually, what you need is a 7YO child who can explain it to an MBA earning 5 times what you do.....

    3. Anonymous Coward
      Anonymous Coward

      Re: I would rather drink bleach

      I've found it pretty easy to get manglement on board with graphs. The really, really nice thing about graph tech for getting business buy-in is that it makes pretty pictures. Graphs are really bloody intuitive. Ever seen a tube map? Graph. Family tree? Graph.

      And that holy of holies for the MBA in the room: Flowchart? Graph.

      Compare that to trying to explain the wonderful world of JOINs to the layman and it's a doddle. The real problem with graphs is actually getting some value out of them. They're (very) easy to build, but hard to get right and expensive to fix.

  2. Anonymous Coward
    Anonymous Coward

    Wot! Most popular DB is not Oracle/SQLServer/MySql?

    {Or any of the other most recognised DB's for that matter}

    The world must be about to stop turning.

    As for the three at the top of that list, who are the people that use these DB's that I am sure that many here may well have never heard of?

    Perhaps El Reg might like to do an article or three on them so at least a few more people at least know their key features?

    1. Doctor Syntax Silver badge

      Re: Wot! Most popular DB is not Oracle/SQLServer/MySql?

      Were you referring to this statement:

      "the most popular graph DBMS by some magnitudes is Neo4j, followed by OrientDB and Aurelius's TitanDB graph databases"?

      If so let me repeat it again with one word emphasised:

      "the most popular graph DBMS by some magnitudes is Neo4j, followed by OrientDB and Aurelius's TitanDB graph databases"

  3. Charlie Clark Silver badge

    What?

    JOINs in relational databases would be prohibitively computationally expensive

    JOINs shouldn't involve computation and they're usually themselves in-memory lookups.

    SQL might be shit for graph work but that has little to with graph databases. But graphs and topology are a different branch of maths than relational calculus.

    As for transactional stuff: if it isn't ACID then it will break and you will lose data. Analytical processing can benefit from parallelism, just as it can live better with redundancy but the SparkSQL approach allows you to keep the API while playing with the storage.

    1. Anonymous Coward
      Anonymous Coward

      Re: What?

      "JOINs shouldn't involve computation and they're usually themselves in-memory lookups."

      Except when they're not equi-joins, or when your data don't fit in memory, or when you don't have a handy index pointing at exactly what you want*. If your problem is graphy, that is always.

      *Which of course required substantial "computation" to build in the first place.

  4. Martin Gregorie

    From an ignorant, long-time DB designers's viewpoint...

    The article's description of Graph DBs make them sound more or less like updated versions of IDMS, a B.F.Goodrich-developed mainframe DBMS that preceeded relational databases. In IDMS the 'edges' were represented by pointers linking the nodes and programs traversed the database by walking the pointer chains.

    Is this a fair comparison?

    1. Destroy All Monsters Silver badge
      Holmes

      Re: From an ignorant, long-time DB designers's viewpoint...

      In a sense but in the olden databases the edge/node structure came directly from the on-disk layout.

      Here the graph is the conceptual idea. Underneath there may well be reused table-structure handling/indexing routines.

      Additionally the use of the "lambda" in the article sounds like name-dropping, I don't see why one would not just call them "procedures".

      1. FIA Silver badge

        Re: From an ignorant, long-time DB designers's viewpoint...

        Additionally the use of the "lambda" in the article sounds like name-dropping, I don't see why one would not just call them "procedures".

        Shush!! Don't tell people, they might peek behind the curtain!

        You'll be telling people that web services are basically just RPC next. ;)

    2. Tim Hines

      Re: From an ignorant, long-time DB designers's viewpoint...

      Also from a position of profound ignorance, is this similar to the basis of the late lamented Corel InfoCentral, which effectively had nodes and connections. For example, you might have records for people with personal info, and for companies with company info and the connection between them might be the person's position and their work related numbers. A person could be connected to more than one company (e.g. somewhere they used to work, or the agent for their area). You could add your own types of entry both for the nodes and the connections, so it was very flexible (I used to track items that could be reused by different companies), although it was somewhat OTT for a simple contacts database.

      It sounds as though there may be tools to create something similar - any recommendations?

      1. Adam 52 Silver badge

        Re: From an ignorant, long-time DB designers's viewpoint...

        My perception is that lack of quality tooling is holding the field back. I don't get on with anything we tried. It's one of the areas Neo4j is leading in, even if their core graph model is a bit limited.

        That said you could try http://ontowiki.net

    3. Anonymous Coward
      Anonymous Coward

      Re: From an ignorant, long-time DB designers's viewpoint...

      "Is this a fair comparison?"

      As far as Neo4j goes, yes. Under the hood it's basically pointers on pointers on pointers on pointers all the way down. Instead of being materialised out in a relational format where every record is a member of a small set of types, graphs allow independent entities to be highly connected in any way, with those connections themselves being typed and traversable in any way. It allows you to answer queries that SQL just isn't geared up to solve; anything with an arbitrary depth.

  5. Lyndon Hills 1
    Joke

    SQL-inspired language for describing patterns in graphs visually using an ASCII-art syntax

    Sadly the most recent ascii-art I can recall is at goat.se (NSFW). I wonder what these databases make of this?

    1. TheVogon

      Re: SQL-inspired language for describing patterns in graphs visually using an ASCII-art syntax

      "I wonder what these databases make of this?"

      I would imagine the best you could hope for is that they would flag that there is a hole in your data....

  6. GrapeBunch

    Chess

    Methods of doing pairings for one-on-one sports where the number of competitors is much greater than the number of rounds, these looked like witchcraft in the 1950s, and sophisticated by 1970. But in 2017 they are tired. When computer pairings came to the fore, the systems were rewritten to eliminate the last vestiges of uncertainty, so now pairings may contain no trace of favouritism. Both the manual and computerized methods are algorithmic, procedural. If Graph Theoretic methods become available, it is an exciting new kinggame. When I last looked into this in 2007, Graph Theory was being taught to undergrads, but way back when I studied Math(s), it was not. Caveat: nobody has determined whether Graph Theory is an appropriate method for making pairings, often called Swiss System pairings. Another caveat: you may invent the greatest pairing system since sliced bread, but it has to be seen as such.

  7. leon clarke

    What's interesting to me about Graph Engine

    What you clearly want now is a 'database' which is scalable (throw more nodes at it when you need more space or speed), which stores things in RAM but properly persists them to (redundant) discs.

    If you've got one of them, it's probable that the CPUs will be under-utilised (since they're mostly there to hang all the RAM off)

    So the dream would be something that can do some compute on all those nodes. (Why copy data somewhere else for processing when there's an under-utilised CPU in the same place as the data)

    That's what Graph Engine seems to be. And I think it's the only open source thing that ticks those boxes. OK, it's a graph database, but that probably fits real wold problems at least as well as SQL usually does when you've got your head round it.

    What else can do that?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like