View a markdown version of this page

Pertimbangan untuk menggunakan cluster yang disediakan Amazon Redshift - Amazon Redshift
Pertimbangan Wilayah dan Zona KetersediaanPemeliharaan cluster

Amazon Redshift tidak akan lagi mendukung penggunaan Python UDF setelah 30 Juni 2026. Kami akan mulai menegakkannya secara bertahap. Untuk informasi lebih lanjut tentang detail opsi akhir masa pakai dan migrasi Python, lihat posting blog yang diterbitkan pada 30 Juni 2025.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pertimbangan untuk menggunakan cluster yang disediakan Amazon Redshift

Setelah cluster dibuat, Anda dapat menemukan informasi di bagian ini tentang wilayah di mana fitur tersedia, tugas pemeliharaan, jenis node, dan batas penggunaan.

Pertimbangan Wilayah dan Zona Ketersediaan

Amazon Redshift tersedia di beberapa Wil AWS ayah. Secara default, Amazon Redshift menyediakan cluster Anda di Availability Zone (AZ) yang dipilih secara acak dalam Wil AWS ayah yang Anda pilih. Semua node cluster disediakan di Availability Zone yang sama.

Anda dapat secara opsional meminta Zona Ketersediaan tertentu jika Amazon Redshift tersedia di zona tersebut. Misalnya, jika Anda sudah memiliki instans Amazon EC2 yang berjalan di satu Zona Ketersediaan, Anda mungkin ingin membuat cluster Amazon Redshift di zona yang sama untuk mengurangi latensi. Di sisi lain, Anda mungkin ingin memilih Zona Ketersediaan lain untuk ketersediaan yang lebih tinggi. Amazon Redshift mungkin tidak tersedia di semua Zona Ketersediaan dalam Wil AWS ayah.

Untuk daftar Wilayah yang didukung AWS tempat Anda dapat menyediakan cluster Amazon Redshift, lihat titik akhir Amazon Redshift di. Referensi Umum Amazon Web

Pemeliharaan cluster

Amazon Redshift secara berkala melakukan pemeliharaan untuk menerapkan peningkatan ke cluster Anda. Selama pembaruan ini, cluster Amazon Redshift Anda tidak tersedia untuk operasi normal. Anda memiliki beberapa cara untuk mengontrol cara kami memelihara cluster Anda. Misalnya, Anda dapat mengontrol kapan kami menerapkan pembaruan ke cluster Anda. Anda juga dapat memilih apakah cluster Anda menjalankan versi yang paling baru dirilis, atau versi yang dirilis sebelumnya ke versi yang paling baru dirilis. Terakhir, Anda memiliki opsi untuk menunda pembaruan pemeliharaan non-wajib untuk jangka waktu tertentu.

Jendela pemeliharaan

Amazon Redshift menetapkan jendela pemeliharaan 30 menit secara acak dari blok waktu 8 jam per Wil AWS ayah, yang terjadi pada hari acak dalam seminggu (Senin hingga Minggu, termasuk).

Jendela pemeliharaan default

