Multiple indexes

[fab2s]

Hello,

This package is great really, thanks for the good work.

Detailed description

Search index are bound to grow and I think that a great feature to add would be to allow for a per model index. In many case, we need to add search on more than one model, and with a single table, we will end up with unnecessary big one. The "global search" could be made optional, and only include the models specifically declared as such.

I also think that the underlying model should avoid using auto increments as primary key, as they tend to degrade performance when growing, especially for the "global search" usage.
Would be better to use UUids. Uuid kind is not very important for the usage, as we don't expect to order the table on them, but ordered UUids mays still be worth it for better write throughput (as new records are almost always happened to the index).
I wrote a simple package for that https://github.com/fab2s/SoUuid
There are others but base62 format may be worth considering to reduce index length (it requires a case sensitive column though, or in laravel / mysql world $table->char('id', 21)->charset('ascii')->collation('ascii_bin')->primary();).

The index structure also should have no opinion about the models id type and just use case sensitive string type, as it would work for both auto-incremented and uuid models (any kind).

Context

It would make increase performance (a lot) every time one needs to index several models but does not necessarily want to search all of them at once, for example to smart auto complete to most models.

Possible implementation

I just discovered this great package, so I just took a quick look, but from what I see, the change surface should not be that big. The trait could include a variable to ask for a dedicated table, and another one to be included in the global index or not.

The search run would only consider the global index, and the runForClass would just have to set the table name in the Index model if applicable, and use a slightly different query (to not use the morph relation in that case).

There would be a need to be able to create relevant specialized table "on the fly" when indexing (another way would be to put those model based settings in config (array of model classes) or to parse model to read props (and maybe add an option in config for extra model paths) and leave the dedicated table creation to the commands.
The on the fly option seems ok if the table exist check (model table name could be implicit and or specifically set by the indexed model props) result in stored in cache.

Then tweak the "live" and "batch" indexing to either index globally, or locally, or both.

I know this would represent still some changes, but I really think it would make this package battle ready for many more use cases, and BC should also remain possible.

I am willing to help, but I won't be able to code much immediately. I would though be happy if you would consider it and would help as much as I can.

Keep up the good work !

Cheers

[bbrala]

Thanks for the writeup. It's an interesting idea to split up the indexes for speed. Currently we don't really have an usecase in our projects for that unfortunately, single index is fine.

But especially if the changes are too breaking i wouldn't mind. :)