dynamodb transition

[tmcw]

@mick i'm currently looking around in dynamodb land for how we should angle this

• intuition would be that simple 'get a ton of exact keys' would be faster than any range queries, but dynamodb charges read units for misses, so that seems inefficient
• otherwise, we could use lots of range queries using the Query type

as far as how to abstract this, it's either finishing #10 or writing simple-ish 'wrappers' for each backend, like i've started with dynamodb. not sure if leveldown is a decent abstraction for dynamodb

[mick]

Dynamo Query allows for BEGINS_WITH comparisons. I think you could generate s2 cells that cover the bounds, perhaps limited to like 5-10 cells (this would be something to tune), and use those for parallel queries. You'll end up getting a bit too much data back and then need to filter that out in cardboard.

leveldown compatible api could be cool. I really like that running locally it would levelup -> leveldown -> dynalite -> levelup -> leveldown But dynamo has more complex items then leveldb key/values so the abstraction might not allow for some of the features you might want to use in the future.

[tmcw]

Okay: after much annoyance with trying to get this thing compatible with both DynamoDB and LevelDB, I'm dropping LevelDB. It shall be revisited at a later date, but the style and function gap is just too big for compatibility not to be a distraction.