Teknik pengoptimalan biaya untuk Amazon OpenSearch Service - OpenSearch Layanan Amazon
Optimalisasi biaya untuk kluster terkelola OpenSearch Layanan AmazonOptimalisasi biaya untuk OpenSearch Layanan Amazon Tanpa Server

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

Teknik pengoptimalan biaya untuk Amazon OpenSearch Service

Berikut ini adalah beberapa teknik yang paling umum digunakan untuk mengoptimalkan biaya saat menggunakan Amazon OpenSearch Service — baik Managed Cluster maupun Serverless. Karena setiap beban kerja adalah unik, evaluasi strategi ini terhadap pola penggunaan spesifik Anda dan validasi dalam lingkungan pengujian sebelum diterapkan pada produksi.

Optimalisasi biaya untuk kluster terkelola OpenSearch Layanan Amazon

Sumber Berasal - Lewati menyimpan bidang _source

Derived Source adalah fitur pengoptimalan penyimpanan yang menghilangkan overhead penyimpanan _source bidang:

  • OpenSearch menyimpan setiap dokumen yang dicerna dua kali: sekali di _source lapangan (dokumen mentah) dan sekali sebagai bidang yang diindeks untuk pencarian.

  • _sourceBidang saja dapat mengkonsumsi ruang penyimpanan yang signifikan — seringkali 30-50% dari total penyimpanan indeks.

  • Dengan Sumber Derived, Anda melewatkan penyimpanan _source dan sebagai gantinya secara dinamis merekonstruksinya dari bidang yang diindeks saat diperlukan (selama operasi pencarian, dapatkan, mget, indeks ulang, atau pembaruan).

  • Ini adalah opt-in, diaktifkan pada pembuatan indeks menggunakan pengaturan indeks komposit.

  • Tersedia di semua wilayah di mana OpenSearch 3.1 atau yang lebih baru didukung.

Terbaik untuk: Beban kerja analitis dan log di mana Anda tidak perlu sering mengambil dokumen mentah asli tetapi masih perlu mencari dan menggabungkan bidang.

Untuk informasi selengkapnya, lihat dokumentasi sumber terbuka dan pengumuman Apa yang Baru.

OR1 / OR2 / OM2 instance — OpenSearch -keluarga instans yang dioptimalkan

OR1 dan yang lebih baru OR2 dan OM2 instans menggunakan Amazon S3 untuk penyimpanan replika melalui replikasi segmen:

  • OR2: Hingga 26% throughput pengindeksan lebih tinggi dari OR1, 70% lebih banyak dari instans R7g.

  • OM2: Hingga 15% throughput pengindeksan lebih tinggi dari OR1, 66% lebih banyak dari instans M7g.

  • Keduanya menggunakan arsitektur yang sama: EBS lokal untuk penyimpanan primer dan S3 untuk daya tahan.

  • Menghilangkan biaya penyimpanan replika — replika yang disimpan dalam S3 (daya tahan 11 sembilan) alih-alih volume EBS yang mahal.

  • Peningkatan kinerja harga hingga 30% dibandingkan instans generasi sebelumnya.

  • Mendukung snapshot dangkal v2 - snapshot hampir instan tanpa overhead. I/O

Terbaik untuk: Pengindeksan analitik operasional yang berat dan beban kerja analitik log.

Untuk informasi selengkapnya, lihat Pengumuman OR2 dan OM2 Apa yang Baru dan topik panduan OpenSearch Instans yang Dioptimalkan untuk domain OpenSearch Layanan Amazon pengembang.

Rollup indeks — Data deret waktu historis agregat

Rollup indeks merangkum dan mengompres data deret waktu yang lebih lama menjadi interval waktu yang lebih kasar, secara dramatis mengurangi volume penyimpanan:

  • Data IoT/sensor: Simpan data per detik dalam penyimpanan panas untuk periode terakhir; gulung hingga ringkasan per jam atau harian untuk data yang lebih lama.

  • Metrik sistem: Pertahankan metrik terperinci selama 30 hari terakhir; agregat data lama ke dalam ringkasan per jam atau harian.

  • Data log: Pertahankan detail lengkap untuk jendela pemecahan masalah aktif (misalnya, 1 minggu); pertahankan pola kesalahan yang diringkas untuk periode yang lebih lama.

  • Gabungkan dengan kebijakan ISM untuk mengotomatiskan migrasi rollup dan tingkat dalam satu kebijakan siklus hidup.

  • Penghematan yang lebih besar saat menggabungkan dari detik ke jam versus detik ke menit.

