Where Native Multi-Model Suits Nicely
Native multi-model provides a huge solution space and is used across industries. Find below a small selection of use cases with a quick explanation from our customers why they have chosen a multi-model approach.
Detecting fraud now involves complicated pattern matching that often considers the graph structure (e.g. an unusual amount of connections to a single host or account), but sometimes also other data which is best accessed orthogonally to the graph structure using secondary indexes.
Internet Of Things
The IoT produces a very high volume of status data, geo location information, sensor data and the like. At the same time, the actual things in the IoT typically come in a hierarchical structure.
Enterprise hierarchies come naturally as graph data and rights management typically needs a mixture of graph and document queries.
The multi-model idea and its data modelling benefits shown for aircraft fleet management.
Identity and Access Management
Identity and access management often involves data that has a hierarchical structure. This data is best described by a tree or a directed acyclic graph. Deciding access rights often involves the graph structure, but there are also a lot of queries about the identities which completely ignore the hierarchy.
Coming up with sensible and effective real-time recommendations for customers in e-commerce is essentially path pattern matching in graphs, since one would like to recommend things to a customer A that have been bought by another customer B who is linked to A in some way, for example by both having bought similar products.
E-commerce systems need to store customer and product data (JSON), shopping carts (key/value), orders and sales (JSON or graph) and data for recommendations (graph), and need a multitude of queries featuring all of these data items.
Network and IT Operations
Computer networks and the associated hosts themselves form a graph, and management of such infrastructure frequently involves queries about this very graph structure, but also queries about the set of hosts or similar things.
In logistics a lot of data occurs: geo locations, tasks, dependencies of tasks, resources needed for tasks. The data is both of a rather diverse structure and highly connected. Queries involve both graph queries considering dependencies and standard index backed queries ignoring dependencies.
Content can have a very inhomogeneous structure, which makes a document store a good data model. However, frequently there are links and connections between different pieces of content, which are most naturally described by a graph structure.
Social networks are the prime example for large, highly connected graphs and typical queries are graph, nevertheless, actual applications need additionally queries which totally ignore the social relationship and thus need secondary indexes and possibly JOINs with key lookups.
Street networks are naturally modelled as a graph. Traffic flow data produces a high volume of time based data which is closely related to the street network. Finding good decisions about traffic management involves querying all this data and running intelligent algorithms using aggregations, graph traversals and joins.
Complex, User-Defined Data Structures
Any application that deals with complex, user-defined data structures benefits dramatically from the flexibility of a document store and has often good applications for graph data as well.
Knowledge graphs are enormous data collections, most queries from expert systems use only the edges and graph queries, but often enough you needs “orthogonal” queries only considering the vertex data.
Workflow Management Software
Workflow management software often models the dependencies between tasks with a graph, some queries need these dependencies; others ignore them and only look at the remaining data.
Version Management Applications
Version management applications usually work with a directed acyclic graph, but also need graph queries and others.