When Facebook released its Graph Search, the general public finally got a look at what the “backend” of Facebook looked like or its possible uses ... For many the consumer to consumer (c2c) version of Facebook’s long available business-to-business and business-to-consumer offerings was a bit more of the “creepy” vs. the “cool” of the social media content. However, I think it will have the impact of opening people’s eyes on how their content can and probably should be used for search and other analytical purposes.
With graph structures, unlike tabular structures such as row and column data schemas, you look at the relationships between the nodes (i.e. customers, products, locations, etc.) as opposed to looking at the attributes of a particular object. For someone like me, who has long advocated that we should look at how people, places and things interact with each other versus how their “demographics” (i.e. size, shape, income, etc.) make us “guess” how they interact with each other. In my opinion, demographics and now firmographics have been used as “substitutes” for how people and organizations behave. While this can be effective in the aggregate, as we move toward a “bucket of one” treatment model for customers or clients, for instance, we need to move away from using demographics/firmographics as a primary analysis tool.
Graphs, whether they be social relationships like Facebook or LinkedIn or event interactions like call/SMS graphs from telecommunications or sales nodes and links for businesses are well positioned to take the lead in analytics. Because the graph structures are designed to represent and report on relationship rather than just attributes, graph data stores such as Neo4j and InfiniteGraph can often do analysis much quicker and easier than if you were to put the same information in a tabular format.
When you identify nodes that matter the most for your graph (i.e. most connections, highest point of important between two groups, most influential relationships), you can then bring in the demographic/firmographic information about those nodes. In a way, you are getting away from using the “creepy aspects” of a set of information because the analysis is purely based on how the nodes behave rather than the “who” in the nodes are. At this point, you can link the demographic/firmographics information with the node and make a treatment decision for any number of analytical or operational analytics use cases.
For example, in telecommunications, fraudsters have been detected based on the associations or relationships they make. Often, you didn’t need to know the “who” of the fraudster. The actions generally told you what you needed to know. Imagine using the same type of analytics to determine who the most influential companies in your customer base are and then using their firmographic information to make a decision on how to target your sales efforts. Highly influential customers always deserve attention, but imagine you now understand their budgets in addition to their leadership in your customer base. Those are customers that can make or break a sales cycle whether it’s a month, a quarter or a year.
What say the readers?
Do graph data stores have a future in your organization? Do you have information that might easily be placed into a graph store? Have you tried graphs and gotten good or bad results?
Provide your comments below and/or ping me via twitter at @JohnLMyers44 with the hashtag #noodlingNoSQL.
(Author’s note: As I move into describing specific NoSQL solutions, I will mention specific NoSQL products. I am not endorsing any one product or configuration. However, I do like to mention technologies that make particular impressions on me because of their innovation or unique abilities.)
O'Reilly has a new book on Graph Databases (graphdatabases.com).