Update: The scope of this ticket has been adjusted to focus on a spike for the overall getEvents design. It’s difficult to make a clear decision between LFS and RocksDB without further exploring and validating the several alternatives specifically the indexing portion, which this spike is focused on.
Original: Based on the outputs from all of the spikes into alternative datastores, we're currently at a crossroads between LFS and rocksdb. While investigations have focused on the LCM store and getTransaction implementations, we know that the next highest priority historical endpoint up that we'll need to implement is getEvents. Because the results between LFS and rocksdb are so close, we'd like to also spike out if one is markedly better in terms of implementation ease/performance/data footprint/etc for a potential getEvents implementation, as that may be the decision-making factor.
Update: The scope of this ticket has been adjusted to focus on a spike for the overall getEvents design. It’s difficult to make a clear decision between LFS and RocksDB without further exploring and validating the several alternatives specifically the indexing portion, which this spike is focused on.
Original: Based on the outputs from all of the spikes into alternative datastores, we're currently at a crossroads between LFS and rocksdb. While investigations have focused on the LCM store and
getTransactionimplementations, we know that the next highest priority historical endpoint up that we'll need to implement isgetEvents. Because the results between LFS and rocksdb are so close, we'd like to also spike out if one is markedly better in terms of implementation ease/performance/data footprint/etc for a potentialgetEventsimplementation, as that may be the decision-making factor.