I'd still need a "all events for app_id" query. We have seconds-level events :-(
On Fri, Feb 1, 2019 at 3:02 PM Jeff Jirsa <jji...@gmail.com> wrote: > On Fri, Feb 1, 2019 at 12:58 PM Carl Mueller > <carl.muel...@smartthings.com.invalid> wrote: > > > Jeff: so the partition key with timestamp would then need a separate > index > > table to track the appid->partition keys. Which isn't horrible, but also > > tracks into another desire of mine: some way to make the replica mapping > > match locally between the index table and the data table: > > > > So in the composite partition key for the TWCS table, you'd have app_id + > > timestamp, BUT ONLY THE app_id GENERATES the hash/key. > > > > > Huh? No, you'd have a composite partition key of app_id + timestamp > ROUNDED/CEIL/FLOOR to some time window, and both would be used for > hash/key. > > And you dont need any extra table, because app_id is known and the > timestamp can be calculated (e.g., 4 digits of year + 3 digits for day of > year makes today 2019032 ) > > > > > Thus it would match with the index table that is just partition key > app_id, > > column key timestamp. > > > > And then theoretically a node-local "join" could be done without an > > additional query hop, and batched updates would be more easily atomic to > a > > single node. > > > > Now how we would communicate all that in CQL/etc: who knows. Hm. Maybe > > materialized views cover this, but I haven't tracked that since we don't > > have versions that support them and they got "deprecated". > > > > > > On Fri, Feb 1, 2019 at 2:53 PM Carl Mueller < > carl.muel...@smartthings.com> > > wrote: > > > > > Interesting. Now that we have semiautomated upgrades, we are going to > > > hopefully get everything to 3.11X once we get the intermediate hop to > > 2.2. > > > > > > I'm thinking we could also use sstable metadata markings + custom > > > compactors for things like multiple customers on the same table. So you > > > could sequester the data for a customer in their own sstables and then > > > queries could effectively be subdivided against only the sstables that > > had > > > that customer. Maybe the min and max would cover that, I'd have to look > > at > > > the details. > > > > > > On Thu, Jan 31, 2019 at 8:11 PM Jonathan Haddad <j...@jonhaddad.com> > > wrote: > > > > > >> In addition to what Jeff mentioned, there was an optimization in 3.4 > > that > > >> can significantly reduce the number of sstables accessed when a LIMIT > > >> clause was used. This can be a pretty big win with TWCS. > > >> > > >> > > >> > > > http://thelastpickle.com/blog/2017/03/07/The-limit-clause-in-cassandra-might-not-work-as-you-think.html > > >> > > >> On Thu, Jan 31, 2019 at 5:50 PM Jeff Jirsa <jji...@gmail.com> wrote: > > >> > > >> > In my original TWCS talk a few years back, I suggested that people > > make > > >> > the partitions match the time window to avoid exactly what you’re > > >> > describing. I added that to the talk because my first team that used > > >> TWCS > > >> > (the team for which I built TWCS) had a data model not unlike yours, > > and > > >> > the read-every-sstable thing turns out not to work that well if you > > have > > >> > lots of windows (or very large partitions). If you do this, you can > > fan > > >> out > > >> > a bunch of async reads for the first few days and ask for more as > you > > >> need > > >> > to fill the page - this means the reads are more distributed, too, > > >> which is > > >> > an extra bonus when you have noisy partitions. > > >> > > > >> > In 3.0 and newer (I think, don’t quote me in the specific version), > > the > > >> > sstable metadata has the min and max clustering which helps exclude > > >> > sstables from the read path quite well if everything in the table is > > >> using > > >> > timestamp clustering columns. I know there was some issue with this > > and > > >> RTs > > >> > recently, so I’m not sure if it’s current state, but worth > considering > > >> that > > >> > this may be much better on 3.0+ > > >> > > > >> > > > >> > > > >> > -- > > >> > Jeff Jirsa > > >> > > > >> > > > >> > > On Jan 31, 2019, at 1:56 PM, Carl Mueller < > > >> carl.muel...@smartthings.com.invalid> > > >> > wrote: > > >> > > > > >> > > Situation: > > >> > > > > >> > > We use TWCS for a task history table (partition is user, column > key > > is > > >> > > timeuuid of task, TWCS is used due to tombstone TTLs that rotate > out > > >> the > > >> > > tasks every say month. ) > > >> > > > > >> > > However, if we want to get a "slice" of tasks (say, tasks in the > > last > > >> two > > >> > > days and we are using TWCS sstable blocks of 12 hours). > > >> > > > > >> > > The problem is, this is a frequent user and they have tasks in ALL > > the > > >> > > sstables that are organized by the TWCS into time-bucketed > sstables. > > >> > > > > >> > > So Cassandra has to first read in, say 80 sstables to reconstruct > > the > > >> > row, > > >> > > THEN it can exclude/slice on the column key. > > >> > > > > >> > > Question: > > >> > > > > >> > > Or am I wrong that the read path needs to grab all relevant > sstables > > >> > before > > >> > > applying column key slicing and this is possible? Admittedly we > are > > in > > >> > 2.1 > > >> > > for this table (we in the process of upgrading now that we have an > > >> > > automated upgrading program that seems to work pretty well) > > >> > > > > >> > > If my assumption is correct, then the compaction strategy knows as > > it > > >> > > writes the sstables what it is bucketing them as (and could encode > > in > > >> > > sstable metadata?). If my assumption about slicing is that the > whole > > >> row > > >> > > needs reconstruction, if we had a perfect infinite monkey coding > > team > > >> > that > > >> > > could generate whatever we wanted within some feasibility, could > we > > >> > provide > > >> > > special hooks to do sstable exclusion based on metadata if we know > > >> that > > >> > > that the metadata will indicate exclusion/inclusion of columns > based > > >> on > > >> > > metadata? > > >> > > > > >> > > Goal: > > >> > > > > >> > > The overall goal would be to support exclusion of sstables from a > > read > > >> > > path, in case we had compaction strategies hand-tailored for other > > >> > queries. > > >> > > Essentially we would be doing a first-pass bucketsort exclusion > with > > >> the > > >> > > sstable metadata marking the buckets. This might aid support of > > >> superwide > > >> > > rows and paging through column keys if we allowed the table > creator > > to > > >> > > specify bucketing as flushing occurs. In general it appears query > > >> > > performance quickly degrades based on # sstables required for a > > >> lookup. > > >> > > > > >> > > I still don't know the code nearly well enough to do patches, it > > would > > >> > seem > > >> > > based on my looking at custom compaction strategies and the basic > > read > > >> > path > > >> > > that this would be a useful extension for advanced users. > > >> > > > > >> > > The fallback would be a set of tables to serve as buckets and we > > span > > >> the > > >> > > buckets with queries when one bucket runs out. The tables rotate. > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >> > For additional commands, e-mail: dev-h...@cassandra.apache.org > > >> > > > >> > > > >> > > >> -- > > >> Jon Haddad > > >> http://www.rustyrazorblade.com > > >> twitter: rustyrazorblade > > >> > > > > > >
