Pertimbangan saat menggunakan integrasi Zero-ETL dengan Amazon Redshift

Gudang data Amazon Redshift target Anda harus memenuhi prasyarat berikut:

Jika Anda menghapus sumber yang merupakan sumber integrasi resmi untuk gudang data Amazon Redshift, semua integrasi terkait akan masuk ke FAILED status. Setiap data yang direplikasi sebelumnya tetap ada di database Amazon Redshift Anda dan dapat ditanyakan.

Database tujuan bersifat read-only. Anda tidak dapat membuat tabel, tampilan, atau tampilan terwujud dalam database tujuan. Namun, Anda dapat menggunakan tampilan terwujud pada tabel lain di gudang data target.

Tampilan terwujud didukung saat digunakan dalam kueri lintas database. Untuk informasi tentang membuat tampilan terwujud dengan data yang direplikasi melalui integrasi Zero-ETL, lihat. Mengkueri data yang direplikasi dengan tampilan yang terwujud

Secara default, Anda dapat menanyakan tabel hanya di gudang data target yang berada di Synced negara bagian. Untuk menanyakan tabel dalam keadaan lain, atur parameter database QUERY_ALL_STATES keTRUE. Untuk informasi tentang pengaturanQUERY_ALL_STATES, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift. Untuk informasi selengkapnya tentang status database Anda, lihat SVV_INTEGRATION_TABLE_STATE di Panduan Pengembang Database Amazon Redshift.

Amazon Redshift hanya menerima UTF-8 karakter, jadi mungkin tidak menghormati kolasi yang ditentukan dalam sumber Anda. Aturan penyortiran dan perbandingan mungkin berbeda, yang pada akhirnya dapat mengubah hasil kueri.

Zero-ETL integrasi dibatasi hingga 50 per target gudang data Amazon Redshift.

Tabel dalam sumber integrasi harus memiliki kunci utama. Jika tidak, tabel Anda tidak dapat direplikasi ke gudang data target di Amazon Redshift.

Untuk informasi tentang cara menambahkan kunci utama ke Amazon Aurora PostgreSQL, lihat Men angani tabel tanpa kunci utama saat membuat integrasi Amazon Aurora PostgreSQL Zero-ETL dengan Amazon Redshift di Blog Database. AWS Untuk informasi tentang cara menambahkan kunci utama ke Amazon Aurora MySQL atau RDS untuk MySQL, lihat Men angani tabel tanpa kunci utama saat membuat integrasi Amazon Aurora MySQL atau Amazon RDS untuk MySQL Zero-ETL dengan Amazon Redshift di Blog Database. AWS

Anda dapat menggunakan pemfilteran data untuk integrasi Aurora Zero-ETL untuk menentukan ruang lingkup replikasi dari cluster Aurora DB sumber ke gudang data Amazon Redshift target. Alih-alih mereplikasi semua data ke target, Anda dapat menentukan satu atau lebih filter yang secara selektif menyertakan atau mengecualikan tabel tertentu agar tidak direplikasi. Untuk informasi selengkapnya, lihat Pemfilteran data untuk integrasi Aurora Zero-ETL dengan Amazon Redshift di Panduan Pengguna Amazon Aurora.

Untuk integrasi Aurora PostgreSQL Zero-ETL dengan Amazon Redshift, Amazon Redshift mendukung maksimal 100 database dari Aurora PostgreSQL. Setiap database mereplikasi dari sumber ke target secara independen.

Zero-ETL integrasi tidak mendukung transformasi saat mereplikasi data dari penyimpanan data transaksional ke Amazon Redshift. Data direplikasi apa adanya dari basis data sumber. Namun, Anda dapat menerapkan transformasi pada data yang direplikasi di Amazon Redshift.

Zero-ETL integrasi berjalan di Amazon Redshift menggunakan koneksi paralel. Ini berjalan menggunakan kredenSIAL pengguna yang membuat database dari integrasi.

