Kesintisiz DynamoDB Göçleri (Migrations)

SQL'den geliyorsanız, bir göç (migration), her satırı yeniden yazarken tabloyu kilitleyen bir ALTER TABLE'dır. DynamoDB'nin değiştirilecek bir şeması yoktur — öğeler şemasızdır, bu yüzden bir nitelik ya da yeni bir varlık türü eklemek bedavadır.

Zor kısım, yeni verinin hizmet etmek zorunda olduğu erişim deseni ve canlı veriyi, dur-dünya bir yeniden yazma olmadan ona hizmet etmek için yeniden şekillendirmektir.

Bir DynamoDB tablosunu kesintisiz nasıl göç ettirirsiniz?

DynamoDB'nin ALTER TABLE'ı olmadığından göçler tabloyu asla kilitlemez. UpdateTable ile nitelikler, yeni bir anahtar şekli ya da yeni bir GSI'yi çevrimiçi ekler, ardından canlı veriyi aşamalı olarak yeniden şekillendirirsiniz: eski öğeleri okumada tembel ya da kısıtlı bir süpürmeyle geri doldurun ve geçiş süresince her iki biçimi çift yazın. Bayrak-günü bir geçiş yoktur.

• ALTER TABLE yoktur. Öğeler şemasızdır. Bir "göç", nitelikler, yeni bir anahtar şekli ya da yeni bir indeks eklemek demektir — asla sabit bir sütun kümesini yeniden yazmak değil.
• Yeni yazmalar kolaydır; eski öğeler sorundur. Mevcut satırlar yeni nitelikleri taşımaz, bu yüzden geri doldurana kadar her yeni indeks ya da sorgu onları sessizce kaçırır.
• İndeksleri çevrimiçi ekleyin, tembel geri doldurun. UpdateTable, canlı bir tabloda bir GSI kurar; eski öğeleri okumada (tembel) ya da kontrollü bir süpürmeyle geri doldurun — asla bayrak-günü bir geçiş değil.
• Geçiş boyunca çift yazın. Her iki şekil bir arada var olduğu sürece, eski ve yeni biçimi birlikte yazın, böylece hiçbir okuma yolu bayatlamaz.

Bunu bir sütun değil, bir erişim deseni olarak çerçeveleyin

Diyelim ki tek bir tabloda bir SaaS çalışma alanı ürünü işletiyorsunuz. Öğeler PK = "WS#<id>" kullanır ve SK varlık başına aşırı yüklenmiştir:

Şimdi ürün, belgelere yorumlar istiyor, artı yeni bir okuma: "bir üyenin tüm çalışma alanı boyunca yazdığı her yorumu, en yeniden başlayarak listele." İşte o son cümle göçtür. Tek başına yeni bir varlık türü önemsizdir; mevcut anahtarların yanıtlayamayacağı bir sorguya hizmet etmek asıl iştir.

Önce yeni varlık türünü ekleyin

Yorumlar aynı bölümdeki yalnızca yeni öğelerdir — göç töreni yok, yeni tablo yok:

SK begins_with "DOC#2026-04-01#x7#CMT#" ile PK = "WS#a91" üzerinde bir Query zaten bir belgenin yorumlarını listeler. Mevcut belgelere dokunulmaz. Bu yarı ilk gün yayınlanır — aynı bölümün her ikisini neden tuttuğu için bkz. öğe koleksiyonları ve aşırı yüklenmiş anahtarlar.

Yeni sorgu bir GSI ister

"Bir üyeye ait tüm yorumlar, en yeniden başlayarak" temel tablo tarafından hizmet edilemez — memberId ne PK ne de bir SK önekidir. Bu yeni bir indekstir ve onu doğru seçmek kendi kararıdır: bkz. GSI vs LSI (bir LSI tablo oluşturulurken var olmalıdır, bu yüzden canlı bir tabloda bir göç için bir GSI tek seçeneğinizdir).