Daftar berikut menunjukkan blok waktu untuk setiap AWS Wilayah dari mana jendela pemeliharaan default ditetapkan:

  • Wilayah Timur AS (Virginia Utara): 03:00 — 11:00 UTC

  • Wilayah AS Timur (Ohio): 03:00 — 11:00 UTC

  • Wilayah AS Barat (California Utara): 06:00 — 14:00 UTC

  • Wilayah AS Barat (Oregon): 06:00 — 14:00 UTC

  • Wilayah Afrika (Cape Town): 20:00 — 04:00 UTC

  • Wilayah Asia Pasifik (Hong Kong): 13:00 — 21:00 UTC

  • Wilayah Asia Pasifik (Hyderabad): 16:30 — 00:30 UTC

  • Wilayah Asia Pasifik (Jakarta): 15:00 — 23:00 UTC

  • Wilayah Asia Pasifik (Malaysia): 14:00 — 22:00 UTC

  • Wilayah Asia Pasifik (Melbourne): 12:00 — 20:00 UTC

  • Wilayah Asia Pasifik (Mumbai): 16:30 — 00:30 UTC

  • Wilayah Asia Pasifik (Selandia Baru): 10:00 — 18:00 UTC

  • Wilayah Asia Pasifik (Osaka): 13:00 — 21:00 UTC

  • Wilayah Asia Pasifik (Seoul): 13:00 — 21:00 UTC

  • Wilayah Asia Pasifik (Singapura): 14:00 — 22:00 UTC

  • Wilayah Asia Pasifik (Sydney): 12:00 — 20:00 UTC

  • Wilayah Asia Pasifik (Taipei): 14:00 — 22:00 UTC

  • Wilayah Asia Pasifik (Thailand): 15:00 — 23:00 UTC

  • Wilayah Asia Pasifik (Tokyo): 13:00 — 21:00 UTC

  • Wilayah Kanada (Tengah): 03:00 — 11:00 UTC

  • Wilayah Kanada Barat (Calgary): 04:00 — 12:00 UTC

  • Wilayah China (Beijing): 13:00 — 21:00 UTC

  • Wilayah China (Ningxia): 13:00 — 21:00 UTC

  • Wilayah Eropa (Frankfurt): 06:00 — 14:00 UTC

  • Wilayah Eropa (Irlandia): 22:00 — 06:00 UTC

  • Wilayah Eropa (London): 22:00 — 06:00 UTC

  • Wilayah Eropa (Milan): 21:00 — 05:00 UTC

  • Wilayah Eropa (Paris): 23:00 - 07:00 UTC

  • Wilayah Eropa (Stockholm): 23:00 - 07:00 UTC

  • Wilayah Eropa (Zurich): 20:00 — 04:00 UTC

  • Wilayah Israel (Tel Aviv): 20:00 — 04:00 UTC

  • Wilayah Meksiko (Tengah): 04:00 — 12:00 UTC

  • Wilayah Eropa (Spanyol): 21:00 — 05:00 UTC

  • Wilayah Timur Tengah (Bahrain): 13:00 — 21:00 UTC

  • Wilayah Timur Tengah (UEA): 18:00 — 02:00 UTC

  • Wilayah Amerika Selatan (São Paulo): 19:00 — 03:00 UTC

Jika acara pemeliharaan dijadwalkan untuk minggu tertentu, itu dimulai selama jendela pemeliharaan 30 menit yang ditetapkan. Sementara Amazon Redshift melakukan pemeliharaan, ia menghentikan kueri atau operasi lain yang sedang berlangsung. Waktu henti yang dialami selama pemeliharaan terencana tidak dianggap sebagai downtime bulanan atau ketidaktersediaan dalam Perjanjian Tingkat Layanan Amazon Redshift. Sebagian besar pemeliharaan selesai selama jendela pemeliharaan 30 menit, tetapi beberapa tugas pemeliharaan mungkin terus berjalan setelah jendela ditutup. Jika tidak ada tugas pemeliharaan yang harus dilakukan selama jendela pemeliharaan terjadwal, cluster Anda akan terus beroperasi secara normal hingga jendela pemeliharaan terjadwal berikutnya.

Anda dapat mengubah jendela pemeliharaan terjadwal dengan memodifikasi cluster, baik secara terprogram atau dengan menggunakan konsol Amazon Redshift. Anda dapat menemukan jendela pemeliharaan dan mengatur hari dan waktu terjadinya untuk cluster di bawah tab Pemeliharaan.

Adalah mungkin bagi cluster untuk memulai ulang di luar jendela pemeliharaan. Ada beberapa alasan mengapa hal ini dapat terjadi. Satu lagi alasan umum adalah bahwa masalah telah terdeteksi dengan cluster dan operasi pemeliharaan sedang dilakukan untuk mengembalikannya ke keadaan sehat. Untuk informasi selengkapnya, lihat artikel Mengapa cluster Amazon Redshift saya melakukan reboot di luar jendela pemeliharaan? , yang memberikan rincian tentang mengapa ini mungkin terjadi.

Menunda pemeliharaan

Untuk menjadwal ulang jendela pemeliharaan cluster Anda, Anda dapat menunda pemeliharaan hingga 60 hari. Misalnya, jika jendela pemeliharaan cluster Anda diatur ke Rabu 08:30 — 09:00 UTC dan Anda perlu mengakses cluster Anda pada waktu itu, Anda dapat menunda pemeliharaan ke periode waktu berikutnya.

Jika Anda menunda pemeliharaan, Amazon Redshift masih akan menerapkan pembaruan perangkat keras atau pembaruan keamanan wajib lainnya ke cluster Anda. Cluster Anda tidak tersedia selama pembaruan ini.

Jika pembaruan perangkat keras atau pembaruan keamanan wajib lainnya dijadwalkan selama jendela pemeliharaan yang akan datang, Amazon Redshift mengirimi Anda pemberitahuan terlebih dahulu di bawah kategori Ter tunda. Untuk mempelajari lebih lanjut tentang Pember itahuan acara yang tertunda, lihatPemberitahuan acara klaster yang disediakan Amazon Redshift.

