B B
B B

Reputation: 1196

Does an ancestor index consume less storage? About how much less storage would it consume?

Given the fact that indices in app engine occupy significant amounts of storage, I was wondering which setup would save me more storage. I have an ndb model that has more than 100,000 entities. The autogenerated index entries for it in index.yaml are the following:

# index.yaml
indexes:
- kind: MyModel
  properties:
  - name: label
  - name: date

- kind: MyModel
  ancestor: yes
  properties:
  - name: label
  - name: date

I was wondering if keeping both indexes would not significantly impact the amount of storage they use. Or would I be able to save around 50% of the storage they consume by removing one of them? As of now, I can much easily refactor my code to use or not use ancestor queries, so refactoring code is not an issue. I am solely interested in knowing which path would save me more storage.

And if its best to remove one of them, which should I remove that would save me more storage? The index for ancestor queries, or the one that isn't?

Thanks in advance

Upvotes: 1

Views: 36

Answers (1)

glmvrml
glmvrml

Reputation: 1632

Assuming you use autogenerated indexes (index.yaml has 2 modes: auto and manual), and first worked with no ancestors, but later changed your scheme (so new index was automatically added), you should remove first index:

# index.yaml
- kind: MyModel
  ancestor: yes
  properties:
  - name: label
  - name: date

If you create and use entities with no ancestor it is supposed to be None and this index works well. I advice you to take manual control over indexes if you worried about space/speed issues.

Upvotes: 1

Related Questions