milleruntime commented on issue #2076: URL: https://github.com/apache/accumulo/issues/2076#issuecomment-839984446
> As Keith says, the current key scheme may be adequate... it's certainly the simplest migration. In that case, you don't need to use the CF, CQ, or CV at all. Just Row/Value. The current scheme in LogFileKey is just an implementation for `WritableComparable` which includes serialization/deserialization and the compareTo method. Part of this task is translating `LogFileKey` into an Accumulo `Key` so we can store it in an RFile. I am also translating `LogFileValue` into an Accumulo `Value` (but this is just the mutations serialized). We need somewhere to put all the information serialized in `LogFileKey` into `Key`, otherwise it will be lost when sorted. > We don't need efficient reads of all events of a specific type (I don't think so, anyway). There are a few places during recovery where we iterate over the logs to get different types of information. The first time we only look for `DEFINE_TABLET` events in the log. This is where I got the idea to use event for CF. Check it out here: https://github.com/apache/accumulo/blob/6a74b4667e3bd33e34b5262c5dd8ea64167fb657/server/tserver/src/main/java/org/apache/accumulo/tserver/log/SortedLogRecovery.java#L105 > The wrench in my thinking is that I'm not that familiar right now with the recovery process, and I'm not actually sure why event type sorts before tablet ID. Join the club! I still don't understand `tabletId` and `seq` in LogFileKey. This comment here makes me think its tracking in each WAL: https://github.com/apache/accumulo/blob/6a74b4667e3bd33e34b5262c5dd8ea64167fb657/server/tserver/src/main/java/org/apache/accumulo/tserver/log/SortedLogRecovery.java#L290-L292 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
