Gesaan dan skop
Perkhidmatan ini mempunyai jadual orders yang besar, banyak jadual anak, URL awam, muatan peristiwa (event payloads) dan replika. PostgreSQL 18 menyediakan penjana uuidv7() asli untuk UUID yang disusun mengikut cap masa. Alihkan rekod baharu ke arah UUIDv7 sambil mengekalkan kontrak UUIDv4 sedia ada dan mengelakkan penulisan semula jadual atau kunci sekatan yang lama.
Ini ialah soalan backend kerana kemahiran terasnya ialah migrasi identiti dan skema dalam talian merentasi API, storan dan pengguna tak segerak.
Perkara yang dinilai oleh penemu duga
Pertama, bolehkah anda membezakan format pengecam daripada kebenaran kronologi? UUIDv7 membenamkan susunan masa, tetapi ia bukanlah jujukan komit global yang ketat dan tidak seharusnya menggantikan cap masa perniagaan yang eksplisit.
Kedua, bolehkah anda mengekalkan identiti awam? URL sedia ada, cache, kunci ketakberubahan (idempotency keys), peristiwa dan kunci asing mesti terus berfungsi semasa migrasi.
Ketiga, bolehkah anda mereka bentuk fasa dwi-baca dan dwi-tulis dengan sumber kebenaran (source of truth) yang tidak kabur?
Keempat, bolehkah anda melakukan pengisian semula secara selamat merentasi replika dan rantau tanpa mewujudkan amplifikasi penulisan atau kelambatan replikasi?
Kelima, bolehkah anda mengesahkan lokaliti dan kependaman dan bukannya menganggap bahawa UUIDv7 secara automatik lebih pantas untuk setiap beban kerja?
Soalan untuk dijelaskan terlebih dahulu
- Adakah UUID didedahkan secara luaran, digunakan sebagai kunci utama, atau kedua-duanya?
- Bolehkah klien menerima pengecam baharu, atau adakah UUID lama mesti kekal kanonikal?
- Berapa banyak jadual anak, indeks, peristiwa dan dokumen carian yang merujuk kepada kunci tersebut?
- Versi dan sambungan PostgreSQL manakah yang wujud pada setiap penulis (writer) dan replika?
- Apakah kadar penulisan, SLO kelambatan replikasi dan tarikh akhir pengembalian semula?
- Adakah susunan diperlukan untuk penomboran halaman, paparan audit, atau hanya lokaliti indeks?
Rangka kerja jawapan 30 saat
“Saya akan mengekalkan UUIDv4 sebagai pengecam awam yang stabil, menambah lajur pengganti atau pemetaan UUIDv7, dan melancarkan dwi-tulis sebelum sebarang pengisian semula. Operasi baca menerima salah satu kunci sementara pemetaan selesai; rujukan anak dan peristiwa kekal serasi. Lakukan pengisian semula dalam julat kunci utama yang terhad dengan pemantauan kelambatan dan kunci (lock), kemudian tukar indeks dalaman dan laluan pertanyaan selepas semakan pariti. UUIDv7 membantu lokaliti dan imbasan berorientasikan masa, tetapi cap masa kekal eksplisit. Pengembalian semula ialah pembalikan bendera ciri (feature flag) sehingga semua pengguna terbukti berfungsi.”
Jawapan langkah demi langkah
Langkah 1: Pilih bentuk keserasian
Jangan tukar maksud UUID sedia ada secara senyap. Kekalkan order_id_v4 sebagai kontrak luaran dan tambahkan order_id_v7 berserta kekangan unik, atau perkenalkan kunci dalaman berasingan dengan pemetaan yang tahan lama (durable). Tentukan kunci yang digunakan oleh jadual anak dan peristiwa semasa setiap fasa.
ALTER TABLE orders ADD COLUMN order_id_v7 uuid;
CREATE UNIQUE INDEX CONCURRENTLY orders_order_id_v7_uq
ON orders(order_id_v7) WHERE order_id_v7 IS NOT NULL;Gunakan uuidv7() hanya pada versi PostgreSQL yang menyediakannya; jika tidak, gunakan penjana setara secara konsisten sebelum mendayakan laluan tersebut.
Langkah 2: Lancarkan penulisan terlebih dahulu
Penulisan baharu menjana kedua-dua pengecam dalam satu transaksi dan merekodkan pemetaan tersebut. Penulisan sedia ada yang tidak dapat mengisi lajur baharu kekal sah. Jadikan percubaan semula bersifat idempoten supaya arahan yang berulang tidak dapat mencipta dua pemetaan.
Langkah 3: Tambah penyelesaian dwi-baca
Carian API menerima salah satu pengecam, menyelesaikannya kepada satu susunan kanonikal, dan mengeluarkan ID legasi dalam respons lama. Titik akhir baharu boleh mendedahkan UUIDv7 di sebalik kontrak berversi. Kunci cache harus menyertakan identiti kanonikal yang diselesaikan supaya kedua-dua bentuk tidak bercanggah.
Langkah 4: Isi semula dalam kelompok terhad
Isi semula baris menggunakan kursor yang stabil, transaksi kecil, dan jeda apabila kelambatan replikasi, penantian kunci atau kependaman penulisan melepasi had. Indekskan lajur baharu selepas data mencukupi wujud, menggunakan operasi serentak di mana ia disokong. Jangan kemas kini jadual anak sehingga pemetaan induk adalah tahan lama.
Langkah 5: Pindahkan rujukan dan peristiwa
Pastikan kunci asing anak dan skema peristiwa kekal serasi semasa tempoh pertindihan. Tambahkan medan v7 sebagai pilihan, terbitkan kedua-dua nilai dan kemas kini pengguna sebelum mewajibkan v7. Selaraskan pemetaan yang hilang dan pemetaan pendua sebelum menukar kekangan.
Langkah 6: Tukar laluan akses dalaman
Selepas semakan pariti, halakan cantuman (joins) dalaman dan penomboran halaman ke UUIDv7 di mana lokaliti atau imbasan berorientasikan masa adalah penting. Kekalkan created_at eksplisit untuk susunan perniagaan dan gunakan pemutus seri (tie-breaker); susunan UUIDv7 adalah anggaran pada peringkat aplikasi.
Langkah 7: Sahkan dan pantau
Bandingkan saiz indeks, pemisahan halaman (page splits), tingkah laku cache, kependaman sisipan, kependaman imbasan julat, kelambatan replikasi dan kadar ralat berbanding beban kerja yang sepadan. Periksa bahawa carian v4 dan v7 mengembalikan baris yang sama dan pengguna peristiwa kekal idempoten.
Langkah 8: Hentikan penggunaan hanya selepas tetingkap pengembalian semula
Kekalkan pemetaan, indeks lama dan laluan dwi-baca sehingga setiap klien, alat main semula (replay tool), eksport dan replika melepasi tetingkap migrasi. Alih keluar kekangan lama dalam penggunaan (deploys) berasingan dengan pelan pengembalian semula yang eksplisit.
Contoh jawapan model
“Saya tidak akan menulis semula kontrak UUID awam secara terus (in place). Saya akan menambah lajur UUIDv7 dan pemetaan unik, melaksanakan dwi-tulis, kemudian dwi-baca yang menyelesaikan mana-mana bentuk kepada susunan yang sama. Isi semula dalam transaksi terhad sambil memerhatikan kunci, kelambatan replikasi dan kependaman penulisan. Rujukan anak dan peristiwa membawa kedua-dua ID sehingga setiap pengguna memahami v7. Selepas pengukuran pariti dan lokaliti, tukar cantuman dalaman dan penomboran halaman sambil mengekalkan created_at sebagai medan susunan perniagaan. Bendera ciri boleh membalikkan bacaan dan penulisan sehingga laluan lama dihentikan penggunaannya.”
Kesilapan lazim
- Menggantikan UUID awam serta-merta → pautan dan peristiwa terputus → kekalkan kontrak kanonikal dan pemetaan.
- Menganggap UUIDv7 ialah susunan masa yang ketat → penomboran halaman melangkau atau menyusun semula rekod → gunakan cap masa eksplisit dan pemutus seri.
- Mengisi semula dalam satu transaksi gergasi → kunci dan kelambatan replikasi melonjak → gunakan kelompok terhad.
- Menambah kunci asing sebelum pemetaan wujud → penulisan gagal semasa pertindihan → pindahkan induk, anak, kemudian kekangan.
- Menjana ID pada versi tidak disokong yang bercampur-campur → semantik bercanggah → tetapkan versi atau gunakan satu penjana yang konsisten.
- Mengabaikan percubaan semula → pemetaan pendua muncul → jadikan dwi-tulis bersifat idempoten.
- Menggugurkan v4 terlalu awal → eksport lama dan main semula gagal → tunggu sehingga tetingkap pengembalian semula tamat.
Soalan susulan
Soalan susulan 1: Adakah UUIDv7 pengganti untuk created_at?
Tidak. Ia boleh meningkatkan lokaliti dan menyediakan bit berorientasikan cap masa, tetapi susunan perniagaan memerlukan cap masa eksplisit dan pemutus seri yang deterministik.
Soalan susulan 2: Bolehkah v4 dan v7 berkongsi lajur UUID?
Ya, jenis UUID boleh memegang kedua-dua format, tetapi metadata migrasi, kontrak luaran dan semantik susunan masih memerlukan pelan yang eksplisit.
Soalan susulan 3: Mengapakah dwi-baca dilakukan sebelum menukar penulisan?
Ia membolehkan rekod lama dan baharu diselesaikan secara konsisten sementara pengisian semula dan pelancaran pengguna masih belum selesai.
Soalan susulan 4: Bagaimanakah anda mengawal kadar (throttle) pengisian semula?
Gunakan transaksi terhad dan jeda pada ambang kelambatan replikasi, penantian kunci, CPU atau kependaman penulisan; sambung semula daripada kursor yang tahan lama.
Soalan susulan 5: Apakah yang mesti terkandung dalam peristiwa?
Semasa pertindihan, terbitkan kedua-dua ID atau rujukan pemetaan yang stabil, versikan skema dan kemas kini pengguna sebelum mewajibkan v7.
Soalan susulan 6: Bilakah lajur lama boleh dialih keluar?
Hanya selepas klien, eksport, main semula, replika dan semakan pengembalian semula melepasi tetingkap yang dipersetujui; alih keluar kekangan dan indeks dalam penggunaan berasingan yang boleh dipulihkan.