Anda juga dapat memilih untuk menerima pemberitahuan acara dari Amazon Simple Notification Service (Amazon SNS). Untuk informasi selengkapnya tentang berlangganan notifikasi acara dari Amazon SNS, lihat. Langganan pemberitahuan acara klaster Amazon Redshift

Jika Anda menunda pemeliharaan cluster Anda, jendela pemeliharaan setelah periode penundaan tidak dapat ditangguhkan.

catatan

Anda tidak dapat menunda pemeliharaan setelah dimulai.

Untuk informasi selengkapnya tentang pemeliharaan cluster, lihat dokumentasi berikut:

Memilih trek pemeliharaan cluster

Saat Amazon Redshift merilis versi cluster baru, cluster Anda diperbarui selama jendela pemeliharaannya. Anda dapat mengontrol apakah cluster Anda diperbarui ke rilis terbaru atau ke rilis sebelumnya.

Track mengontrol versi cluster mana yang diterapkan selama jendela pemeliharaan. Saat Amazon Redshift merilis versi cluster baru, versi tersebut ditetapkan ke trek saat ini, dan versi sebelumnya ditetapkan ke trek trailing.

Untuk informasi tentang trek cluster, lihatTrek untuk klaster yang disediakan Amazon Redshift dan grup kerja tanpa server.

Memahami bagaimana node RG dan RA3 memisahkan komputasi dan penyimpanan

Bagian ini merinci tugas yang tersedia untuk tipe node RG dan RA3, menunjukkan penerapannya ke kumpulan kasus penggunaan dan merinci kelebihannya dibandingkan jenis node yang tersedia sebelumnya.

Keuntungan dan ketersediaan node RG dan RA3

Node RG dan RA3 memberikan keuntungan sebagai berikut:

  • Mereka fleksibel untuk meningkatkan kapasitas komputasi Anda tanpa meningkatkan biaya penyimpanan Anda. Dan mereka menskalakan penyimpanan Anda tanpa menyediakan kapasitas komputasi yang berlebihan.

  • Mereka menggunakan SSD berkinerja tinggi untuk data panas Anda dan Amazon S3 untuk data dingin. Dengan demikian mereka memberikan kemudahan penggunaan, penyimpanan hemat biaya, dan kinerja kueri yang tinggi.

  • Mereka menggunakan jaringan bandwidth tinggi yang dibangun di atas Sistem AWS Nitro untuk lebih mengurangi waktu yang dibutuhkan data untuk diturunkan ke dan diambil dari Amazon S3.

Pertimbangkan untuk memilih jenis node RG dan RA3 dalam kasus ini:

  • Anda memerlukan fleksibilitas untuk menskalakan dan membayar komputasi terpisah dari penyimpanan.

  • Anda menanyakan sebagian kecil dari total data Anda.

  • Volume data Anda tumbuh dengan cepat atau diperkirakan akan tumbuh dengan cepat.

  • Anda menginginkan fleksibilitas untuk mengukur cluster hanya berdasarkan kebutuhan kinerja Anda.

Pertimbangan komputasi kueri danau data — Pada cluster yang disediakan DC2 dan RA3, kueri data lake berjalan di Redshift Spectrum, yang menggunakan server Amazon Redshift khusus yang independen dari cluster Anda. Pada cluster yang disediakan RG, kueri data lake berjalan pada sumber daya komputasi cluster sendiri dan berbagi sumber daya tersebut dengan beban kerja lainnya. Untuk beban kerja dengan penggunaan kueri data lake yang berat, pertimbangkan hal ini saat menentukan ukuran cluster RG Anda.

Untuk menggunakan tipe node RG, Wil AWS ayah Anda harus mendukung RG. Untuk informasi selengkapnya, lihat Ketersediaan tipe node RG di AWS Wilayah.

Untuk menggunakan tipe node RA3, Wil AWS ayah Anda harus mendukung RA3. Untuk informasi selengkapnya, lihat Ketersediaan tipe node RA3 di AWS Wilayah.

penting

Anda dapat menggunakan tipe node ra3.xlplus hanya dengan cluster versi 1.0.21262 atau yang lebih baru. Anda dapat melihat versi cluster yang ada dengan konsol Amazon Redshift. Untuk informasi selengkapnya, lihat Menentukan versi workgroup atau cluster.

Pastikan Anda menggunakan konsol Amazon Redshift baru saat bekerja dengan tipe node RG atau RA3.

