A graph database like Neo4j allows much greater flexibility than a traditional relational database, and this is especially true for businesses that need to be able to trace the relationships in their data and uncover patterns of data quality issues.
In this week’s five-minute interview (conducted at GraphTour NYC, 2019), we speak with Mayank Gupta, senior vice president of Data at LPL Financial, about the wide-ranging benefits his company gains from graph technology and his vision for a domain-specific knowledge graph.
How are you using Neo4?
We are using Neo4j to essentially group entities together. So, we have a lot of accounts that have persons associated with them, it could be the advisor, the account holder, secondary beneficiary, and what we’re doing is we’re using our graph to house this data. And to sort of construct different types of groups so that we could consolidate alerts, and do a more efficient reach-out in case there is a fraud alert, or any kind of notification that we need to work with, with our users.
Why did you choose graph technology?
Graphs are an incredibly powerful structure.
Neo4j brought us three key advantages. One was that data modeling can be iterative, without really breaking older use cases. So you can layer in nodes, and edges, and relationships onto an existing graph, grow it, both in terms of its scope of data, as well as the scope of its meaning, very iteratively. And that allows us to work faster, better.
I think a lot of our problems, because the relationships can be very convoluted, are better served with graph constructs than they are with relational stores. Those are our main drivers for using Neo4j.
What are the most surprising results that you’ve seen with Neo4j?
For us, we got two benefits that we were not planning on but perhaps had thought about. We are able to see data quality issues, because of the centrality of certain nodes. And we also started to create a system that gave us a historical path.
For example, John started as an advisor, opened up these accounts, moved to a different group, moved those accounts under that group, or Joe as an investor opened that account, closed it, and consolidated it into a different one. So that change history, and being able to visualize it, and find that path very quickly were very powerful secondary benefits that we derived from Neo4j.
Do you have any advice for people just starting out with graph?
Yes. One bit of advice is understanding graphs as a data structure. I know all of us in comp-sci had graph theory in school. But, at least for me personally, the applications were difficult to see. We all learned about the traveling salesman problem, and so on. But seeing how graphs can apply to other business problems is crucial.
So, my initial introduction to graphs was through this book called NoSQL Distilled. And it really talked about graphs as a structure and the emerging databases. So definitely learn about graph and graph theory. I think it’s deeply, deeply powerful.
And it starts to make that shift, from relational models, because most folks think in terms of models, to instance data, and connections between instances. And dynamic connections between instances.
I think the second thing is to learn the tool set for Neo4j. There are really very few graph databases, and to me, at an enterprise level Neo4j is the only one. Many people have tried and it just hasn’t worked, right? So, really learn the tooling.
Out of the box Neo4j comes with a great browser; it’s something that you can query and you can visualize off of it. Start to get into that, definitely.
And, I think the final advice I would give is around iteration. You’re not gonna get a perfect model. It’s not gonna be a waterfall-style project, where you’ll have everything well defined. You’re gonna iterate and you’re gonna make a lot of mistakes and you’ll have to make changes, but understand that the graph is actually making it easy for you to do that. I think that would be my key advice to anybody starting out.
What are you looking forward to with the future of graphs?
The knowledge graph. Look at Google, and how good they have become at search. There’s a deep amount of underlying engineering and data gathering, crawling the web as it were. They’ve turned that information into an internal knowledge graph that is driving the majority of their search results. I think there are 57 steps that they take, typically. They call different algorithms, and half of them are against a knowledge graph.
I think that a knowledge graph that is specific to our user base and to our company is gonna be mind blowing. If I can get this to work, I think there are many applications and benefits to derive from it. For us and for our users.
Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at firstname.lastname@example.org
Want to learn more on how relational databases compare to their graph counterparts? Get The Definitive Guide to Graph Databases for the RDBMS Developer, and discover when and how to use graphs in conjunction with your relational database.
Get the Ebook
Get the Ebook