Untuk informasi lebih lanjut, lihat posting blog Index Rollups.

Manajemen Status Indeks - Mengotomatiskan siklus hidup data lengkap

Kebijakan ISM mengotomatiskan pergerakan indeks melalui tingkatan penyimpanan dan tindakan siklus hidup:

  • Secara otomatis memigrasikan indeks: Panas UltraWarm ke Dingin untuk Menghapus, berdasarkan usia, ukuran, atau jumlah dokumen.

  • Picu rollup sebelum transisi tingkat untuk mengurangi volume data.

  • Tetapkan kebijakan rollover (misalnya, ketika indeks mencapai 50 GB atau berusia 30 hari) untuk mengontrol pertumbuhan indeks.

  • Mengotomatiskan penggabungan paksa pada indeks hanya-baca untuk merebut kembali penyimpanan dari dokumen yang dihapus.

  • Kombinasikan dengan rollup untuk penghematan maksimum pada kumpulan data deret waktu yang besar.

Instans cadangan — Berkomitmen untuk diskon yang dapat diprediksi

Untuk beban kerja analitis yang stabil dan dapat diprediksi, Instans Cadangan memberikan diskon signifikan atas harga sesuai permintaan:

  • Ketentuan komitmen 1 tahun atau 3 tahun dengan opsi pembayaran No Upfront, Partial Upfront, atau All Upfront.

  • Terbaik untuk node data hot-tier dan node master khusus yang berjalan terus menerus.

  • Gunakan Kalkulator AWS Harga untuk memperkirakan penghematan sebelum melakukan.

  • Instans Cadangan adalah diskon penagihan yang diterapkan pada Instans Sesuai Permintaan — tidak perlu perubahan infrastruktur.

Jenis dan hitungan instans ukuran kanan

Panduan utama dari OpenSearch Well-Architected Lens dan praktik terbaik ukuran yang tepat:

  • Selalu gunakan instance generasi terbaru (misalnya, instans Graviton3 memberikan kinerja hingga 25% lebih baik dibandingkan instans berbasis Graviton2).

  • Gunakan volume EBS gp3 alih-alih gp2 — kinerja yang lebih baik dengan biaya lebih rendah tanpa biaya tambahan.

  • Cocokkan jenis instans dengan beban kerja: dioptimalkan memori untuk penelusuran yang berat, dioptimalkan komputasi untuk pengindeksan yang berat.

  • Evaluasi node pengelola klaster khusus: Hanya diperlukan untuk 3 node data atau lebih; hindari penyediaan ukuran node master yang berlebihan.

  • Monitor CloudWatch metrik untuk mendeteksi penyediaan berlebih: CPU berkelanjutan di bawah 40%, JVM di bawah 50%, dan penyimpanan di bawah 50% adalah tanda-tanda pemborosan.

  • Rentang optimal: CPU 60— 80%, JVM 65-85%, Penyimpanan 70— 85% untuk beban kerja berkelanjutan.

Untuk informasi selengkapnya, lihat posting blog Praktik Terbaik Ukuran Kanan.

Pengoptimalan pecahan - Hindari sharding yang berlebihan

Over-sharding adalah driver biaya tersembunyi - terlalu banyak pecahan kecil membuang CPU, memori, dan tumpukan JVM:

  • Ukuran pecahan yang disarankan: 10—50 GiB per pecahan tergantung pada beban kerja.

  • Tidak lebih dari 25 pecahan per GiB heap Java, tidak lebih dari 1.000 pecahan per node data.

  • Gunakan kebijakan rollover ISM untuk mengontrol pertumbuhan indeks dan menghindari proliferasi pecahan tak terbatas.

  • Kurangi jumlah replika jika daya tahan memungkinkan (OR1/OR2 instance menghilangkan kebutuhan akan replika sepenuhnya).

  • Gunakan force merge pada indeks read-only untuk mengurangi jumlah segmen dan merebut kembali penyimpanan.

Untuk informasi lebih lanjut, lihat Berapa Banyak Pecahan yang Saya Butuhkan?

Nol-ETL/Kueri Langsung dengan Amazon S3

