Hi,
I have a table with composite primary id ((userid), id). Some patterns about my table: * Each user generally has 0-3000 rows. But there is currently no upper limit. * Deleting rows for a user is extremely rare, but when done it can be done thousands of rows at a time. * The absolutely most common query is to select all rows for a user. Recently I saw a user that previously had 65000 tombstones when querying for all his rows. system.log was printing TombstoneOverwhelmingException. What are my options to avoid this overwhelming tombstone exception? I am willing to have slower queries than actually not being able to query at all. I see a couple of options: * Using an anti-column to mark rows as deleted. I could then control the rate of which I am writing tombstones by occasionally deleting anti-columns/rows with their equivalent rows. * Simply raise tombstone_failure_threshold. AFAIK, this will eventually make me run into possible GC issues. * Use fetchSize to limit the number of rows paged through. This would make every single query slower, and would not entirely avoid the possibility of getting TombstoneOverwhelmingException. Have I missed any alternatives here? In the best of worlds, the fetchSize property would also honour the number of tombstones, but I don’t think that would be possible, right? Thanks, Jens ——— Jens Rantil Backend engineer Tink AB Email: jens.ran...@tink.se Phone: +46 708 84 18 32 Web: www.tink.se Facebook Linkedin Twitter