Anda dapat mengatur integrasi Zero-ETL untuk mengontrol frekuensi replikasi data ke Amazon Redshift. REFRESH_INTERVAL Untuk informasi selengkapnya, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Setelah Anda membuat database Amazon Redshift dari integrasi Zero-ETL dengan Amazon DynamoDB, status database harus berubah dari Membuat ke Aktif. Ini memulai replikasi data dalam tabel DynamoDB sumber ke tabel Redshift target, yang dibuat di bawah skema publik dari database tujuan (). ddb_rs_customerprofiles_zetl_db

Saat Anda menjatuhkan tabel pada sumber, tabel pada target tidak dijatuhkan, tetapi diubah menjadi DroppedSource status. Anda dapat melepaskan atau mengganti nama tabel dari database Amazon Redshift.

Saat Anda memotong tabel pada sumber, penghapusan dijalankan pada tabel target. Misalnya, jika semua catatan dipotong pada sumber, catatan yang sesuai pada kolom target _record_is_active diubah menjadi. false

Saat Anda menjalankan TRUNCATE tabel SQL pada tabel target, baris riwayat aktif ditandai tidak aktif dengan stempel waktu yang sesuai.

Ketika baris dalam tabel diatur ke tidak aktif, itu dapat dihapus setelah penundaan singkat (sekitar 10 menit). Untuk menghapus baris yang tidak aktif, sambungkan ke database Zero-ETL Anda dengan editor kueri v2 atau klien SQL lainnya.

Anda hanya dapat menghapus baris tidak aktif dari tabel dengan mode riwayat aktif. Misalnya, perintah SQL yang mirip dengan berikut ini hanya menghapus baris yang tidak aktif.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

Ini setara dengan perintah SQL seperti berikut ini.

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

Saat menonaktifkan mode riwayat untuk tabel, semua data historis disimpan ke tabel bernama with <schema>.<table-name>_historical_<timestamp> sementara tabel asli bernama <schema>.<table-name> diperbarui.

Ketika tabel dengan mode riwayat aktif dikecualikan dari replikasi menggunakan filter tabel, semua baris ditetapkan sebagai tidak aktif dan diubah menjadi DroppedSource status. Untuk informasi selengkapnya tentang filter tabel, lihat Pemfilteran data untuk integrasi Aurora Zero-ETL dengan Amazon Redshift di Panduan Pengguna Amazon Aurora.

Mode riwayat hanya dapat dialihkan ke true atau false untuk tabel dalam Synced status.

Tampilan terwujud untuk tabel dengan mode riwayat aktif dibuat sebagai komputasi ulang penuh.

Anda dapat menggunakan pemfilteran data untuk integrasi Aurora dan RDS untuk MySQL Zero-ETL untuk menentukan ruang lingkup replikasi dari cluster DB sumber ke gudang data Amazon Redshift target. Alih-alih mereplikasi semua data ke target, Anda dapat menentukan satu atau lebih filter yang secara selektif menyertakan atau mengecualikan tabel tertentu agar tidak direplikasi. Untuk informasi selengkapnya, lihat Pemfilteran data untuk integrasi Aurora Zero-ETL dengan Amazon Redshift di Panduan Pengguna Amazon Aurora.

Tabel dalam sumber integrasi harus memiliki kunci utama. Jika tidak, tabel Anda tidak dapat direplikasi ke gudang data target di Amazon Redshift.

Untuk informasi tentang cara menambahkan kunci utama ke Amazon Aurora PostgreSQL, lihat Men angani tabel tanpa kunci utama saat membuat integrasi Amazon Aurora PostgreSQL Zero-ETL dengan Amazon Redshift di Blog Database. AWS Untuk informasi tentang cara menambahkan kunci utama ke Amazon Aurora MySQL atau RDS untuk MySQL, lihat Men angani tabel tanpa kunci utama saat membuat integrasi Amazon Aurora MySQL atau Amazon RDS untuk MySQL Zero-ETL dengan Amazon Redshift di Blog Database. AWS