Selain itu, untuk menggunakan tipe node RG atau RA3 dengan operasi Amazon Redshift yang menggunakan trek, nilai trek pemeliharaan harus disetel ke versi cluster yang mendukung RG atau RA3. Untuk informasi selengkapnya tentang trek, lihatMemilih trek pemeliharaan cluster.

Pertimbangkan hal berikut saat menggunakan tipe node RA3 simpul tunggal.

  • Produsen dan konsumen berbagi data didukung.

  • Untuk mengubah jenis node, hanya perubahan ukuran klasik yang didukung. Mengubah jenis simpul dengan pengubahan ukuran elastis atau pemulihan snapshot tidak didukung. Skenario berikut didukung:

    • Ubah ukuran klasik dari 1-node dc2.xlarge menjadi 1-node ra3.xlplus, dan sebaliknya.

    • Pengukuran klasik dari 1-node dc2.xlarge menjadi multi-node ra3.xlplus, dan sebaliknya.

    • Pengukuran klasik dari dc2.xlarge multiple-node menjadi 1-node ra3.xlplus, dan sebaliknya.

Bekerja dengan penyimpanan terkelola Amazon Redshift

Dengan penyimpanan terkelola Amazon Redshift, Anda dapat menyimpan dan memproses semua data Anda di Amazon Redshift sambil mendapatkan lebih banyak fleksibilitas untuk menskalakan kapasitas komputasi dan penyimpanan secara terpisah. Anda terus menelan data dengan perintah COPY atau INSERT. Untuk mengoptimalkan kinerja dan mengelola penempatan data otomatis di seluruh tingkatan penyimpanan, Amazon Redshift memanfaatkan pengoptimalan seperti suhu blok data, usia blok data, dan pola beban kerja. Saat diperlukan, Amazon Redshift menskalakan penyimpanan secara otomatis ke Amazon S3 tanpa memerlukan tindakan manual apa pun.

Untuk informasi tentang biaya penyimpanan, lihat harga https://aws.amazon.com/redshift/pricing/ Amazon Redshift.

Mengelola tipe node RG atau RA3

Untuk memanfaatkan memisahkan komputasi dari penyimpanan, Anda dapat membuat atau meningkatkan cluster Anda dengan tipe node RG atau RA3. Untuk menggunakan tipe node RG atau RA3, buat cluster Anda di cloud pribadi virtual ()EC2-VPC.

Untuk mengubah jumlah node cluster Amazon Redshift dengan tipe node RG atau RA3, lakukan salah satu hal berikut:

  • Tambahkan atau hapus node dengan operasi pengubahan ukuran elastis. Dalam beberapa situasi, menghapus node dari cluster RG atau RA3 tidak diperbolehkan dengan pengubahan ukuran elastis. Misalnya, ketika peningkatan jumlah node 2:1 menempatkan jumlah irisan per node pada 32. Untuk informasi selengkapnya, lihat Mengubah ukuran cluster. Jika perubahan ukuran elastis tidak tersedia, gunakan perubahan ukuran klasik.

  • Tambahkan atau hapus node dengan operasi pengubahan ukuran klasik. Pilih opsi ini saat Anda mengubah ukuran ke konfigurasi yang tidak tersedia melalui perubahan ukuran elastis. Perubahan ukuran elastis lebih cepat daripada pengubahan ukuran klasik. Untuk informasi selengkapnya, lihat Mengubah ukuran cluster.

Ketersediaan tipe node RG di AWS Wilayah

