: > Yes, that's the standard trick. :) : > > Ok, so it wouldn't be possible to have a smaller, faster authoritative : > > shard for near-real-time updates while keeping the entire dataset in a : > > second shard which is updates less frequently?
: Ok, now I'm confused, if the shard the document comes from is : non-deterministic, how can you use this 'trick'? (except that since the I believe Otis's point is that many people use distributed search across shards where some are large and mostly static and one is small and frequently updated with new docs in order to get some performance advantages out of hte long cache lifes on the larger shard(s) ... but this typically works best when you only "add" new docs, and don't modify old ones (or only modify docs added very recently so they're always in the small shard) while the bigger shards are treated as "archives" that don't change. To be deterministic you can't have the same uniqueKey in multiple shards. -Hoss
