1

My question is simple, instead of having one big GSI that maps several fields from many entities that I had to set common name like field_GSI_1, I want to create a separate GSI for each entity that I have.

So, let's consider two scenarios.

Scenario 1, 2 GSIs

My_GSI_1

Partition Key = "pk"
Range Key = "ok"

Projected attributes = "field_gsi_1", "field_gsi_2"

My_GSI_2

Partition Key = "pk"
Range Key = "ok"

Projected attributes = "field_gsi_3", "field_gsi_4"

Scenario 2, 1 GSI

My_GSI_1

Partition Key = "pk"
Range Key = "ok"

Projected attributes = "field_gsi_1", "field_gsi_2", "field_gsi_3", "field_gsi_4"

Question is, will Scenario 1 be more expensive in on-demand mode? Because scenario 1 is much more manageable and organized.

Of course this is only 2 GSIs, but imagine in a real scenario where I can have 10 GSIs vs 1.

Mojimi
  • 2,561
  • 9
  • 52
  • 116

1 Answers1

1

Think of a GSI as another DDB table...

So in scenario 1, for every insert you are paying for 3 writes instead of the 2 in scenario 2.

Same thing applies during updates; if field (1 or 2) and field (3 or 4) change at the same time.

I don't think two GSIs with the same key and different projections makes sense.

Charles
  • 21,637
  • 1
  • 20
  • 44
  • Yeah I wanted to "normalize" the data via GSI, wasn't aware you payed the write for the GSI replication – Mojimi May 03 '19 at 16:44
  • Actually, wouldn't the write only happens if a object has the specified attributes in the GSI? So if I insert an object that only has field_1 and field_2 it will only write to GSI 1 – Mojimi May 03 '19 at 17:50
  • @Mojimi no, sparseness of a GSI applies to the keys...not the projected attributes. – Charles May 03 '19 at 20:17