Jenis node RG hanya tersedia di Wil AWS ayah berikut:

  • Wilayah AS Timur (Virginia Utara) (us-timur-1)

  • Wilayah AS Timur (Ohio) (us-east-2)

  • Wilayah AS Barat (California Utara) (us-barat-1)

  • Wilayah AS Barat (Oregon) (us-barat-2)

  • Wilayah Afrika (Cape Town) (af-south-1)

  • Wilayah Asia Pasifik (Hong Kong) (ap-east-1)

  • Wilayah Asia Pasifik (Taipei) (ap-east-2)

  • Wilayah Asia Pasifik (Tokyo) (ap-northeast-1)

  • Wilayah Asia Pasifik (Seoul) (ap-northeast-2)

  • Wilayah Asia Pasifik (Osaka) (ap-northeast-3)

  • Wilayah Asia Pasifik (Mumbai) (ap-south-1)

  • Wilayah Asia Pasifik (Hyderabad) (ap-south-2)

  • Wilayah Asia Pasifik (Singapura) (ap-southeast-1)

  • Wilayah Asia Pasifik (Sydney) (ap-southeast-2)

  • Wilayah Asia Pasifik (Jakarta) (ap-southeast-3)

  • Wilayah Asia Pasifik (Melbourne) (ap-southeast-4)

  • Wilayah Asia Pasifik (Malaysia) (ap-southeast-5)

  • Wilayah Asia Pasifik (Thailand) (ap-southeast-7)

  • Wilayah Kanada (Tengah) (ca-central-1)

  • Wilayah Eropa (Frankfurt) (eu-central-1)

  • Wilayah Eropa (Stockholm) (eu-utara-1)

  • Wilayah Eropa (Milan) (eu-selatan-1) (hanya rg.xlarge dan rg.4xlarge)

  • Eropa (Spanyol) Wilayah (eu-south-2)

  • Wilayah Eropa (Irlandia) (eu-west-1)

  • Wilayah Eropa (London) (eu-west-2)

  • Wilayah Eropa (Paris) (eu-west-3)

  • Wilayah Meksiko (Tengah) (mx-central-1)

  • Wilayah Amerika Selatan (São Paulo) (sa-east-1)

  • AWS GovCloud (US-East) (us-gov-east-1)

  • AWS GovCloud (US-West) (us-gov-west-1)

Ketersediaan tipe node RA3 di AWS Wilayah

Jenis node RA3 hanya tersedia di Wil AWS ayah berikut:

  • Wilayah AS Timur (Virginia Utara) (us-timur-1)

  • Wilayah AS Timur (Ohio) (us-east-2)

  • Wilayah AS Barat (California Utara) (us-barat-1)

  • Wilayah AS Barat (Oregon) (us-barat-2)

  • Wilayah Afrika (Cape Town) (af-south-1)

  • Wilayah Asia Pasifik (Hong Kong) (ap-east-1)

  • Wilayah Asia Pasifik (Hyderabad) (ap-south-2)

  • Wilayah Asia Pasifik (Jakarta) (ap-southeast-3)

  • Wilayah Asia Pasifik (Malaysia) (ap-southeast-5)

  • Wilayah Asia Pasifik (Melbourne) (ap-southeast-4)

  • Wilayah Asia Pasifik (Mumbai) (ap-south-1)

  • Wilayah Asia Pasifik (Selandia Baru) (ap-southeast-6)

  • Wilayah Asia Pasifik (Osaka) (ap-northeast-3)

  • Wilayah Asia Pasifik (Seoul) (ap-northeast-2)

  • Wilayah Asia Pasifik (Singapura) (ap-southeast-1)

  • Wilayah Asia Pasifik (Sydney) (ap-southeast-2)

  • Wilayah Asia Pasifik (Taipei) (ap-east-2)

  • Wilayah Asia Pasifik (Thailand) (ap-southeast-7)

  • Wilayah Asia Pasifik (Tokyo) (ap-northeast-1)

  • Wilayah Kanada (Tengah) (ca-central-1)

  • Wilayah Kanada Barat (Calgary) (ca-west-1)

  • Wilayah China (Beijing) (cn-north-1)

  • Wilayah China (Ningxia) (cn-northwest-1)

  • Wilayah Eropa (Frankfurt) (eu-central-1)

  • Wilayah Eropa (Zurich) (eu-central-2)

  • Wilayah Eropa (Irlandia) (eu-west-1)

  • Wilayah Eropa (London) (eu-west-2)

  • Wilayah Eropa (Milan) (eu-south-1)

  • Eropa (Spanyol) Wilayah (eu-south-2)

  • Wilayah Eropa (Paris) (eu-west-3)

  • Wilayah Eropa (Stockholm) (eu-utara-1)

  • Wilayah Israel (Tel Aviv) (il-sentral-1)

  • Wilayah Meksiko (Tengah) (mx-central-1)

  • Wilayah Timur Tengah (Bahrain) (me-south-1)

  • Wilayah Timur Tengah (UEA) (me-central-1)

  • Wilayah Amerika Selatan (São Paulo) (sa-east-1)

  • AWS GovCloud (US-East) (us-gov-east-1)

  • AWS GovCloud (US-West) (us-gov-west-1)

Memutakhirkan ke tipe node RG atau RA3