Untuk data yang sangat jarang ditanyakan tetapi harus tetap dapat diakses, Direct Query (Zero-ETL dengan S3) memungkinkan kueri data S3 langsung dari tanpa menelannya: OpenSearch

  • Tidak ada biaya konsumsi - data tetap di S3.

  • Tidak ada biaya penyimpanan hot-tier untuk data arsip.

  • Pay-per-query model komputasi.

  • Mendukung OpenSearch Dasbor untuk visualisasi.

  • Latensi detik atau menit dapat diterima — bukan untuk kasus penggunaan waktu nyata.

Pengambilan sampel dan kompresi saat konsumsi

Mengurangi biaya bahkan sebelum data mencapai OpenSearch:

  • Pengambilan sampel: Hanya mengonsumsi subset representatif dari aliran log volume tinggi (misalnya, 10% dari log debug).

  • Kompresi indeks: Aktifkan codec kompresi terbaik untuk mengurangi jejak penyimpanan.

  • Pemfilteran bidang: Jatuhkan bidang kardinalitas tinggi dan bernilai rendah sebelum pengindeksan (misalnya, jejak tumpukan mentah untuk log lama).

  • Kebijakan retensi: Tentukan jendela retensi maksimum yang selaras dengan persyaratan kepatuhan — jangan pernah menyimpan data tanpa batas waktu.

Hindari biaya dukungan yang diperpanjang - Tetap terkini pada versi mesin

Amazon OpenSearch Service mengenakan biaya tetap per Jam Instans Normalisasi untuk versi engine di Extended Support:

  • Tetap menggunakan versi yang lebih lama dan tidak didukung menimbulkan biaya tambahan di atas biaya instans.

  • Tingkatkan ke versi yang didukung saat ini untuk menghindari biaya Extended Support.

Tag alokasi biaya dan pemantauan CloudWatch

Tata kelola biaya proaktif mencegah pemborosan:

  • Terapkan tag alokasi biaya ke OpenSearch domain untuk pelacakan biaya terperinci per tim atau beban kerja.

  • CloudWatch Atur alarm untuk pemanfaatan penyimpanan, tekanan JVM, dan CPU untuk menangkap penyediaan berlebih lebih awal.

  • Gunakan AWS Cost Explorer untuk mengidentifikasi domain dengan pemanfaatan rendah secara konsisten.

  • Evaluasi Auto-Tune — secara otomatis menyesuaikan ukuran heap JVM dan pengaturan lainnya untuk meningkatkan kinerja dan mengurangi pemborosan sumber daya.

Optimalisasi biaya untuk OpenSearch Layanan Amazon Tanpa Server

Pencarian vektor yang dioptimalkan disk (koleksi vektor)

Pencarian vektor yang dioptimalkan disk adalah salah satu teknik pengurangan biaya yang paling kuat untuk beban kerja vektor. Ini menjalankan pencarian vektor pada sebagian kecil dari biaya mode dalam memori dengan menyimpan hanya vektor terkompresi dalam RAM dan menyimpan vektor presisi penuh pada disk.

Cara kerjanya:

  • Dalam mode standar (in_memory), grafik HNSW penuh dimuat ke dalam RAM - yang menjadi sangat mahal dalam skala.

  • Dalam on_disk mode, hanya vektor terkompresi (terkuantisasi) yang disimpan dalam memori untuk pembuatan kandidat; vektor presisi penuh diambil dari disk hanya untuk fase rescoring akhir (pencarian dua fase).

  • Ini secara dramatis mengurangi kebutuhan RAM sambil mempertahankan kualitas pencarian yang tinggi.

  • on_diskMode default menggunakan kuantisasi biner 32x — mengurangi kebutuhan memori sebesar 97% dibandingkan mode dalam memori.

  • Mendukung tingkat kompresi: 2x (FP16), 4x (byte), 8x, 16x, 32x (biner).

  • Latensi P90 dalam rentang 100—200ms — cocok untuk beban kerja yang tidak memerlukan waktu respons milidetik satu digit.

Tolok ukur penghematan biaya:

Set data Ingat @100 Latensi P90 Pengurangan Biaya
Cohere TREC-RAG 0,94 104ms 83%
Tugas-1M 0,96 7ms 67%
Marco-1M 0,99 7ms 67%

Terbaik untuk: jaringan pipa RAG, pencarian semantik, pengambilan dokumen, dan beban kerja vektor apa pun di mana latensi P90 100-200 ms dapat diterima dan pengurangan biaya adalah prioritas.

