View a markdown version of this page

Pertimbangan untuk menggunakan kluster yang disediakan Amazon Redshift - Amazon Redshift
Pertimbangan Wilayah dan Availability ZonePemeliharaan cluster

Amazon Redshift tidak akan lagi mendukung pembuatan UDF Python baru mulai Patch 198. UDF Python yang ada akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat posting blog.

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

Pertimbangan untuk menggunakan kluster yang disediakan Amazon Redshift

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

Pertimbangan Wilayah dan Availability Zone

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

Anda dapat meminta Availability Zone tertentu secara opsional jika Amazon Redshift tersedia di zona tersebut. Misalnya, jika Anda sudah menjalankan instans Amazon EC2 di satu Availability Zone, Anda mungkin ingin membuat klaster Amazon Redshift di zona yang sama untuk mengurangi latensi. Di sisi lain, Anda mungkin ingin memilih Availability Zone lain untuk ketersediaan yang lebih tinggi. Amazon Redshift mungkin tidak tersedia di semua Availability Zone dalam suatu AWS Wilayah.

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

Pemeliharaan cluster

Amazon Redshift secara berkala melakukan pemeliharaan untuk menerapkan peningkatan ke klaster Anda. Selama pembaruan ini, klaster Amazon Redshift Anda tidak tersedia untuk operasi normal. Anda memiliki beberapa cara untuk mengontrol cara kami mempertahankan klaster Anda. Misalnya, Anda dapat mengontrol kapan kami menerapkan pembaruan ke kluster Anda. Anda juga dapat memilih apakah klaster 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 AWS Wilayah, terjadi pada hari acak dalam seminggu (Senin hingga Minggu, inklusif).