Untuk memutakhirkan tipe node yang ada ke RG atau RA3, Anda memiliki opsi berikut untuk mengubah jenis node:

  • Pulihkan dari snapshot — Amazon Redshift menggunakan snapshot terbaru dari cluster Anda dan mengembalikannya untuk membuat cluster RG atau RA3 baru. Segera setelah pembuatan cluster selesai (biasanya dalam beberapa menit), node RG atau RA3 siap menjalankan beban kerja produksi penuh Anda. Karena komputasi terpisah dari penyimpanan, data panas dibawa ke cache lokal dengan kecepatan tinggi berkat bandwidth jaringan yang besar. Jika Anda memulihkan dari snapshot DC2 terbaru, RG dan RA3 mempertahankan informasi blok panas dari beban kerja DC2 dan mengisi cache lokalnya dengan blok terpanas. Untuk informasi selengkapnya, lihat Memulihkan cluster dari snapshot.

    Untuk menjaga titik akhir yang sama untuk aplikasi dan pengguna Anda, Anda dapat mengganti nama cluster RG atau RA3 baru dengan nama yang sama dengan cluster DC2 asli. Untuk mengganti nama cluster, ubah cluster di konsol Amazon Redshift atau operasi ModifyCluster API. Untuk informasi selengkapnya, lihat Mengganti nama cluster atau operasi ModifyCluster API di Refer ensi API Amazon Redshift.

  • Elastic resize — mengubah ukuran cluster menggunakan pengubahan ukuran elastis. Saat Anda menggunakan pengubahan ukuran elastis untuk mengubah jenis node, Amazon Redshift secara otomatis membuat snapshot, membuat cluster baru, menghapus cluster lama, dan mengganti nama cluster baru. Operasi pengubahan ukuran elastis dapat dijalankan sesuai permintaan atau dapat dijadwalkan untuk dijalankan di masa mendatang. Anda dapat dengan cepat meningkatkan cluster tipe simpul DC2 yang ada ke RG atau RA3 dengan pengubahan ukuran elastis. Untuk informasi selengkapnya, lihat Ubah ukuran elastis.

catatan

Untuk memigrasikan cluster RA3 yang ada ke rg.xlarge atau rg.4xlarge, cluster sumber Anda harus menjalankan patch versi P201 atau yang lebih baru. Untuk bermigrasi ke rg.large atau rg.12xlarge, cluster sumber Anda harus menjalankan P202 atau yang lebih baru. Cluster DC2 dapat bermigrasi ke RG terlepas dari versi patch.

Tabel berikut menunjukkan rekomendasi saat memutakhirkan ke tipe node RG. (Rekomendasi ini juga berlaku untuk node yang dicadangkan.)

Rekomendasi dalam tabel ini adalah jenis dan ukuran node cluster awal tetapi tergantung pada persyaratan komputasi beban kerja Anda. Untuk memperkirakan kebutuhan Anda dengan lebih baik, pertimbangkan untuk melakukan bukti konsep (POC) yang menggunakan Test Drive untuk menjalankan konfigurasi potensial. Menyediakan cluster untuk gudang data POC Anda alih-alih Redshift Serverless. Untuk informasi selengkapnya tentang melakukan bukti konsep, lihat Mel akukan bukti konsep (POC) untuk Amazon Redshift di Panduan Pengembang Database Amazon Redshift.

Jenis simpul yang ada Jumlah node yang ada Jenis simpul baru yang direkomendasikan Tindakan upgrade

ra3.16xbesar

2—128

rg.12xbesar

Mulailah dengan 1 node rg.12xlarge untuk setiap 1 node ra3.16xlarge 1.

ra3.4xbesar

2-64

rg.4xbesar

Mulailah dengan 3 node rg.4xlarge untuk setiap 4 node ra3.4xlarge 1.

ra3.xlplus

2—32

rg.xbesar

Mulailah dengan 1 node rg.xlarge untuk setiap 1 node ra 3.xlplus 1.

ra3.besar

2—16

rg.besar

Mulailah dengan 1 node rg.large untuk setiap 1 node ra 3.large 1.

dc2.8xbesar

2—15

rg.4xbesar

Mulailah dengan 3 node rg.4xlarge untuk setiap 2 node dc2.8xlarge 1.

dc2.8xbesar

16—128

rg.12xbesar

Mulailah dengan 1 node rg.12xlarge untuk setiap 2 node dc2.8xlarge 1.

dc2.besar

1—3

rg.besar

Mulailah dengan 1 node rg.large untuk setiap 1 node dc 2.large 1.

dc2.besar

4

rg.besar

Mulailah dengan 3 node rg.large 1.

dc2.besar

5—15

rg.xbesar

Mulailah dengan 3 node rg.xlarge untuk setiap 8 node dc 2.large 1.

dc2.besar