Genel bir GSI1 ekleyin ve yeni nitelikleri yeni yorum öğelerine yazın:

ScanIndexForward = false ile Query GSI1 WHERE GSI1PK = "MEMBER#u44", üye başına en yeniden başlayan yorumları verir.

İndeksi çevrimiçi kurun

UpdateTable, canlı bir tabloya kesintisiz bir GSI ekler. DynamoDB mevcut öğeleri arka planda indekse geri doldurur; indeks bitene kadar CREATING/geri doldurma bildirir, sonra ACTIVE'e döner (GSI'leri yönetme).

Burada iki tuzak var. İlk olarak, AWS, yeni anahtar eşit olmayan biçimde dağılırsa bir GSI eklemenin temel tablo yazmalarını kısıtlayabileceği konusunda uyarır — onu düşük trafikli bir pencerede ekleyin ve CloudWatch'ı izleyin. İkinci olarak, indeks ACTIVE olduktan sonra bile nihai tutarlıdır; bir yazma bir an için GSI'de görünmeyebilir. Bkz. GSI'ler neden nihai tutarlıdır.

Eski öğeleri geri doldurun

GSI yalnızca GSI1PK/GSI1SK'ye sahip olan öğeleri indeksler. Göç-öncesi yorumlarınız — nitelik var olmadan önce yazılmış — geri doldurma tamamlandıktan sonra bile asla görünmez. Çevrimiçi GSI geri doldurması mevcut öğeleri kopyalar, ama onların üzerinde olmayan nitelikleri icat edemez. Değerleri eklemeniz gerekir.

İki strateji:

Süpürme için, Scan ile sayfalayın ve her eski yorum için indeks niteliklerini koşullu bir UpdateItem ile ekleyin, böylece eşzamanlı bir yazmanın üzerine asla yazmazsınız.

Koşul, niteliğin zaten var olmaması üzerinde korur. attribute_not_exists(GSI1PK) elle yazmak yerine tam ConditionExpression ve UpdateExpression'ı DynamoDB Expression Builder ile oluşturun ve kopyalayın.

Geçiş boyunca çift yazın

Her eski öğe yeni nitelikleri taşıyana kadar, iki şekil bir arada var olur. Yazma yolu, yeni biçimi her yazmada doldurmalıdır — yeni yorumlar ve eski bir tanesine yapılan herhangi bir güncelleme — böylece boşluk yalnızca küçülür.

Doğrulayabileceğiniz bir geri doldurma bitiş koşulu seçin: süpürme tüm tabloyu sayfaladı ya da tembel yol, dönüştürülmemiş öğeler tasarımı gereği bayat olacak kadar uzun çalıştı. Ancak o zaman eski okuma yolunu kaldırın. Bunu atlamak, bir göçün sorguların bir kısmı sessizce kısa sonuçlar döndürürken nasıl "tamamlandığıdır".

Tuzaklar

• Niteliği eklemek ≠ geri dolduruldu. Yeni bir GSI, eski öğeler için boş başlar. Sorguya güvenmeden önce kapsamı doğrulayın.
• Bir anahtarı yerinde değiştirmek bir göç değil — bir yeniden yazmadır. Bir öğenin PK/SK'sini mutasyona uğratamazsınız; yeni anahtar altında yeni bir öğe yazar ve eskisini silersiniz. Arada çift-okuma ile kopyala-sonra-sil olarak planlayın.
• İşlemsel geçiş yok. Tüm tablonun döndüğü bir an yoktur. Her iki şekil de canlıyken güvenli olması için her adımı tasarlayın.

Sonraki adımlar

Yeni anahtarları ve aşırı yüklenmiş koleksiyonları tek tablo tasarımında sağlama kontrolü yapın ve geri doldurmanın tamamlandığını canlı tabloyu sayfalayarak doğrulayın. Tablonuza göz atmak, geri-doldurulmamış öğeleri tespit etmek ve koşullu güncellemeleri kendi verinize karşı çalıştırmak için DynoTable'ı deneyin.