Searching and Indexing the Json in redis

Introduction

RedisJSON is a Redis module that gives JSON support in Redis. RedisJSON lets your store update and recover JSON values in Redis, similarly to you would with some other Redis information type. RedisJSON likewise works flawlessly with RediSearch to allow you to file and question your JSON archives. As well as putting away JSON archives, you can again record them utilizing the RediSearch module. This empowers full-text search abilities and reports recovery given their substance. You should introduce two modules to use this element: RedisJSON and RediSearch.

Searching and Indexing the Json in redis

To start indexing JSON documents, one must have 

• Redis 6. x or later
• RedisJSON 2.0 or later
• RediSearch 2.2 or later

Download and introduce Redis on the off chance that you don't, as of now, have it on your OS.

Utilize the redis-cli - - rendition order to affirm that you additionally have the intuitive Redis order line interface.

Indexing

You can now determine ON JSON to illuminate RediSearch that you need to record JSON archives.

For the SCHEMA, you can give JSONPath articulations. The consequence of each JSON Path articulation is ordered and connected with a coherent name (trait). Utilize the characteristic name in the question.

Here is the essential linguistic structure for ordering a JSON record:

FT.CREATE userIdx ON JSON SCHEMA $.user.name AS name TEXT $.user.tag AS country TAG

Note: The characteristic is discretionary in FT.CREATE, yet FT.SEARCH and FT.AGGREGATE questions require property modifiers. Likewise, you ought to try not to utilize JSON Path articulations, which are not entirely upheld by the inquiry parser.

Any prior JSON report or any new JSON archive, added or changed, is naturally listed when the record is made.

You can utilize any compose order from the RedisJSON module (JSON.SET, JSON.ARRAPPEND, etc.).

Example:

{
  "user": {
    "name": "John Smith",
    "tag": "foo,bar",
    "hp": "1000",
    "dmg": "150"
  }
}

Since ordering is coordinated, the record will be noticeable on the file when the JSON.SET 

order returns. Any resulting question that matches the listed substance will return the report.

Indexing JSON arrays with tags 

It is feasible to list scalar string and boolean qualities in JSON clusters by utilizing the special case administrator in the JSON Path. For instance, if you were ordering blog entries, you could have a field called labels, a variety of labels that apply to the blog entry.

{
   "title":"Using RedisJson is Easy and Fun",
   "tags":["redis","json","redisjson"]
}

You can apply a list to the labels field by determining the JSON Path $.tags.* in your construction creation:

FT.CREATE blog-idx ON JSON PREFIX 1 Blog: SCHEMA $.tags.* AS tags TAG

You would then set a blog entry as you would some other JSON record:

JSON.SET Blog:1 . '{"title":"Using RedisJson is Easy and Fun", "tags":["redis","json","redisjson"]}'

Lastly you can look through utilizing the commonplace label looking through linguistic structure:

127.0.0.1:6379> FT.SEARCH blog-idx "@tags:{redis}"
1) (integer) 1
2) "Blog:1"
3) 1) "$"
   2) "{\"title\":\"Using RedisJson is Easy and Fun\",\"tags\":[\"redis\",\"json\",\"redisjson\"]}"

Current indexing limitations

JSON clusters must be listed in TAG identifiers.

It is simply conceivable to list a variety of strings or booleans in a TAG identifier. Different sorts (numeric, geo, invalid) are not upheld.

It is unimaginable to expect to file JSON objects.

A JSONPath articulation should return a solitary scalar worth (string or number) to be recorded.

On the off chance that the JSONPath articulation returns an article, it will be disregarded.

Anyway, ordering the strings in isolated attributes is conceivable.

Given the accompanying archive:

{
  "name": "Headquarters",
  "address": [
    "Suite 250",
    "Mountain View"
  ],
  "cp": "CA 94040"
}

Before you can record the cluster under the location key, you need to make two fields:

FT.CREATE orgIdx ON JSON SCHEMA $.address[0] AS a1 TEXT $.address[1] AS a2 TEXT
OK

You can now record the report:

JSON.SET org:1 $ '{"name": "Headquarters","address": ["Suite 250","Mountain View"],"cp": "CA 94040"}'
OK

You can now look through in the location:

FT.SEARCH orgIdx "suite 250"
1) (integer) 1
2) "org:1"
3) 1) "$"
   2) "{\"name\":\"Headquarters\",\"address\":[\"Suite 250\",\"Mountain View\"],\"cp\":\"CA 94040\"}"

Record JSON strings and numbers as TEXT and NUMERIC

• You can list JSON strings as TEXT, TAG, or GEO (utilizing the correct punctuation).
• You can list JSON numbers as NUMERIC.
• JSON booleans must be recorded as TAG.
• Invalid qualities are overlooked.

SORTABLE isn't upheld on TAG

FT.CREATE orgIdx ON JSON SCHEMA $.cp[0] AS cp TAG SORTABLE
(error) On JSON, cannot set tag field to sortable - cp

With hashes, you can utilize SORTABLE (as a secondary effect) to work on the exhibition of FT.AGGREGATE on TAGs. This is conceivable because the worth in the hash is a string, for example, "foo, bar."

Searching

To look for records, utilize the FT.SEARCH order. You can look through any trait referenced in the pattern.

Following our model, find the client called John:

FT.SEARCH userIdx '@name:(John)'
1) (integer) 1
2) "myDoc"
3) 1) "$"
   2) "{\"user\":{\"name\":\"John Smith\",\"tag\":\"foo,bar\",\"hp\":1000,\"dmg\":150}}"
Indexing JSON arrays with tags

Field projection

FT.SEARCH returns the entire record, of course.

You can likewise return just a particular trait (name for instance):

FT.SEARCH userIdx '@name:(John)' RETURN 1 name
1) (integer) 1
2) "myDoc"
3) 1) "name"
   2) "\"John Smith\""

Projecting utilizing JSON Path articulations

The RETURN boundary likewise acknowledges a JSON Path articulation which allows you to remove any piece of the JSON report.

The accompanying model returns the consequence of the JSON Path articulation $.user.hp.

FT.SEARCH userIdx '@name:(John)' RETURN 1 $.user.hp
1) (integer) 1
2) "myDoc"
3) 1) "$.user.hp"
   2) "1000"

Note that the property name is the JSON articulation itself: 3) 1) "$.user.hp"

Utilizing the AS choice, it is additionally conceivable to nom de plume the brought property back.

FT.SEARCH userIdx '@name:(John)' RETURN 3 $.user.hp AS hitpoints
1) (integer) 1
2) "myDoc"
3) 1) "hitpoints"
   2) "1000"

Highlighting

You can feature any characteristic when it is filed utilizing the TEXT type.

For FT.SEARCH, you need to set the traits in the RETURN boundary and the HIGHLIGHT boundaries expressly.

FT.SEARCH userIdx '@name:(John)' RETURN 1 name HIGHLIGHT FIELDS 1 name TAGS '<b>' '</b>'
1) (integer) 1
2) "myDoc"
3) 1) "name"
   2) "\"<b>John</b> Smith\""

With JSON, you can record a variety of strings. Since there is no substantial single literary portrayal of those qualities, it is impossible for RediSearch to know how to sort the outcome.