Jendela pemeliharaan default

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

  • Wilayah AS Timur (Virginia N.): 03:00 - 11:00 UTC

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

  • Wilayah AS Barat (California N.): 06:00 - 14:00 UTC

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

  • Afrika (Cape Town) Wilayah: 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

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

  • Wilayah Tiongkok (Beijing): 13:00 - 21:00 UTC

  • Wilayah Tiongkok (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. Saat Amazon Redshift melakukan pemeliharaan, Amazon Redshift menghentikan kueri atau operasi lain yang sedang berlangsung. Waktu henti yang dialami selama pemeliharaan terencana tidak dianggap sebagai waktu henti bulanan atau tidak tersedianya 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, klaster 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 itu terjadi untuk cluster di bawah tab Maintenance.

Hal ini dimungkinkan untuk sebuah cluster untuk restart di luar jendela pemeliharaan. Ada beberapa alasan ini bisa terjadi. Satu lagi alasan umum adalah bahwa masalah telah terdeteksi dengan cluster dan operasi pemeliharaan sedang dilakukan untuk mengembalikannya ke keadaan sehat. Untuk informasi lebih lanjut, lihat artikel Mengapa cluster Amazon Redshift saya reboot di luar jendela pemeliharaan? , yang memberikan rincian tentang mengapa ini mungkin terjadi.

Menunda pemeliharaan

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

Jika Anda menunda pemeliharaan, Amazon Redshift akan tetap 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 Tertunda. Untuk mempelajari lebih lanjut tentang Pemberitahuan acara 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 klaster Anda, jendela pemeliharaan setelah periode penundaan tidak dapat ditangguhkan.

catatan

Anda tidak dapat menunda pemeliharaan setelah dimulai.

Untuk informasi selengkapnya tentang pemeliharaan klaster, lihat dokumentasi berikut:

Memilih trek pemeliharaan cluster

Saat Amazon Redshift merilis versi cluster baru, klaster Anda diperbarui selama jendela pemeliharaannya. Anda dapat mengontrol apakah klaster 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 trailing track.

Untuk informasi tentang trek klaster, 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 pada kumpulan kasus penggunaan dan merinci keunggulannya dibandingkan jenis node yang tersedia sebelumnya.

Keuntungan dan ketersediaan node RG dan RA3

Node RG dan RA3 memberikan keuntungan sebagai berikut:

  • Mereka fleksibel untuk menumbuhkan 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 untuk data yang akan diturunkan dan diambil dari Amazon S3.

Pertimbangkan untuk memilih tipe 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 berkembang pesat atau diperkirakan akan tumbuh dengan cepat.

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

Pertimbangan komputasi kueri data lake — 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 kluster yang disediakan RG, kueri data lake berjalan pada sumber daya komputasi kluster sendiri dan berbagi sumber daya tersebut dengan beban kerja lainnya. Untuk beban kerja dengan penggunaan kueri data lake yang berat, pertimbangkan ini saat mengukur cluster RG Anda.

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

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

penting

Anda dapat menggunakan tipe node ra3.xlplus hanya dengan versi cluster 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 track, nilai track 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 simpul RA3 simpul tunggal.

  • Produsen dan konsumen Datasharing didukung.

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

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

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

    • Pengubahan ukuran klasik dari multiple-node dc2.xlarge 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 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. Bila diperlukan, Amazon Redshift menskalakan penyimpanan secara otomatis ke Amazon S3 tanpa memerlukan tindakan manual apa pun.

Untuk informasi tentang biaya penyimpanan, lihat harga Amazon Redshift.

Mengelola tipe node RG atau RA3

Untuk memanfaatkan pemisahan komputasi dari penyimpanan, Anda dapat membuat atau memutakhirkan cluster Anda dengan tipe node RG atau RA3. Untuk menggunakan tipe node RG atau RA3, buat cluster Anda di virtual private cloud (). 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 pengubahan ukuran elastis tidak tersedia, gunakan pengubahan ukuran klasik.

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

Ketersediaan tipe simpul RG di AWS Wilayah

Jenis node RG hanya tersedia di AWS Wilayah berikut:

  • Wilayah AS Timur (Virginia N.) (us-east-1)

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

  • Wilayah AS Barat (California N.) (us-west-1)

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

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

  • Wilayah Asia Pasifik (Taipei) (ap-timur-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-tenggara 5)

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

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

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

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

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

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

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

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

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

Ketersediaan tipe simpul RA3 di AWS Wilayah

Jenis node RA3 hanya tersedia di AWS Wilayah berikut:

  • Wilayah AS Timur (Virginia N.) (us-east-1)

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

  • Wilayah AS Barat (California N.) (us-west-1)

  • Wilayah AS Barat (Oregon) (us-west-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-tenggara 5)

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

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

  • Wilayah Asia Pasifik (Selandia Baru) (ap-tenggara 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-timur-2)

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

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

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

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

  • Wilayah Tiongkok (Beijing) (cn-utara-1)

  • Wilayah Tiongkok (Ningxia) (cn-barat laut-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)

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

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

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

  • Wilayah Israel (Tel Aviv) (il-central-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) (kami-gov-timur-1)

  • AWS GovCloud (US-West) (kami-gov-barat-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 untuk menjalankan beban kerja produksi penuh Anda. Karena komputasi terpisah dari penyimpanan, data panas dibawa ke cache lokal dengan kecepatan cepat 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 endpoint 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 ModifyCluster atau operasi API. Untuk informasi selengkapnya, lihat Mengganti nama cluster atau operasi ModifyCluster API di Referensi Amazon Redshift API.

  • Ubah ukuran elastis — 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 klaster lama, dan mengganti nama cluster baru. Operasi pengubahan ukuran elastis dapat dijalankan sesuai permintaan atau dapat dijadwalkan untuk berjalan di masa mendatang. Anda dapat dengan cepat memutakhirkan cluster tipe node DC2 yang ada ke RG atau RA3 dengan pengubahan ukuran elastis. Untuk informasi selengkapnya, lihat Ubah ukuran elastis.

catatan

Untuk memigrasikan cluster RA3 dan DC2 yang ada ke RG, versi cluster sumber Anda harus P201 atau yang lebih baru.

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

Rekomendasi dalam tabel ini adalah memulai jenis dan ukuran node cluster tetapi bergantung 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 pembuktian konsep, lihat Melakukan bukti konsep (POC) untuk Amazon Redshift di Panduan Pengembang Basis Data Amazon Redshift.

Jenis node yang ada Jumlah node yang ada Jenis node baru yang direkomendasikan Upgrade tindakan

ra3.4xl

2-64

rg.4xbesar

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

ra3.xlplus

2—32

rg.xlarge

Mulailah dengan 1 node rg.xlarge untuk setiap 1 node ra3.xlplus 1.

dc2.8xlarge

2—15

rg.4xbesar

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

dc2.large

5—15

rg.xlarge

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

dc2.large

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. Menambahkan atau menghapus node berdasarkan persyaratan komputasi dari 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 memulai jenis dan ukuran node cluster tetapi bergantung 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 pembuktian konsep, lihat Melakukan bukti konsep (POC) untuk Amazon Redshift di Panduan Pengembang Basis Data Amazon Redshift.

Jenis node yang ada Jumlah node yang ada Jenis node baru yang direkomendasikan Upgrade tindakan

dc2.8xlarge

2—15

ra3.4xlarge

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

dc2.8xlarge

16—128

ra3.16xlarge

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

dc2.large

1—4

ra3. besar

Mulailah dengan 1 node ra3.large untuk setiap 1 node dc2.large 1.

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

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

Mulailah dengan 3 node ra3.large untuk setiap 4 node dc2.large 1.

dc2.large

5—15

ra3.xlplus

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

dc2.large

16—32

ra3.4xlarge

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

1 Node tambahan mungkin diperlukan tergantung pada persyaratan beban kerja. Menambahkan atau menghapus node berdasarkan persyaratan komputasi dari 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 cluster RA3.

Fitur jaringan yang didukung oleh node RG dan RA3

Node RG dan RA3 mendukung kumpulan fitur jaringan yang tidak tersedia untuk jenis node lainnya. 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 dalamnya. Jika Anda menyetel klaster agar dapat diakses publik, Redshift akan membuat alamat IP elastis di AWS akun Anda dan menempelkannya ke titik akhir VPC. Untuk informasi selengkapnya, lihat Mengonfigurasi setelan komunikasi grup keamanan untuk klaster Amazon Redshift atau grup kerja Amazon Redshift Tanpa Server.

  • Single-subnet Kluster 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 klaster saat subnet tidak memiliki beberapa Availability Zones (AZ).

  • Multi-subnet Kluster RG atau RA3 dan grup subnet — Anda dapat membuat klaster 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 klaster Amazon Redshift.

  • Cross-account atau akses titik akhir lintas-VPC — Anda dapat mengakses klaster yang disediakan atau grup kerja Amazon Redshift Tanpa Server dengan menyiapkan titik akhir VPC. Redshift-managed Anda dapat mengaturnya sebagai koneksi pribadi antara VPC yang berisi cluster atau workgroup 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 Bekerja dengan titik Redshift-managed akhir VPC.

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

  • Nama domain khusus - Anda dapat membuat nama domain khusus, juga dikenal sebagai URL khusus, untuk klaster 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

P201 adalah versi patch minimum yang diperlukan untuk bermigrasi dari RA3 atau DC2 ke RG. Sebelum melakukan migrasi, verifikasi klaster Anda menggunakan P201 atau yang lebih baru dan uji beban kerja Anda dengan memulihkan snapshot ke klaster RG sebelum memindahkan lalu lintas produksi. Lihat perinciannya di Patch Pergeseran Merah Amazon 201.

Beban kerja spektrum

Cluster dengan beban kerja yang banyak menggunakan Spectrum dapat mengamati kinerja kueri yang lebih lambat setelah bermigrasi ke RG. Tidak seperti RA3 dan DC2, RG menjalankan mesin kueri data lake 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 migrasi ke tipe node RG yang lebih besar.

Cursor-based beban kerja

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