Panjang maksimum tipe data Amazon Redshift VARCHAR adalah 65.535 byte. Ketika konten dari sumber tidak sesuai dengan batas ini, replikasi tidak dilanjutkan dan tabel dimasukkan ke dalam keadaan gagal. Anda dapat mengatur parameter database TRUNCATECOLUMNS TRUE untuk memotong konten agar sesuai dengan kolom. Untuk informasi tentang pengaturanTRUNCATECOLUMNS, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Untuk informasi selengkapnya tentang perbedaan tipe data antara sumber integrasi Zero-ETL dan database Amazon Redshift, lihat Perbedaan tipe data antara Aurora dan Amazon Redshift di Panduan Pengguna Amazon Aurora.

Nama tabel dari DynamoDB yang lebih besar dari 127 karakter tidak didukung.

Data dari integrasi DynamoDB Zero-ETL dipetakan ke kolom tipe data SUPER di Amazon Redshift.

Nama kolom untuk kunci partisi atau kunci pengurutan yang lebih besar dari 127 karakter tidak didukung.

Integrasi Zero-ETL dari DynamoDB hanya dapat memetakan ke satu database Amazon Redshift.

Untuk kunci partisi dan pengurutan, presisi dan skala maksimum adalah (38,18). Tipe data numerik pada DynamoDB mendukung presisi maksimum hingga 38. Amazon Redshift juga mendukung presisi maksimum 38, tetapi desimal default precision/scale pada Amazon Redshift adalah (38,10). Itu berarti nilai nilai skala dapat dipotong.

Untuk integrasi Zero-ETL yang berhasil, atribut individual (terdiri dari nama+nilai) dalam item DynamoDB, tidak boleh lebih besar dari 64 KB.

Saat aktivasi, integrasi Zero-ETL mengekspor tabel DynamoDB lengkap untuk mengisi database Amazon Redshift. Waktu yang dibutuhkan untuk menyelesaikan proses awal ini tergantung pada ukuran tabel DynamoDB. Integrasi Zero-ETL kemudian secara bertahap mereplikasi pembaruan dari DynamoDB ke Amazon Redshift menggunakan ekspor inkremental DynamoDB. Ini berarti data DynamoDB yang direplikasi di Amazon Redshift tetap diperbarui secara otomatis.

Saat ini, latensi minimum untuk integrasi DynamoDB Zero-ETL adalah 15 menit. Anda dapat meningkatkannya lebih lanjut dengan menetapkan bukan nol REFRESH_INTERVAL untuk integrasi Zero-ETL. Untuk informasi selengkapnya, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Nama tabel dan nama kolom dari sumber aplikasi yang lebih besar dari 127 karakter tidak didukung.

Panjang maksimum tipe data Amazon Redshift VARCHAR adalah 65.535 byte. Ketika konten dari sumber tidak sesuai dengan batas ini, replikasi tidak dilanjutkan dan tabel dimasukkan ke dalam keadaan gagal. Anda dapat mengatur parameter database TRUNCATECOLUMNS TRUE untuk memotong konten agar sesuai dengan kolom. Untuk informasi tentang pengaturan, TRUNCATECOLUMNS lihat CREATE DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Untuk informasi selengkapnya tentang perbedaan tipe data antara sumber aplikasi integrasi Zero-ETL dan database Amazon Redshift, lihat Zero-ETL integrasi di Panduan Peng AWS Glue embang.

Latensi minimum untuk integrasi Zero-ETL dengan aplikasi adalah 1 jam. Anda dapat meningkatkannya lebih lanjut dengan menetapkan bukan nol REFRESH_INTERVAL untuk integrasi Zero-ETL. Untuk informasi selengkapnya, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Memulihkan snapshot ke namespace yang berbeda tidak mempertahankan integrasi.

