This is related to the issue #1807.
Right now the linklist is stored as [,]. This doesn't scale when you've many items because everytime OrientDB has to un-marshall the full list, add an item and re-marshall it. So we need something like we did for LINKSET but with LIST. The first idea in my mind is linked list, but probably there can be better impl.
Can we use LINKBAG for this?
On this case the index would be the position, not a document field. Could it be efficient?
The same issue with insert into position other then the last.
I'm not sure that such batch updating of indexing will provide a good scale.
There is a workaround, we could use floats as keys and don't update other indexes. So the key will not represent an index just some value to order elements.
However it is rather workaround then proper solution.
WDYT about creation a new disk data structure, like SBTreeBonsai?
is it done anything on this ? this is closely related to #681, the new serialization format should support partial update
My initial idea was to ave huge lists split in multiple records as linked list or whatever.
the implementation in the record binary serialization, already improve the LINKLIST handling compared to the csv serialization. in future we may consider to user the ridbag for really uge list.