Here's the transcript of our conversation:
RVB: 00:03.249 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo Technology, and here I am again, recording another podcast for the Graphistania podcast, and this time I've got another introduction of my dear friend Michael Hunger on the other side of this Skype call and that's Andrew Bowman. Hi, Andrew.
AB: 00:22.118 Hi, Rik. Thanks for having me.
RVB: 00:23.483 Hey, thanks for coming online. I really appreciate it. Andrew, I've seen a bit of your work and I've heard people talk about your work with Neo4j but I think most listeners haven't yet, so would you mind introducing yourself and tell us a little bit about your relationship to the wonderful world of graphs?
AB: 00:45.271 Sure. So if you ask questions about Neo4j on StackOverflow or on the Neo4j-users Slack, I'll probably pop in there at some point. I like answering questions and dealing with questions with Cypher, with modeling, and figuring out tricky queries, and troubleshooting. So that's most of my visibility at this point in time.
RVB: 01:12.639 That's where I've seen you being visible [laughter], I must admit, yeah. And then how did you get into Neo4j, Andrew?
AB: 01:21.048 Sure. Well, I joined up a little bit late, around last year when Neo4j 3.0 was introduced. I've been with Athena Health last year and we have an athenaText social network, and, as you know, when you're trying to use a social network on a relational database, eventually you'll probably run into problems as you attempt to scale. So problems with query complexity, problems with trying to interconnect people with each other if they're part of the same group, an N-squared issue, for example. Questions about, well how do we easily recommend people to each other? What if we want to create newsgroups? All of these questions around social networks and the challenges of handling these questions at scale, it eventually leads to the idea that relational is not enough. So last year when we got the opportunity to start looking for some better solutions to improve some of our systems, I started looking into graph databases as a solution, and Neo4j has been a leader of the pack for graph databases for a long time, so that was my top hit. And I think it wasn't until I started seeing snippets of Cypher that I started falling in love with this technology [laughter].
RVB: 02:51.316 You're not the only one, Andrew. I mean, there's so many people have told us about that already and, yeah, I understand it as well. Cypher is dear to my heart as well. But it's the social networking use case that kind of drove you to Neo4j if I understand correctly, right?
AB: 03:06.203 Yes, that's right.
RVB: 03:07.462 Okay. Is that the only reason why you think it's-- I mean, that's always the second question that I ask people. Why are you attracted to graphs or why do you why do you work with graphs? Is it that use case specifically or what's driving your engagement there?
AB: 03:24.120 Well, that was the hook, certainly. But as far as what's keeping me here, for one, it's so immensely useful in so many different cases besides just social graphs, and of course you've got many cases listed on the sites, from fraud detection to real-time recommendations to dealing with issues of security and management, and so many others. It's so useful. And with cypher as kind of the driving language, it's such an elegant language and avoids so many of the pitfalls that SQL and SQL-based languages have typically run into. So it's easy to work with. it's an incredible technology, and I think one of my favourite parts of Neo4j is it enables clearer and faster communication between everyone involved, whether it's the developers or management or even people who don't have any experience with graph databases or databases in general. You can show them a snippet of Cypher or Cypher match, draw that on the whiteboard very quickly, and it's easy to understand and figure out, "Oh well, that's what you want this to do." So I--
RVB: 04:48.580 Do you have a large database background, Andrew, or have you been working with [inaudible] database for a long time and experiencing all of the problems there? Or how would you compare the both, I would say?
AB: 05:04.307 That's about right. So I've been kind of working in multiple places in the Stack for athenaText both at the front ends and a lot on the back ends, and that does involve taking a look at our tables, our actual data, the SQL queries, and the views that we're using, and changes that we're applying ways- to optimize. So I'm fairly familiar with SQL and some of the headaches that come with it or just some of what's kind of baked into it, whether it's having to declare what your returning at the very start and kind of workin upside down, where SQL - I'm sorry, where Cypher - kind of makes it all clear and makes sense. You get a change to kind of break apart your query and drive towards an end rather than having to try to throw everything together all at once.
RVB: 06:03.764 So is there anything that you're using-- for example, in Cypher, is like your-- how do I say this? My English is failing me here, sorry. Like your favorite feature in Cypher. What do you think is like the best thing about it that's really unleashing a lot of the power for you?
AB: 06:25.883 Well, I'm not sure if I could pick one thing [laughter], but related to that, I am a huge fan of the APOC libraries, so a lot of my work has been on those too, figuring out what other functions or procedures could be useful and making some pull requests there. So one of my favorite features there, I could talk about is APOC' s path expander. I'm a big fan of that, both in terms of using that to better handle queries where you're interested more in the nodes at the end of the path than you are in the older paths that get generated. So that's great for matching two sub-graphs, expanding out sub-graphs.
RVB: 07:09.179 [inaudible]. One of my colleagues was working in that as well. Like Kees Vegter in Holland was originally working on that one, I think, as well. If I recall correctly, at least. I'm not sure.
AB: 07:19.963 Yeah. So that's one area where Cypher can sometimes run into issues because the variable length relationships are more concerned with the paths, but it's very nice to be able to specify with APOC that, "No, I'm only interested in nodes. Give me the nodes here," and to see a nice speed up on the execution.
RVB: 07:41.493 Sweet. Very cool. So maybe we can kind of wrap up this conversation with a crystal ball. Where do you see this going, Andrew? What's in store for you and for our industry? How do you look at that? What does the future hold?
AB: 08:02.181 Well, let's see. For myself, I definitely want a future with property graphs, hopefully with Neo4j themselves. So looking for maybe consulting or if there's a place with Neo Technology I'd be open to that.
RVB: 08:19.758 Oh, okay. Cool, I'll keep that in mind [laughter].
AB: 08:24.537 As for graphs themselves, it feels like usage and knowledge of graphs is already taking off. More and more articles about it, more and more tech companies becoming aware that, "Well, we've got some challenges with relational databases. Maybe there's better solutions out there," and Neo4j is well positioned to take advantage of that and to kind of expand and feed that world of graphs, and that's a wonderful thing to see.
RVB: 08:59.074 Very much so - absolutely. Well, you know what? I think we'll probably meet each other at one of the future GraphConnect conferences or something like that, so I look forward to continuing that conversation over there, and of course on one of the online channels, Stackoverflow, Slack or wherever it is that you might be intervening, right?
AB: 09:22.122 Absolutely. You'll definitely see me there.
RVB: 09:24.722 Very good. Thank you, Andrew, for taking this time to have this conversation. I really appreciate it and I look forward to what's in store.
AB: 09:33.953 Thanks so much, Rik.
RVB: 09:34.629 Cheers. Bye-bye.
AB: 09:36.565 Bye.Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!
All the best
Rik
No comments:
Post a Comment