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

Pilar efisiensi performa

Pilar efisiensi kinerja dari AWS Well-Architected Framework berfokus pada cara mengoptimalkan kinerja sambil menelan atau menanyakan data. Optimalisasi kinerja adalah proses tambahan dan berkelanjutan dari hal-hal berikut:

Pilar efisiensi kinerja memberikan pedoman yang dapat membantu Anda memilih model data berkinerja tinggi. Pilar efisiensi kinerja mencakup praktik terbaik pengoptimalan kueri dan penulisan.

Pilar efisiensi kinerja berfokus pada bidang-bidang utama berikut:

Pemodelan data masuknya dan optimasi kueri

Merancang skema yang efektif sangat penting untuk mengoptimalkan kinerja dan kemampuan kueri data deret waktu di InfluxDB. Mulailah dengan memilih tag dan bidang yang tepat. InfluxDB mengindeks tag, sehingga mesin kueri tidak perlu memindai setiap catatan dalam pengukuran untuk menemukan nilai tag. Ini berarti bahwa kueri tag lebih efisien daripada bidang kueri. Untuk memadatkan dan menyimpan data, mesin penyimpanan mengelompokkan nilai bidang berdasarkan kunci seri, dan kemudian memesan nilai bidang tersebut berdasarkan waktu. Kunci seri didefinisikan oleh pengukuran, kunci tag dan nilai, dan kunci bidang. Untuk informasi selengkapnya tentang desain data, lihat dokumentasi InfluxDB.

Mesin penyimpanan menggunakan format data Time-Structured Merge Tree (TSM). Untuk informasi selengkapnya tentang format data TSM, lihat dokumentasi InfluxDB..

Bayangkan Anda mengumpulkan data (timestamp,host_id,region,cpu,memory,network_in_bytes,network_out_bytes,disk_io) sebagai bagian dari kasus DevOps penggunaan. Tag, termasuk stempel waktu rekaman, menyediakan konteks untuk membantu mengidentifikasi siapa, apa, kapan, dan di mana rekaman. Tag digunakan untuk mengatur dan mengkategorikan data, dan untuk memfilter data sebagai bagian dari kueri.

regionTag host_id dan tag adalah tag yang ideal untuk mengatur dan mengkategorikan kasus DevOps penggunaan. Kolom ini membantu memfilter data untuk host tertentu atau menjalankan analisis berdasarkan kolom wilayah.

Ukuran memberikan dasar untuk melakukan perhitungan matematis (seperti total komputasi, rata-rata, dan perbedaan dalam tingkat perubahan) dan analisis kuantitatif pada data Anda. Oleh karena itucpu,memory,network_in_bytes,network_out_bytes, dan disk_io menangkap metrik penting yang terkait dengan DevOps yang berubah dari waktu ke waktu. Anda dapat menggunakan metrik ini untuk melakukan berbagai analisis, seperti menghitung CPU dan memori di berbagai host. Anda dapat menggunakan nilai metrik ini untuk membuat keputusan berbasis data yang membantu menghindari pemadaman produksi dan melakukan perencanaan infrastruktur.

Kardinalitas adalah kombinasi dari nilai tag yang unik. Bertujuan untuk menjaga kardinalitas serendah mungkin, Jika aplikasi Anda memerlukan pengidentifikasi unik untuk setiap titik data, gunakan nilai bidang alih-alih nilai tag. Ini akan menghasilkan latensi kueri yang jauh lebih baik. Desain skema yang baik dapat mencegah kardinalitas seri tinggi, menghasilkan kueri berkinerja lebih baik. Jika Anda melihat data membaca dan menulis melambat atau Anda ingin mempelajari bagaimana kardinalitas memengaruhi kinerja, lihat dokumentasi Timestream for InfluxDB.

Jika aplikasi Anda memancarkan objek JSON, konversikan ke kolom individual (tag atau bidang), dan muat kolom ke InfluxDB. InfluxDB dirancang untuk data deret waktu, jadi mengatur data Anda dengan kolom individual adalah praktik terbaik untuk memanfaatkan sepenuhnya kemampuan layanan.

