Graph pattern search

Let’s say you want to find Products that are connected to Orders by any relationship. Using a near-natural language search expression, you can type in the search in several different ways. Here are a few examples with Bloom results for the first two:

As shown above, Bloom interprets your search term using the vocabulary and as a result, offers suggestions for graph pattern queries you can run.

This is done by first breaking down the search input into word tokens. These tokens are then refined and combined together to create meaningful token permutations, which may be many in number. Bloom uses its knowledge of the graph schema as well as the data in your graph to filter out invalid permutations. The remaining permutations are presented in a comprehensive list of suggestions, which includes graph pattern and other matches (as described in Search bar).

The picture below shows how to interpret these suggestions before selecting one to run. You can toggle the suggestions with the arrows on your keyboard or just click the appropriate one. Once you have decided, press <RETURN> to execute.

Another approach to building graph patterns is to use the proactive suggestions feature of Bloom. This is useful when you need assistance with picking elements of your graph schema (e.g. relationship types from a label or categories that connect together).

Before you type anything in the search input box, Bloom proactively shows a list of your graph schema objects, like categories, label and relationship types. If appropriate for your query, you can start by picking one of the proactive suggestions. But, as explained in Near-natural language and graph patterns above, you can always type your own query as well.

If you pick something from the list (e.g. Order), Bloom assumes that you are interested in a graph pattern with that element. Bloom is able to further refine your suggestion options from there on, including offering additional suggestions on patterns you can create (e.g. categories that connect with Order).

You can also combine both approaches mentioned above by typing a partial search term, picking a suggestion and continuing to build the search using proactive suggestions. Once you are satisfied with your graph pattern query, press <RETURN> to run it.

Category, label and relationship type matches are searched in Bloom’s in-memory metadata of available graph and Perspective elements. For property matches, Bloom queries the database instead to find suggestions. To do so, Bloom relies on property indexes to be set up in the database for any properties that should be searchable in Bloom.

For bigger graphs, all properties of a node with a certain label are considered as indexed if there are less than 1000 nodes with the specific label. However, if a property has the same value on more than 10% of the nodes, it will not be searchable, whether indexed or not, for performance reasons. For small graphs with low cardinality in data values (e.g. the Movies graph, found in the example data sets), Bloom is able to search for property values without requiring an index.

Depending on the search input, the number of indexes, and the speed of typing in the search box, it is possible that Bloom will run a large number of index lookup queries to find relevant matches. Optimizations are built-in to delay firing queries while waiting for user to complete the input and to cancel un-needed queries if the input is changed.

Bloom will also attempt to hide pattern permutations from the suggestions list, if they are not found in the database. This may not be applicable in all situations. It is possible for database performance issues or network latency between the user’s machine and the Neo4j server to cause delays in showing search suggestions.

Neo4j database is case sensitive. By default, property values are matched by Bloom in a case sensitive fashion, if they begin with any of the matching tokens input by the user. If you would like search suggestions to be case insensitive, you can enable Case insensitive search and suggestions under Bloom settings.

By contrast, metadata elements like labels, categories, relationship types or property keys, are matched in a case insensitive fashion. Also, metadata elements are matched if they simply contain one of the search tokens.