Right structure for index

[Kimblis (Edgaras)]

Hello, in my application I have registered users (Users), unregistered users (Guests) and service providers (Providers). Provider can have clients, it's either Users or Guests. I want to have autosuggest and search for specific provider clients. What would be the best structure? Should I use nested fields for clients and docId as partnerId? Can I search only in specific document? Any ideas for the structure?

[dadoonet (David Pilato)]

I'd totally forget about the existing model and would just think about the usage to build the right "search" objects for my use case.
Here I can't really answer as I don't know the use case.

Basically I'd recommend to ask yourself 2 questions:

• What kind of objects my users want to get back as a response? If it's object X, then just index object X
• What typical attributes my users want to search for? Let say I need attribute a, b and c, just index those attributes within object X whatever the original source of those attributes is.

HTH

[Kimblis (Edgaras)]

I want user to be able to write his previous client's name and get suggested his clients - both registered users and guests. Guests would have some base information like name and phone number, however User might also have email and image url or something like that. How it would be best to maintain index? The most efficient way sounds like storing list of clients in form of:

docId: 1
clients: {
  guests: [{name: 'bobas2', phone: '+457494596489'}, {...}]
  users: [{name: 'bobas', phone: '+45465648496', email: "test@gmail.com", imageUrl:"sdfasdf.jpg"}, {...}]
}

So if it would be possible to search only within specific doc I would query for doc 1 and then start typing "bob", I would be suggested of both "bobas2" guest and "bobas" user. And if I use it for search I would get both of those as a result. best result would be users: [...], guests: [...] if it would be clients: {users: [...], guests: [...]} that would be lit as well

[Christian_Dahlqvist]

That looks like a very relational approach based on your current structure. When working with Elasticsearch it is often better to denormalise than try to replicate a relational structure. It sounds like you need to filter on client type as well as provider, so would perhaps something like where each document stores a single client work?

{
  "provider": "provider2",
  "client": {
    "type" : "guest",
    "name": "bobas2",
    "phone": "+45465648496"
  }
}

Large nested documents are often slow to index and update and querying can also be slower. As you are looking for autosuggest you probably want as low latencies as possible so a flat structure might be preferable.