Instance OSS InfluxDB v2.7 tunggal mendukung sekitar 20 bucket InfluxDB yang secara aktif ditulis atau ditanyakan di semua organisasi. Lebih dari 20 ember dapat mempengaruhi kinerja. Ada batasan pada beberapa opsi konfigurasi InfluxDB, dan ada beberapa opsi yang dapat Anda konfigurasi berdasarkan kasus penggunaan Anda. Validasi konfigurasi berdasarkan beban kerja aplikasi selama tahap pengujian. Retensi data dikonfigurasi pada tingkat bucket, sehingga data dengan persyaratan retensi data yang berbeda harus disimpan dalam bucket yang berbeda. Untuk informasi selengkapnya tentang opsi konfigurasi, lihat dokumentasi Timestream for InfluxDB.

Simpan data dalam nilai tag atau nilai bidang, bukan di kunci tag, kunci bidang, atau pengukuran. Jika Anda mendesain skema untuk menyimpan data dalam nilai tag dan bidang, kueri Anda akan lebih mudah ditulis dan lebih efisien. Untuk praktik terbaik lainnya tentang pemodelan data, lihat Desain untuk kinerja.

Gunakan tugas InfluxDB untuk melakukan pra-agregat data, memuat data ke dalam pengukuran atau bucket yang berbeda, dan menghasilkan data untuk dasbor dan visualisasi dari mereka.

InfluxDB OSS memperlihatkan /metrics titik akhir yang mengembalikan metrik kinerja, sumber daya, dan penggunaan yang diformat dalam format eksposisi teks biasa Prometheus. Gunakan templat InfluxDB untuk menyiapkan pemantauan dan peringatan untuk mendeteksi masalah secara proaktif, seperti latensi kueri tinggi, penurunan throughput tulis, atau lonjakan penggunaan sumber daya.

Timestream untuk InfluxDB menyediakan penyimpanan Influx IO Included. Memilih ukuran IOPS yang sesuai dapat secara signifikan mempercepat eksekusi kueri. Ini sangat membantu untuk kueri yang perlu memindai sejumlah besar data atau menangani berbagai permintaan. Dalam beberapa situasi, kombinasi penskalaan instance dan peningkatan IOPS mungkin diperlukan untuk mencapai peningkatan kinerja yang Anda inginkan.

Kami merekomendasikan pencocokan lingkungan dev dan prod (kelas instance, tipe penyimpanan, konfigurasi). Uji perubahan di lingkungan yang lebih rendah untuk setiap rilis sebelum pindah ke produksi. Pada volume penyimpanan Influx IO Included, Timestream untuk InfluxDB menyediakan tiga tingkatan penyimpanan yang telah dikonfigurasi sebelumnya dengan IOPS optimal (3.000, 12.000, 16.000) dan throughput yang diperlukan untuk berbagai jenis beban kerja. Sebagian besar kasus penggunaan membutuhkan kurang dari 3.000 IOPS. Pilih 12.000 atau 16.000 hanya jika pengujian kinerja menunjukkan perlunya IOPS tinggi. Untuk informasi selengkapnya, lihat bagian Menyiapkan di dokumentasi Timestream for InfluxDB.

Optimalkan menulis

Untuk mengoptimalkan penulisan ke InfluxDB, kami sarankan untuk menulis data dalam batch 5.000 baris protokol baris per permintaan untuk meminimalkan overhead jaringan. Untuk kinerja yang lebih baik, urutkan tag berdasarkan kunci dalam urutan leksikografi sebelum menulis titik data. Menggunakan presisi waktu yang paling kasar untuk stempel waktu, bukan nanodetik, juga dapat meningkatkan kinerja. Mengaktifkan kompresi gzip adalah cara lain untuk mempercepat penulisan dan mengurangi bandwidth jaringan. Dalam konfigurasi plugin influxdb_v2 output di telegraf.conf file Anda, atur content_encoding opsi kegzip. Menerapkan optimasi ini dapat secara signifikan meningkatkan kinerja dan efisiensi penulisan data ke InfluxDB. Untuk praktik terbaik penulisan InfluxDB lainnya, lihat Optimalkan penulisan ke InfluxDB.

Kinerja penulisan InfluxDB sering terkait erat dengan IOPS yang tersedia. Saat menulis data, InfluxDB perlu melakukan sejumlah besar operasi I/O untuk menyimpan data. Saat Anda meningkatkan IOPS, InfluxDB dapat memproses lebih banyak penulisan per detik.