16—32

rg.4xbesar

Mulailah dengan 1 node rg.4xlarge untuk setiap 10 node dc2.large 1.

1 Node tambahan mungkin diperlukan tergantung pada persyaratan beban kerja. Tambahkan atau hapus node berdasarkan persyaratan komputasi kinerja kueri yang Anda butuhkan.

Tabel berikut menunjukkan rekomendasi saat memutakhirkan ke tipe node RA3. (Rekomendasi ini juga berlaku untuk node yang dicadangkan.)

Rekomendasi dalam tabel ini adalah jenis dan ukuran node cluster awal tetapi tergantung pada persyaratan komputasi beban kerja Anda. Untuk memperkirakan kebutuhan Anda dengan lebih baik, pertimbangkan untuk melakukan bukti konsep (POC) yang menggunakan Test Drive untuk menjalankan konfigurasi potensial. Menyediakan cluster untuk gudang data POC Anda alih-alih Redshift Serverless. Untuk informasi selengkapnya tentang melakukan bukti konsep, lihat Mel akukan bukti konsep (POC) untuk Amazon Redshift di Panduan Pengembang Database Amazon Redshift.

Jenis simpul yang ada Jumlah node yang ada Jenis simpul baru yang direkomendasikan Tindakan upgrade

dc2.8xbesar

2—15

ra3.4xbesar

Mulailah dengan 2 node ra3.4xlarge untuk setiap 1 node dc2.8xlarge 1.

dc2.8xbesar

16—128

ra3.16xbesar

Mulailah dengan 1 node ra3.16xlarge untuk setiap 2 node dc2.8xlarge 1.

dc2.besar

1—4

ra3.besar

Mulailah dengan 1 node ra3.large untuk setiap 1 node dc 2.large 1.

Mulailah dengan 2 node ra3.large untuk setiap 2 node dc 2.large 1.

Mulailah dengan 3 node ra3.large untuk setiap 3 node dc 2.large 1.

Mulailah dengan 3 node ra3.large untuk setiap 4 node dc 2.large 1.

dc2.besar

5—15

ra3.xlplus

Mulailah dengan 3 node ra3.xlplus untuk setiap 8 node dc2.large 1.

dc2.besar

16—32

ra3.4xbesar

Mulailah dengan 1 node ra3.4xlarge untuk setiap 8 node dc2. large 1, 2.

1 Node tambahan mungkin diperlukan tergantung pada persyaratan beban kerja. Tambahkan atau hapus node berdasarkan persyaratan komputasi kinerja kueri yang Anda butuhkan.

2 Cluster dengan tipe node dc2.large dibatasi hingga 32 node.

Jumlah minimum node untuk beberapa tipe node RA3 adalah 2 node. Pertimbangkan hal ini saat membuat klaster RA3.

Fitur jaringan yang didukung oleh node RG dan RA3

Node RG dan RA3 mendukung kumpulan fitur jaringan yang tidak tersedia untuk jenis node lain. Bagian ini memberikan deskripsi singkat dari setiap fitur dan tautan ke dokumentasi tambahan:

  • Provisioned-cluster Titik akhir VPC — Saat Anda membuat atau memulihkan cluster RG atau RA3, Amazon Redshift menggunakan port dalam rentang 5431-5455 atau 8191-8215. Saat cluster disetel ke port di salah satu rentang ini, Amazon Redshift secara otomatis membuat titik akhir VPC di AWS akun Anda untuk cluster dan melampirkan alamat IP pribadi ke sana. Jika Anda menyetel cluster agar dapat diakses publik, Redshift membuat alamat IP elastis di AWS akun Anda dan melampirkannya ke titik akhir VPC. Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan komunikasi grup keamanan untuk cluster Amazon Redshift atau grup kerja tanpa server Amazon Redshift.

  • Single-subnet Cluster RG atau RA3 — Anda dapat membuat cluster RG atau RA3 dengan satu subnet, tetapi tidak dapat menggunakan fitur pemulihan bencana. Pengecualian terjadi jika Anda mengaktifkan relokasi cluster ketika subnet tidak memiliki beberapa Availability Zones (AZ).

  • Multi-subnet Cluster RG atau RA3 dan grup subnet — Anda dapat membuat cluster RG atau RA3 dengan beberapa subnet dengan membuat grup subnet saat Anda menyediakan cluster di cloud pribadi virtual (VPC) Anda. Grup subnet cluster memungkinkan Anda menentukan satu set subnet di VPC Anda dan Amazon Redshift membuat cluster di salah satunya. Setelah membuat grup subnet, Anda dapat menghapus subnet yang sebelumnya Anda tambahkan, atau menambahkan lebih banyak. Untuk informasi selengkapnya, lihat grup subnet cluster Amazon Redshift.

  • Cross-account atau akses titik akhir lintas VPC — Anda dapat mengakses cluster yang disediakan atau grup kerja Amazon Redshift Serverless dengan menyiapkan titik akhir VPC. Redshift-managed Anda dapat mengaturnya sebagai koneksi pribadi antara VPC yang berisi cluster atau kelompok kerja dan VPC tempat Anda menjalankan alat klien, misalnya. Dengan melakukan ini, Anda dapat mengakses gudang data tanpa menggunakan alamat IP publik dan tanpa merutekan lalu lintas melalui internet. Untuk informasi selengkapnya, lihat Bek erja dengan titik Redshift-managed akhir VPC.

  • Relok asi klaster — Anda dapat memindahkan cluster ke Availability Zone (AZ) lain tanpa kehilangan data ketika ada gangguan layanan. Anda mengaktifkannya di konsol. Untuk informasi selengkapnya, lihat Relokasi cluster.

  • Nama domain kustom — Anda dapat membuat nama domain khusus, juga dikenal sebagai URL khusus, untuk cluster Amazon Redshift Anda. Ini adalah catatan DNS yang mudah dibaca yang merutekan SQL-client koneksi ke titik akhir cluster Anda. Untuk informasi selengkapnya, lihat Nama domain khusus untuk koneksi klien.

