Di sini dan selamat datang kembali sekarang, kita akan membahas tentang penawaran yang sangat menarik
di bawah layanan database relasional yang disebut Aurora Australis.
Jadi mari kita lanjutkan dan diskusikan lebih lanjut.
Sekarang, sebelum kita melanjutkan dan membahas tentang Aurora Sartorialist, mari kita lihat pengaturan
tipikal yang diikuti di banyak organisasi.
Jadi dalam pengaturan umum, salah satu pertimbangan utama selama pengaturan database adalah instans DB.
Jadi Anda contoh terlalu kecil.
Jadi, misalnya, katakanlah seorang pengembang membutuhkan instance database untuk lingkungan pengembangan atau mungkin
untuk lingkungan pementasan.
Jadi apa contoh DV yang akan Anda berikan?
Apakah Anda akan memberikannya kepada yang kecil atau sedang untuk yang besar?
Pusat adalah pertimbangan yang sangat penting, namun secara khusus ketika datang ke faktor biaya.
Sekarang, jika beban kerja Anda berubah, Anda dapat mengubah ukuran kelas instans DB.
Jadi katakanlah awalnya Anda telah memberikan kepada yang kecil, tetapi karena beban kerja berubah, maka mungkin Anda dapat
meningkatkan kelas instans GBE menjadi sangat banyak sehingga dapat mendukung lebih banyak beban kerja.
Sekarang, ketika Anda membahas tentang pendekatan tipikal, ada tantangan tertentu yang
hampir semua organisasi hadapi tantangan pertama bahwa beban kerja tidak dapat diprediksi.
Jadi ada periode beban kerja berat yang mungkin hanya berlangsung beberapa menit atau jam dan juga periode
aktivitas ringan yang lama atau bahkan tidak ada aktivitas.
Sekarang, ini khusus berlaku untuk saya.
Kami mendemonstrasikan di Wyoming berkali-kali kami telah melihat bahwa ada perkembangan sebaik Anda dalam permintaan
untuk instance yang sangat besar di gedung ini di Wyoming dan selama akhir pekan dan selama waktu
ketika tidak ada pengujian, instance besar itu tidak melakukan apa-apa tetapi meningkatkan biaya keseluruhan
untuk organisasi.
Dan hal serupa juga berlaku untuk lingkungan produksi, karena di banyak organisasi, beban kerja
keseluruhan dalam lingkungan produksi tetap tidak dapat diprediksi.
Jadi dalam kasus ini, mungkin sulit untuk mengonfigurasi kapasitas yang benar untuk waktu yang tepat.
Ini juga dapat mengakibatkan biaya yang lebih tinggi ketika Anda membayar untuk kapasitas yang tidak digunakan.
Jadi jika kita melihat ke dalam pilihan pelanggan, ada tiga pilihan utama yang tersedia untuk kita.
Salah satunya adalah ketentuan baru untuk puncak.
Jadi meskipun ini bagus, tapi itu akan menyebabkan peningkatan biaya.
Kedua, Anda dapat menyediakan selama kurang dari seminggu yang akan berdampak langsung pada bisnis serta pengguna
akhir.
Yang ketiga adalah Anda terus memantau dan menyesuaikan kapasitas database secara manual.
Namun, ini bukanlah pilihan terbaik karena membutuhkan tenaga ahli serta resiko padam pada poin
ketiga tersebut.
Jadi sekarang datanglah Aurora Australis.
Jadi Aurora Australis secara otomatis meningkatkan dan menurunkan berdasarkan kapasitas yang digunakan beban kerja Anda.
Jadi database Ventor, baik secara otomatis akan dimatikan dan kemudian beban kerja menganggapnya akan secara
otomatis mempercepatnya kembali.
Dan ini sangat menarik di sini.
Jadi ini sangat mirip dengan penskalaan otomatis jika Anda telah menetapkan kapasitas minimum dan maksimum untuk
instans database Anda.
Jadi misalkan saja dari Senin sampai Jumat, para developer yang Anda akan lebih aktif menggunakan instance
DBE.
Namun, sejak Jumat malam, tidak ada sambungan dan tidak ada aktivitas.
Jadi, jika Anda menggunakan Aurora, Tanpa Server, Aurora, Cervalis akan mati secara otomatis selama akhir pekan dan
mulai Senin pagi, tidak ada koneksi lain.
STUTZER Maka database Aurora Cervalis akan kembali online.
Jadi ini bisa dijelaskan lebih baik yang saya ingat ketika undang-undang itu tidak ada, bisa
ditutup atau dijalankan dengan contoh minimal.
Dan ketika beban kerjanya sangat tinggi, ia bahkan dapat menskalakan ke kelas instan yang sangat besar.
Jadi mari kita lanjutkan dan pahami arsitektur Aurora sartorialist agar lebih memahami
cara kerjanya.
Jadi jika Anda tidak memiliki aplikasi, maka Anda memiliki armada server proxy sehingga saldonya bisa lebih rendah.
Kemudian Anda memiliki instans Aurora aktif yang sedang berjalan, Anda memiliki layanan pemantauan dan Anda memiliki kumpulan
Aurora Instan yang hangat.
Jadi aplikasi, setiap kali ingin terhubung ke database, yang terjadi adalah pertama-tama akan terhubung
ke feed proxy.
Dan dari cairan proxy ini, koneksi itu akan dikirim ke instans Aurora aktif yang menjalankan
OIR sekarang, seperti yang kami lihat bahwa instans Aurora bisa.
Naik juga, turun tergantung pada jumlah pinjaman, sehingga layanan pemantauan secara aktif memantau insiden
ini atau lainnya untuk memutuskan apakah operasi peningkatan, pengurangan, atau bahkan penghentian perlu dimulai
atau tidak.
Di sisi kanan, Anda memiliki brankas yang penuh dengan instance lain.
Jadi instans ini didasarkan pada ukuran yang berbeda dan tergantung pada Lord, salah satu instans ini akan
menggantikan instans Aurora yang aktif.
Jadi katakanlah jumlah koneksi dan jumlah beban di Aurora sangat, sangat.
Jadi yang akan terjadi adalah ukuran instans khusus ini akan diganti dengan yang jauh lebih kecil dan lebih kecil.
Jadi tanpa server Aurora ini akan berkurang dan ini pada gilirannya akan menghemat biaya Anda.
Sekarang, mari kita asumsikan bahwa jumlah lalu lintas ke situs web kita meningkat.
Jadi kembali ke hari Senin dan koneksi, beban kerja pesanan meningkat.
Jadi yang akan terjadi adalah layanan monitoring akan memonitor itu dan secara otomatis apa yang akan terjadi, instance
yang lebih kecil akan digantikan oleh instance yang lebih besar.
Jadi itulah yang dilakukannya pada tinjauan tingkat tinggi.
Jadi jika diagram arsitektur, satu contoh adalah sesuatu yang penting untuk kita pahami.
Jadi satu contoh, adanya konflik, contoh yang bisa dengan mudah disapu untuk menambah kapasitas
lingkungan.
Jadi, instans ini berada di berbagai situs yang menyediakan pengawasan pemesan dengan pendekatan yang lebih terperinci tentang
bagaimana responsnya terhadap variasi beban kerja.
Jadi saat ini di dalam kumpulan muntahan, Anda melihat ada beberapa ukuran instans yang tersedia.
Jadi, bergantung pada beban, salah satu instans ini akan berfungsi dengan instans Aurora Anda saat ini dan
pada gilirannya akan dapat melayani lalu lintas yang ada.
Jadi itulah gambaran tingkat tinggi tentang Aurora Sartorialist dan arsitekturnya.
Sekarang, sebelum kita menyimpulkan, mari kita lakukan beberapa hal menarik.
Jadi kita akan memiliki demo cepat yang terkait dengan overlay alamat dan melihat bagaimana tepatnya hal-hal ini bekerja.
Jadi saat ini, saya di Dewan Ide.
Mari kita pergi ke database mereka dan saya sudah memiliki contoh sidewalls Aurora yang sedang berjalan.
Sekarang jika Anda melihat ke dalam ukuran atau ukuran unit kapasitas nol.
Jadi unit kapasitas pada dasarnya adalah kombinasi dari memori plus pemrosesan.
Jadi saat ini unit kapasitas nol.
Sekarang pertanyaan yang muncul adalah mengapa sekarang?
Alasan mengapa unit kapasitas nol adalah karena aurora berada dalam riposted, karena tidak ada koneksi dan
tidak ada beban.
Jadi mari kita lihat itu.
Jadi jika kita pergi ke log dan akhirnya Anda akan melihat bahwa pada waktu tertentu unit kapasitas terbunuh.
Jadi jika Anda melihat penskalaan, hapus klaster dari dua unit kapasitas ke satu unit kapasitas karena alasan ini,
dan alasannya adalah penskalaan otomatis.
Sekarang, sekali lagi, setelah beberapa waktu, ia kembali menskalakan klaster dari satu unit kapasitas menjadi dua
unit kapasitas.
Sekali lagi, alasannya adalah penskalaan otomatis.
Jadi tidak hanya turun, tetapi juga meningkat.
Jadi saat ini kami bermain antara satu dan dua unit kapasitas.
Sekarang, jika Anda melihat urutan penguncian terakhir di sini, ini menyatakan bahwa perdebatan tahun lalu turun dari dua menjadi
satu.
Dan kemudian kluster besar telah dijeda dan kluster debat dijeda.
Jadi sekarang cluster DB terutama karena tidak ada koneksi.
Jadi karena sudah lewat order costing yang mungkin berlaku akan jauh lebih berkurang.
Sekarang, jika saya juga harus menunjukkan ini kepada Anda dalam pemantauan Aurier, mari kita lakukan dari Twila.
Jadi saat ini Anda melihat bahwa setiap kali Aurora Cervalis dimulai, jadi
mereka menciptakan Aurora Cervalis, itu dimulai dengan nilai tertentu atau, Anda tahu, pada waktunya jumlah nilainya menurun.
Jadi jika Anda melihat ke mana ia pergi ke empat, lalu menjadi dua, lalu menjadi satu dan sekarang menjadi nol.
Jadi setelah beberapa waktu, itu adalah nol dan terus menjadi nol.
Baiklah.
Jadi itu berarti terkait dengan kapasitas database SERVERLESS.
Jadi saya harap pada tinjauan tingkat tinggi, Anda memahami konsep Aurora Tanpa Server.
Sekarang, izinkan saya dengan cepat menunjukkan satu hal kepada Anda.
Jadi saat ini, karena database masih dalam pasca bayar, apa jadinya jika ada koneksi baru?
Jadi mari kita coba.
Jadi saya pergi ke data kueri dan mari kita mulai koneksi baru ke server Aurora kami, lebih sedikit contoh dan
lihat apakah itu berhasil atau tidak.
Jadi saya memiliki tes penilaian database yang telah saya gunakan dan mari kita sambungkan ke database.
Jadi kita terintegrasi.
Dan jadi jika Anda cepat melakukan database show ini.
Dan kemudian Anda menjalankannya.
Di output, Anda mendapatkan output terkait database.
Jadi, sekali lagi, mari kita coba.
Jadi mari kita buat database, saya akan menyebutnya lolos dari DB itu dan mari kita lakukan.
Dan kueri telah berhasil dieksekusi, jadi mari kita lakukan lagi database pendek.
Dan sekarang, seperti yang diharapkan, Anda memiliki kemampuan yang tersedia.
Jadi kembali ke Cervalis AutoTrader kami, mari kita pergi ke pemantauan.
Dan sekarang Anda akan melihat bahwa dari nol, keseluruhan unit kapasitas basis data berubah menjadi satu, terutama karena
kami mengeksekusi untuk kueri basis data.
Jadi meskipun aurora berada di masa lalu, segera setelah Anda menjalankan kueri, Anda akan melihat bahwa itu secara otomatis
dimulai.
Dan bahkan dari konsol, kapasitas saat ini, itu menunjukkan bahwa itu adalah satu unit kapasitas dan hal yang sama akan
berlaku ketika Anda pergi ke konsol utama di mana di dalam kasing Anda memiliki satu unit kapasitas
yang tersedia.
Besar.
Jadi saya berharap pada tingkat tinggi di mana Anda memahami konsep dasar Aurora Cervalis bahwa ini akan mengakhiri
video ini.
Dan sampai jumpa di video selanjutnya.