catatan

Untuk menerapkan perubahan ini ke data terindeks yang ada, Anda perlu mengindeks ulang. Anda dapat menggunakan alat pipa eksternal seperti untuk mengindeks ulang data ke indeks baru.

Untuk informasi lebih lanjut, lihat posting blog Pencarian Vektor yang Dioptimalkan Disk, posting blog Teknik Kuantisasi, dan. Bekerja dengan koleksi pencarian vektor

Vektor Auto-Optimalkan (koleksi vektor)

Optimalkan otomatis secara otomatis mengevaluasi konfigurasi indeks vektor dan merekomendasikan pertukaran terbaik antara kualitas pencarian, latensi, dan biaya memori — tanpa memerlukan keahlian vektor:

  • Memberikan rekomendasi pengoptimalan dalam waktu kurang dari satu jam.

  • Terintegrasi dengan pipa konsumsi vektor.

  • Dapat dikombinasikan dengan pengindeksan yang dipercepat GPU untuk database vektor berskala miliaran.

Untuk informasi selengkapnya, lihat posting blog Optimalkan Otomatis.

Pengindeksan vektor yang dipercepat GPU (koleksi vektor)

Akselerasi GPU menurunkan pengindeksan vektor HNSW ke tanpa server GPUs, secara dramatis mengurangi waktu dan biaya OCU untuk membangun indeks vektor besar:

  • Waktu pembuatan indeks 6.4x hingga 13.8x lebih cepat dibandingkan dengan pengindeksan khusus CPU.

  • Biaya OCU pengindeksan hingga 75% lebih rendah untuk beban kerja vektor berat tulis.

  • GPUs terpasang secara dinamis - Anda hanya membayar OCUs saat akselerasi GPU aktif.

  • Memungkinkan database vektor berskala miliaran dibangun dalam waktu kurang dari satu jam.

  • Dibebankan secara terpisah sebagai Akselerasi Vektor OCUs.

Terbaik untuk: Konsumsi vektor awal skala besar atau skenario pelatihan ulang model yang sering di mana membangun kembali indeks mahal.

Untuk informasi lebih lanjut, lihat posting blog Akselerasi GPU.

Tetapkan batas OCU maksimum (semua jenis koleksi)

Amazon OpenSearch Service Serverless auto-scale OCUs berdasarkan permintaan. Tanpa batas, biaya bisa melonjak secara tak terduga. Tetapkan batas OCU maksimum di tingkat akun atau per grup koleksi untuk mencegah penskalaan runaway. Sistem menskalakan hingga batas ini selama beban puncak tetapi tidak akan melebihi itu.

Nilai yang diizinkan:

  • Tingkat akun: Nilai apa pun hingga 1.700 OCUs (tidak terbatas pada kelipatan 16).

  • Grup koleksi: 1, 2, 4, 8, 16, dan kelipatan 16 hingga 1.696. OCUs

Pantau CloudWatch metrik (OCUUtilization) untuk mengukur pengaturan OCU maksimum Anda dari waktu ke waktu.

catatan

Jika pemanfaatan mencapai batas OCU maksimum, kinerja dapat menurun secara signifikan meskipun biaya terkandung. Memukul tutup tidak menyelesaikan penyebab yang mendasari lonjakan OCU. Untuk koleksi vektor, akar penyebabnya biasanya adalah vektor dalam memori, yang harus ditangani secara langsung dengan mengoptimalkan pengindeksan vektor, mengurangi ukuran indeks, atau menyetel penarikan dan pertukaran akurasi.

Tip

Mulailah dengan OCU maks konservatif dan tingkatkan hanya ketika CloudWatch menunjukkan pemanfaatan berkelanjutan di dekat tutup. Jika Anda secara konsisten mencapai batas, selidiki akar penyebabnya — terutama penggunaan vektor dalam memori untuk koleksi vektor — daripada hanya menaikkan batas.

Untuk informasi selengkapnya, lihat Mengelola batas kapasitas untuk Amazon Tanpa OpenSearch Server.

Optimalkan periode retensi (koleksi deret waktu)

Kebijakan siklus hidup data secara otomatis menghapus data dari koleksi deret waktu setelah periode retensi tertentu, mencegah pertumbuhan penyimpanan yang tidak terbatas. Hanya koleksi deret waktu yang mendukung kebijakan siklus hidup data — penelusuran dan koleksi vektor tidak.

