Add section on indexing in user documentation
Summary: The openCypher chapter of user documentation now includes information on creating label & property index. Reviewers: florijan, buda Reviewed By: florijan Subscribers: pullbot Differential Revision: https://phabricator.memgraph.io/D537
This commit is contained in:
parent
62987d22e6
commit
514d9d2808
@ -11,6 +11,7 @@ not yet supported features of the language are listed.
|
|||||||
* [Reading existing Data](#reading-existing-data)
|
* [Reading existing Data](#reading-existing-data)
|
||||||
* [Writing new Data](#writing-new-data)
|
* [Writing new Data](#writing-new-data)
|
||||||
* [Reading & Writing](#reading-amp-writing)
|
* [Reading & Writing](#reading-amp-writing)
|
||||||
|
* [Indexing](#indexing)
|
||||||
* [Other Features](#other-features)
|
* [Other Features](#other-features)
|
||||||
|
|
||||||
### Reading existing Data
|
### Reading existing Data
|
||||||
@ -303,6 +304,54 @@ Example. Set a different properties depending on what `MERGE` did.
|
|||||||
For more details, click [this
|
For more details, click [this
|
||||||
link](https://neo4j.com/docs/developer-manual/current/cypher/clauses/merge/).
|
link](https://neo4j.com/docs/developer-manual/current/cypher/clauses/merge/).
|
||||||
|
|
||||||
|
### Indexing
|
||||||
|
|
||||||
|
An index stores additional information on certain types of data, so that
|
||||||
|
retrieving said data becomes more efficient. Downsides of indexing are:
|
||||||
|
|
||||||
|
* requiring extra storage for each index and
|
||||||
|
* slowing down writes to the database.
|
||||||
|
|
||||||
|
Carefully choosing which data to index can tremendously improve data retrieval
|
||||||
|
efficiency, and thus make index downsides negligible.
|
||||||
|
|
||||||
|
Memgraph automatically indexes labeled data. This improves queries
|
||||||
|
which fetch nodes by label:
|
||||||
|
|
||||||
|
MATCH (n :Label) ... RETURN n
|
||||||
|
|
||||||
|
Indexing can also be applied to data with a specific combination of label and
|
||||||
|
property. These are not automatically created, instead a user needs to create
|
||||||
|
them explicitly. Creation is done using a special
|
||||||
|
`CREATE INDEX ON :Label(property)` language construct.
|
||||||
|
|
||||||
|
For example, to index nodes which is labeled as `:Person` and has a property
|
||||||
|
named `age`:
|
||||||
|
|
||||||
|
CREATE INDEX ON :Person(age)
|
||||||
|
|
||||||
|
After the index is created, retrieving those nodes will become more efficient.
|
||||||
|
For example, the following query will retrieve all nodes which have an `age`
|
||||||
|
property, instead of fetching each `:Person` node and checking whether the
|
||||||
|
property exists.
|
||||||
|
|
||||||
|
MATCH (n :Person {age: 42}) RETURN n
|
||||||
|
|
||||||
|
Using index based retrieval also works when filtering labels and properties
|
||||||
|
with `WHERE`. For example, the same effect as in the previous example can be
|
||||||
|
done with:
|
||||||
|
|
||||||
|
MATCH (n) WHERE n:Person AND n.age = 42 RETURN n
|
||||||
|
|
||||||
|
Since the filter inside `WHERE` can contain any kind of an expression, the
|
||||||
|
expression can be complicated enough so that the index does not get used. We
|
||||||
|
are continuously improving the recognition of index usage opportunities from a
|
||||||
|
`WHERE` expression. If there is any suspicion that an index may not be used,
|
||||||
|
we recommend putting properties and labels inside the `MATCH` pattern.
|
||||||
|
|
||||||
|
Currently, once an index is created it cannot be deleted. This feature will be
|
||||||
|
implemented very soon. The expected syntax for removing an index will be `DROP
|
||||||
|
INDEX ON :Label(property)`.
|
||||||
|
|
||||||
### Other Features
|
### Other Features
|
||||||
|
|
||||||
|
@ -14,20 +14,13 @@ will be continually working on improving the performance. This includes:
|
|||||||
* memory usage and
|
* memory usage and
|
||||||
* other improvements.
|
* other improvements.
|
||||||
|
|
||||||
### Indexing by Label-Property
|
### Label-Property Index Usage Improvements
|
||||||
|
|
||||||
Currently, all nodes in the database are indexed by their labels (if they have
|
Currently, indexing combinations of labels and properties can be created, but
|
||||||
any). This improves the performance of finding labeled data. We plan to extend
|
cannot be deleted. We plan to add a new query language construct which will
|
||||||
indexing to include combinations of labels and property values. These kinds of
|
allow deletion of created indices.
|
||||||
indexes would need to be created on demand, by using a new query language
|
|
||||||
construct.
|
|
||||||
|
|
||||||
The idea behind label-property indexing is to improve the performance of
|
### Improving openCypher Support
|
||||||
finding data, which contains a specific combination of labels and property
|
|
||||||
values. In addition to finding the exact values, with this mechanism, we will
|
|
||||||
offer faster retrieving of property values in sorted order.
|
|
||||||
|
|
||||||
### Improving openCypher support
|
|
||||||
|
|
||||||
Although we have implemented the most common features of the openCypher query
|
Although we have implemented the most common features of the openCypher query
|
||||||
language, there are other useful features we are still working on.
|
language, there are other useful features we are still working on.
|
||||||
|
Loading…
Reference in New Issue
Block a user