Let's say I have a large set of stock data, each containing a
timestamp, value, stock_id.

One way I could do this would be to create a primary with an integer
key (network byte order) - upon initial load I just increment it per
each insert w/ the data containing timestamp, stock_id, and value.
Unfortunately that seems to create a bit of redundant data if I index
off of each data "field" and the integer key only being used for
uniqueness purposes (within the primary database, since primary
databases can't have dupes).

If I instead changed it so that primary was keyed off stock_id and an
insert of data where a key already exists (for instance: another
datapoint for the same stock, but different timestamp) to just do a
db.put() w/ the key being the actual stock_id, and the data being
timestamp and stock_id (essentially overwriting the last values stored
in data) - would the key extractors I setup via db.associate() called
during db.put() happen after I overwrote the data for said key?

If so, wouldn't I be able to just allow the secondary index to
implicitly create duplicates, hence giving me a "history" of sorts that
I could then query upon for useful things like timestamp ranges, etc.;
as opposed to having all the (essentially) duplicate data in the main
database (since I'd be using a key I generated) ?

The key extractors are called twice -- once for the old version of the
data (the version you are overwriting) to remove the old secondary key
(if necessary), and then again for the new version.

The callback must return the same secondary key for a given primary key
/ data pair, regardless of when it is called. So you can't use the
secondary support directly to maintain a history of old values.

Regards,
Michael.