Allow reindexing a Storage
albe opened this issue · 3 comments
This is a very expensive operation, as it involves a full database scan, but it can help when indexes get broken and would technically allow for rewriting storage partitions.
Edit: This is not easily possible without completely losing original global document order, since the global version number needs either to be stored in the document record itself (which means writing the index before the document), OR assume that the documents haven't changed in amount and order, so going through the existing index and keeping that order.
An midway alternative would be to just guarantee a chronological order and reindex on commit timestamp (which could still be unrelated to actuall document creation/event occurence order).
Alternatives:
- no global order, only per partition
- store global sequence inside document (still means writers can never be distributed per partition)
- partial global order by timestamp/vector clock/TrueTime (Google spanner)
- global order by
[monotonic timestamp, partitionId](only consistent with distributed writers with a synchronized clock)
Depending on the goals, following solutions are viable:
- strong consistency for all reads over multiple partitions:
- single writer for all partitions / global sequence number
- TrueTime (increases latency in relation to clock drift, so performance issue without guarantees for synchronized clocks drift in the order of few ms)
- guaranteed consistency only for reads per partition:
- no global order
- partial global order (cross-partition reads are consistent most of the time)
partial global order gives best results vs. implementation cost, but no strong guarantees. The partial global order could be "upgraded" to TrueTime though, by storing two timestamps. As long as a single writer is still used (no replication in place), this would still provide a strong consistency with a monotonic clock in the system and write-timestamp given by the writer.