Jumlah OCU untuk koleksi deret waktu secara langsung didorong oleh berapa banyak data terbaru yang harus disimpan dalam penyimpanan lokal. Koleksi deret waktu hanya menyimpan sebagian data terbaru dalam penyimpanan OCU lokal; data lama diturunkan ke S3, dan jumlah skala yang sesuai: OCUs

OCUs required = max (minimum OCUs, OCUs diperlukan untuk menyimpan data dalam jendela retensi Anda)

Mengkonfigurasi kebijakan siklus hidup data:

  • Tetapkan periode retensi dari 24 jam menjadi 3.650 hari per indeks atau pola indeks.

  • Amazon OpenSearch Service Tanpa Server menghapus data secara otomatis dengan upaya terbaik (biasanya dalam 48 jam atau 10% dari periode retensi).

  • Aturan dapat diterapkan pada tingkat pengumpulan, tingkat pola indeks, atau tingkat indeks individu - aturan yang lebih spesifik diutamakan.

Contoh ukuran:

  • 1 TiB/day konsumsi dengan retensi 30 hari = sekitar 1 TiB data panas = 20 untuk pengindeksan +20 OCUs untuk pencarian. OCUs

  • Mengurangi retensi 7 hari = sekitar 233 GiB data panas = sekitar 4 OCUs untuk pengindeksan+4 untuk pencarian. OCUs

Retensi yang lebih pendek berarti lebih sedikit data panas di penyimpanan lokal, lebih sedikit OCUs yang dibutuhkan, dan tagihan komputasi yang lebih rendah. Sejajarkan periode retensi dengan persyaratan bisnis dan kepatuhan aktual — jangan menyimpan data tanpa batas secara default.

Untuk informasi selengkapnya, lihat Menggunakan kebijakan siklus hidup data dengan Amazon Serverless OpenSearch.

Hindari menyimpan data yang tidak perlu (semua jenis koleksi)

Mengurangi volume data yang dicerna secara langsung mengurangi biaya komputasi (OCUs) dan penyimpanan:

  • Filter bidang saat konsumsi: Gunakan saluran pipa untuk menjatuhkan bidang bernilai rendah sebelum mencapai koleksi.

  • Hindari menelan data duplikat atau redundan: Deduplikat di tingkat pipa.

  • Gunakan pemetaan indeks yang sesuai: Nonaktifkan pengindeksan pada bidang yang disimpan tetapi tidak pernah dicari (). "index": false

  • Untuk koleksi pencarian: Hindari menyimpan gumpalan biner besar atau teks mentah yang mengembang penyimpanan tanpa nilai pencarian.

Grup koleksi untuk beban kerja multi-penyewa (semua jenis koleksi)

Grup Koleksi memungkinkan beberapa koleksi dengan kunci KMS yang berbeda untuk berbagi sumber daya OCU dalam batas keamanan yang sama, secara dramatis mengurangi biaya untuk arsitektur multi-penyewa. Berlaku untuk pelanggan yang menggunakan beberapa kunci KMS per penyewa atau per koleksi:

  • Sebelumnya, setiap kunci KMS unik diperlukan khusus OCUs — membuat isolasi per penyewa menjadi sangat mahal.

  • Dengan grup koleksi, penyewa dengan kunci enkripsi terpisah dapat berbagi kapasitas OCU.

  • Penghematan biaya hingga 90% untuk sejumlah besar beban kerja penyewa yang lebih kecil.

  • Mendukung minimum OCUs (garis dasar dijamin, tidak ada start dingin) dan maksimum OCUs (batas biaya).

  • Koleksi dengan jenis akses jaringan yang berbeda (publik dan VPC) dapat hidup berdampingan dalam grup yang sama.

  • CloudWatch metrik memberikan visibilitas per kelompok ke dalam konsumsi sumber daya dan latensi.

Terbaik untuk: Penyedia SaaS, platform multi-penyewa, atau beban kerja apa pun dengan banyak koleksi kecil yang masing-masing membutuhkan kunci KMS mereka sendiri.

Untuk informasi selengkapnya, lihat posting blog Grup Koleksi, pengumuman Apa yang Baru, danGrup OpenSearch koleksi Amazon Tanpa Server.