Graph Databases in the Enterprise: Graph-based Search
Graph Databases in the Enterprise: Graph-based Search
The advantages of graph-based search and why this model is good enough for Facebook and Google.
Join the DZone community and get the full member experience.Join For Free
MariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.
Graph-based search is a new approach to data and digital asset management originally pioneered by Facebook and Google.
Search powered by a graph database delivers relevant information that you may not have specifically asked for – offering a more proactive and targeted search experience and allowing you to quickly triangulate the data points of the greatest interest.
The key to this enhanced search capability is that on the very first query, a graph-based search engine takes into account the entire structure of available connected data. And because graph systems understand how data is related, they return much richer and more precise results.
Think of graph-based search more as a “conversation” with your data, rather than a series of one-off searches. It’s search and discovery, rather than search and retrieval.
In this “Graph Databases in the Enterprise” series, we’ll explore the most impactful and profitable use cases of graph database technologies at the world’s leading organizations. In past weeks, we’ve examined fraud detection, real-time recommendation engines, master data management, network & IT operations and identity & access management (IAM).
This week, we’ll take a closer look at graph-based search.
The Key Challenges in Graph-Based Search:
As a cutting edge technology, graph-based search is beset with challenges. Here are some of the biggest:
- The size and connectedness of asset metadata The usefulness of a digital asset increases with the associated rich metadata describing the asset and its connections. However, adding more metadata increases the complexity of managing and searching for an asset.
- Real-time query performance The power of a graph-based search application lies in its ability to search and retrieve data in real time. Yet, traversing such complex and highly interconnected data in real time is a significant challenge.
- Growing number of data nodes With the rapid growth in the size of assets and their associated metadata, your application needs to be able to accommodate both the current and future requirements.
Why Use a Graph Database for Graph-Based Search?
Graph-based search would be impossible without a graph database to power it.
In essence, graph-based search is intelligent: You can ask much more precise and useful questions and get back the most relevant and meaningful information, whereas traditional keyword-based search delivers results that are more random, diluted and low-quality.
With graph-based search, you can easily query all of your connected data in real time, then focus on the answers provided and launch new real-time searches prompted by the insights you’ve discovered.
Graph databases make advanced search-and-discovery possible because:
- Enterprises can structure their data exactly as it occurs and carry out searches based on their own inherent structure. Graph databases provide the model and query language to support the natural structure of data.
- Users receive fast, accurate search results in real time. With a graph database, a variety of rich metadata is assigned to all content for rapid search and discovery.
- Data architects and developers can easily change their data and its structure as well as add a wide variety of new data. The built-in flexibility of a graph database model allows for agile changes to search capabilities.
In contrast, information held in a relational database is much more inflexible to future change. If you want to add new kinds of content or make structural changes, you are forced to re-work the relational model in a way that you don’t need to do with the graph model.
The graph model is much more easily extensible and over 1,000 times faster than a relational database when working with connected data.
Example: Google and Facebook
This method relied on plain pattern recognition, and many users found it to be a cumbersome process of repeatedly redefining search terms until the correct result was found.
Facebook’s database of people and Google’s database of information have one crucial thing in common: They were both built using graph technology. And in recent years, both Google and Facebook have realized they could make much better use of their huge swathes of searchable content, and have each launched new graph-based search services to exploit these commercial opportunities.
Realizing the limitations of keyword searches, Google launched its “Knowledge Graph” in 2012 and Facebook followed suit with its “Graph Search” service in 2013, both of which provide users with more contextual information in their searches.
As a result of these new services, both enterprises realized substantial lift in user engagement – and therefore commercial success.
Following in the footsteps of giants like Facebook, Google and adidas, new startups like Glowbl and Decibel – and many others – have also created graph-based search tools to discover new business insights, launch new products and services and attract new customers.
For businesses that have huge volumes of products, content or digital assets, graph-based search provides a better way to make this data available to users, as corporate giants Google and Facebook have clearly demonstrated.
The valuable uses of graph-based search in the enterprise are endless; customer support portals, product catalogs, content portals and social networks are just a few.
Graph-based search offers numerous competitive advantages, including better customer experience, more targeted content and increased revenue opportunities.
Enterprises that tap into the power of graph-based search today will be well ahead of their peers tomorrow.
By Jim Webber & Ian Robinson, Chief Scientist & Senior Engineer, Neo4j
Opinions expressed by DZone contributors are their own.