Setelah pemulihan, Amazon Redshift melakukan sinkronisasi ulang penuh untuk semua integrasi Zero-ETL yang dipelihara. Selama sinkronisasi ulang, kinerja penyerapan data mungkin berkurang sementara.

Jika Anda menggunakan mode riwayat pada database target, rekaman versi dari saat snapshot diambil hingga sinkronisasi ulang lengkap selesai tidak diambil. Setelah sinkronisasi ulang, mode riwayat melanjutkan operasi normal. Perilaku ini sama dengan sinkronisasi penuh lainnya. Untuk informasi selengkapnya, lihat Modus riwayat.

Jika integrasi Zero-ETL dibuat setelah snapshot diambil, integrasi memasuki NEEDS_ATTENTION status setelah pemulihan karena database yang sesuai tidak ada di snapshot. Untuk mengatasi masalah ini, Anda dapat memulihkan dari snapshot yang lebih baru yang menyertakan integrasi, atau menghapus integrasi.

Jika integrasi Zero-ETL dihapus setelah snapshot diambil, integrasi tidak dipulihkan. Basis data dari snapshot tetap dan dapat dihapus.

Jika filter tingkat tabel diubah setelah snapshot diambil, target yang dipulihkan menggunakan filter saat ini dari integrasi, bukan filter pada saat snapshot.

Untuk memilih tidak mempertahankan integrasi selama pemulihan, hapus centang pada kotak Maintain Integrations pada halaman restore di, atau jika Anda menggunakan Konsol Manajemen AWS, setel --no-maintain-integration parameter saat memanggil operasi API restore-from-snapshot atau restore-from-recovery-point. AWS CLIhttps://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromRecoveryPoint.html Saat Anda memilih keluar, integrasi masuk ke FAILED status setelah pemulihan. Anda dapat menghapus integrasi dan membuatnya kembali.

Fitur ini berlaku untuk Amazon Redshift Serverless hanya ketika dipulihkan ke namespace tanpa server yang sama. Pemulihan snapshot pada cluster yang disediakan tidak mempertahankan integrasi Zero-ETL.

Perubahan ukuran elastis yang hanya mengubah jumlah node (perubahan ukuran di tempat) tidak mempengaruhi integrasi Zero-ETL. Tabel tetap disinkronkan.

Perubahan ukuran elastis yang mengubah jenis node menyebabkan semua tabel dalam integrasi Zero-ETL pada cluster disinkronisasi ulang. Setiap perubahan ukuran klasik juga memicu sinkronisasi ulang. Hal ini terjadi karena operasi pengubahan ukuran ini untuk sementara mengubah gaya distribusi tabel sementara layanan mendistribusikan ulang data ke konfigurasi cluster baru. Untuk informasi selengkapnya, lihat Mengubah ukuran cluster.

Integrasi tetap aktif, dan sinkronisasi ulang dimulai secara otomatis setelah pengubahan ukuran selesai. Anda tidak perlu mengambil tindakan apa pun.

Saat tabel disinkronkan ulang, Anda tidak dapat menanyainya di Amazon Redshift. Untuk menjaga tabel dapat dikueri selama sinkronisasi ulang, atur QUERY_ALL_STATES parameter ke TRUE pada database tujuan sebelum Anda memulai pengubahan ukuran. Data yang dikembalikan selama sinkronisasi ulang mungkin basi sampai sinkronisasi ulang selesai. Untuk informasi selengkapnya, lihat MEMBUAT DATABASE dan ALTER DATABASE di Panduan Pengembang Database Amazon Redshift.

Sinkronisasi ulang dapat memakan waktu 20-25 menit atau lebih, tergantung pada ukuran database sumber.

Anda dapat memantau keadaan tabel integrasi menggunakan tampilan sistem SVV_INTEGRATION_TABLE_STATE. Tabel menunjukkan ResyncInitiated status ResyncRequired atau sampai sinkronisasi ulang selesai dan mereka kembali ke. Synced