Hal-hal yang perlu dipertimbangkan saat memutakhirkan ke node RG

Versi Patch

Untuk bermigrasi dari RA3 ke RG, cluster sumber Anda harus memenuhi versi patch minimum yang diperlukan: P201 untuk rg.xlarge dan rg.4xlarge, dan P202 untuk rg.large dan rg.12xlarge. Cluster DC2 dapat bermigrasi ke RG terlepas dari versi patch. Sebelum bermigrasi, uji beban kerja Anda dengan mengembalikan snapshot ke cluster RG sebelum memindahkan lalu lintas produksi. Untuk detailnya, lihat Tambalan Amazon Redshift 201 dan Tambalan Amazon Redshift 202.

Beban kerja spektrum

Cluster dengan beban kerja yang banyak menggunakan Spectrum mungkin mengamati kinerja kueri yang lebih lambat setelah bermigrasi ke RG. Tidak seperti RA3 dan DC2, RG menjalankan mesin query danau data terintegrasi langsung pada node komputasi cluster daripada pada armada Spectrum terpisah. Jika Anda mengalami penurunan kinerja Spectrum, tingkatkan jumlah node di cluster RG Anda atau migrasikan ke jenis node RG yang lebih besar.

Cluster RG juga mendukung kueri data di bucket Amazon S3 yang terletak di Wilayah yang berbeda, menghilangkan batasan AWS wilayah yang sama yang berlaku untuk cluster RA3 dan DC2 menggunakan Spectrum. Cross-region permintaan dikenakan biaya transfer data tambahan. Untuk informasi selengkapnya, lihat Meng kueri danau data Anda.

Cursor-based beban kerja

Node RG memiliki ukuran kursor yang didukung berbeda dibandingkan dengan RA3 dan DC2. Lihat Batasan Kursor untuk batas ukuran kursor. Jika beban kerja Anda sangat bergantung pada kursor dan Anda mengalami keterbatasan ukuran kursor, bermigrasi ke jenis node RG yang lebih besar — Anda dapat mengurangi jumlah node secara proporsional untuk mempertahankan ukuran dan biaya cluster total yang serupa.

Kelayakan penskalaan konkurensi

Jika cluster Anda menggunakan Penskalaan Konkurensi dan memiliki lebih dari 32 node, dan Anda ingin bermigrasi ke rg.12xlarge, gunakan ressize elastis atau pemulihan snapshot untuk mempertahankan dukungan Penskalaan Konkurensi. Jika cluster Anda memiliki lebih dari 32 node dan Anda melakukan perubahan ukuran klasik menjadi rg.12xlarge, cluster kehilangan dukungan Penskalaan Concurrency. Cluster rg.12xlarge yang baru dibuat dengan lebih dari 32 node tidak mendukung Penskalaan Konkurensi. Untuk informasi selengkapnya, lihat Kandi https://docs.aws.amazon.com/redshift/latest/dg/concurrency-scaling.html#concurrency-scaling-candidates dat penskalaan konkurensi.