https://authzed.com logo
Join Discord
Powered by
Hey team,
# spicedb
k
Hey team, Pls, help with this questions: question 1 - we can have only one table 
relation_tuple
and it doesn't depend on the schema type? For example, can we separate data in it for the several tables? question 2 - If I use 
OPERATION_TOUCH
for the same subject+object its always creates a new row in the 
relation_tuple
. And when I use 
OPERATION_DELETE
its deletes only the last, and duplicates before are not deleted. How to avoid it?
v
I'm not sure I understand your question 1. There is only a single 
relation_tuple
table, and the table references types in your SpiceDB schema by denormalizing the type names into that table. I'm not sure I understand what you mean with "separate data". Can you perhaps explain what are you trying to achieve and what's the problem?
k
for example, I have definitions: user, file, folder, org, member.. and for example, table 
relation_tuple
use only for user, file, folder, and some other table, like 
relation_tuple_v2
for org and member
or this is not possible?
v
This is not how SpiceDB works. Why would you want that?
Do you have any scaling concerns with postgres?
k
Nah, question 1 is more understanding the possibilities. Q2 and Q3 is more important for me
v
question 2: I assume you are using Postgres, because a new row is created for each revision of the tuple. SpiceDB does its own MVCC, so it keeps a record of all the changes of a tuple. When delete takes place a row is not delete, but actually created, which simulates a tombstone. Eventually the garbage collector will remove all those tuples once the GC window has elapsed
>question 3: maybe, someone configured Postgres autovacuum_vacuum_scale_factor / autovacuum_vacuum_threshold for the tables with more than billion rows? and can share some recommendations I don't have any recommendations here because we don't operate Postgres in our managed services, RDS has been faring well with the default values
k
I am grateful for your help!
@vroldanbet hey, I have one more question 🥹 Seems GC in our kuber + postgres env doesn't work, and we don't know why... Wt have this params:
Copy code
- name: SPICEDB_DATASTORE_GC_INTERVAL
  value: "30m"
- name: SPICEDB_DATASTORE_GC_MAX_OPERATION_TIME
 value: "30m"
Maybe we configure something wrong?
v
What version of SpiceDB are you using? Which indications do you have that point to GC not working?
k
1.21 and the last 1.29 (two instances are in testing) we have data in DB, that was deleted a very long time ago
v
If you set the log level to debug you should see what the GC does. You could set it to run more frequently just to validate your assumptions
You also need to specify the GC window, which by default ia 24h. So If rows are deleted within the last 24h, the GC won't collect them until 24h have elapsed. I also fixed some issues with GC in like 1.27 or 1.28, so I recommend using the latest version
k
@vroldanbet Hey, here I`m again 🙂 We finally configure 1.29, and it totally works. But we found that GC started clear after memory apped to 100% usage and we are afraid that it could be an OOM killer. Maybe we can do some dipper configuration of GC to start working earlier?
v
SpiceDBs GC is not related to heap GC or runtime memory: its job is to clean old tuple revisions that are past a configure window, by default 24h. SpiceDB automatically sizes caches, based on available memory. So there is some growth expected. How much memory are you providing to the process? If you suspect there is a leak I'd suggest getting a heap dump
PreviousNext
Powered by