Oracle mempercepat strategi berbilang awan: Implikasi industri bagi interkoneksi merentas awan GA, pangkalan data Exascale dan pengembangan serantau

Pecutan strategi berbilang awan Oracle: implikasi industri bagi Interconnect rentas awan GA, pangkalan data Exascale dan pengembangan wilayah

Pendahuluan

Dari Mei hingga Ogos 2026, Oracle berturut-turut mendedahkan satu siri perkembangan pada blog berbilang awan rasminya: Oracle Interconnect for AWS bertukar daripada ketersediaan terhad kepada ketersediaan umum (GA), Oracle AI Database@AWS dan Oracle AI Database@Google Cloud masing-masing memperkenalkan infrastruktur Exascale dan keupayaan storan Exadata Exascale, serta liputan wilayah diperluas kepada 22 wilayah di seluruh dunia. Kemas kini ini kelihatan berselerak, tetapi sebenarnya menunjuk kepada satu tesis yang sama: apabila beban kerja perusahaan secara semula jadi tersebar merentas berbilang awan, bolehkah aset pangkalan data yang dianggap paling sukar dipindahkan berjalan merentas awan tanpa menstruktur semula aplikasi? Bagi CTO dan arkitek awan, ini secara langsung berkaitan dengan struktur kos rangkaian rentas awan, model penggunaan pangkalan data, serta laluan pelaksanaan untuk residensi data dan kesinambungan perniagaan.

1. Latar belakang peristiwa: satu dorongan tertumpu merentas tiga bulan

Idea teras berbilang awan Oracle tidaklah rumit: menjalankan perkhidmatan Oracle Database pada infrastruktur OCI yang ditempatkan berhampiran wilayah awan lain, disampaikan kepada pelanggan melalui rantaian alat yang biasa dan bil disatukan. Pengumuman pada musim panas 2026 ini merupakan pengembangan serentak bagi idea ini dalam dua dimensi: keupayaan dan geografi.| Masa | Peristiwa | Perkara penting | | --- | --- | --- | | 15 Mei | Oracle Interconnect for AWS ketersediaan terhad | Diumumkan oleh Naib Presiden Kanan Pengurusan Produk OCI, Nathan Thomas; matlamatnya ialah menggantikan rangkaian merentas awan binaan sendiri pelanggan dengan sambungan terurus | | 20 Mei | OCI GoldenGate GA pada Oracle AI Database@Google Cloud | Boleh diaktifkan terus dalam konsol Google Cloud dan dibayar menggunakan potongan komitmen Google Cloud | | 20 Mei | Oracle AI Database@AWS dilancarkan di São Paulo | Meliputi pasaran Amerika Selatan, bermula dengan satu zon ketersediaan | | 17 Jun | Ulang tahun pertama Oracle AI Database@AWS | Mengumumkan Autonomous AI Database Serverless GA, infrastruktur Exascale akan datang, pengembangan ke 20 wilayah AWS, peringkat MAA Platinum, dan perjanjian kerjasama strategik jangka panjang (SCA) | | 23 Jun | Penambahan Stockholm dan San Jose | Jumlah wilayah global mencapai 22 | | 29 Julai | Oracle Interconnect for AWS ketersediaan umum | Gelombang pertama di OCI Ashburn dan AWS US East (Virginia Utara), lebih banyak pasangan wilayah akan menyusul kemudian | | 12 Ogos | ExaDB-XS tersedia di Oracle AI Database@AWS | Dibilkan berdasarkan penggunaan ECPU dan storan, mengurangkan kos permulaan, dijual melalui AWS Marketplace | | 14 Ogos | Exadata Exascale memasuki Oracle AI Database@Google Cloud | Pelanggan boleh mengaktifkan kluster VM Exadata dengan storan Exascale |

Perlu diperhatikan bahawa pendedahan pusingan ini tertumpu pada AWS dan Google Cloud. Rentak pengikatan mendalam dengan sebahagian penyedia awan hiperskala terlebih dahulu ini menunjukkan strategi berbilang awan Oracle lebih mirip replikasi keupayaan daripada pengembangan menyeluruh.

2. Analisis Teknikal: Apakah Masalah yang Diselesaikan oleh Tiga Perkara Ini

1. Interkoneksi Merentas Awan: Mengubah Rangkaian daripada Projek kepada PerkhidmatanPada peringkat awal berbilang awan, terdapat dua cara utama untuk menghubungkan dua awan: membenarkan trafik melalui Internet awam, atau membina terowong penyulitan sendiri. Yang pertama mempunyai pendedahan yang jelas dari segi keselamatan, ketersediaan dan kapasiti; yang kedua, walaupun mengecualikan Internet awam, meletakkan semua beban perolehan, konfigurasi dan pengurusan kapasiti kepada pelanggan. Dalam amalan, perusahaan juga perlu menyelaraskan dua model penghalaan yang tidak direka untuk satu sama lain pada masa yang sama, menguruskan kontrak pihak ketiga di kedua-dua belah pihak, dan membina rangkaian binaan sendiri sebelum benar-benar memulakan perniagaan.

Oracle Interconnect for AWS cuba mengubah lapisan ini. Ia menyediakan sambungan peribadi, berkelajuan tinggi dan terurus sepenuhnya antara OCI dan AWS, menggunakan penyulitan IEEE 802.1AE MACsec secara lalai, menggunakan penetapan harga sambungan OCI yang bersatu dan konsisten di seluruh dunia, tidak mengenakan caj pemindahan data, serta disokong secara bersama oleh Oracle dan AWS. Dalam bahasa bukan teknikal: ini bersamaan dengan membina satu lebuh raya khusus antara dua kampus, yang dikendalikan bersama oleh kedua-dua pihak, dan perusahaan tidak lagi perlu membina jalan sendiri, membeli tanah sendiri, atau menyelenggara permukaan jalan sendiri.

2. Exascale: Memisahkan Pengiraan dan Storan, Merendahkan Ambang Kemasukan Exadata

Exadata tradisional lebih menyerupai peranti bersepadu: pengiraan dan storan dikembangkan secara terikat pada nisbah tetap, dan sebaik sahaja perancangan kapasiti tersasar, sama ada berlaku pembaziran atau kekangan. Perubahan utama Exascale ialah memisahkan kedua-duanya.

Di sisi AWS, ExaDB-XS berdasarkan model awan elastik berbilang penyewa Oracle, pelanggan boleh bermula dengan kelompok VM berskala kecil, mengembangkan pengiraan dan storan secara bebas, dan hanya membayar untuk ECPU dan storan yang benar-benar digunakan, sambil menyokong Oracle Database 19c dan Oracle AI Database 26ai, serta menyediakan thin clone dan keupayaan snapshot serta klon berdasarkan redirect-on-write. Di sisi Google Cloud, pelanggan boleh mengaktifkan kelompok VM Exadata dengan storan Exascale, mengembangkan storan secara fleksibel selaras dengan pertumbuhan keperluan pangkalan data, sambil mengekalkan ciri prestasi, ketersediaan dan kebolehpercayaan Exadata khusus.

Bagi pengurus, inti pati perubahan ini ialah peralihan logik perolehan: daripada membeli kapasiti secukupnya secara sekali gus kepada bayar mengikut penggunaan dan pengembangan mengikut pertumbuhan, dengan sifat perbelanjaan modal lebih banyak dialihkan kepada perbelanjaan operasi.

3. OCI GoldenGate: Satah Data dalam Senario Berbilang AwanUntuk menjalankan pangkalan data merentas awan, penyegerakan data tidak dapat dielakkan. Selepas OCI GoldenGate tersedia secara umum di Google Cloud, pelanggan boleh mengaktifkan perkhidmatan terurus ini terus daripada konsol Google Cloud, dan membayar menggunakan komitmen Google Cloud. Ia menyediakan penangkapan data perubahan (CDC) berlatensi rendah dan replikasi masa nyata, menyokong migrasi pangkalan data berisiko rendah, seni bina hibrid dan berbilang awan, peningkatan ketersediaan, serta analitik hampir masa nyata merentas sumber data Oracle dan bukan Oracle.

CDC boleh difahami sebagai lejar perubahan yang sentiasa dikemas kini: setiap perubahan data dalam pangkalan data sumber akan ditangkap dan disegerakkan ke sasaran, bukannya menunggu tetingkap pemprosesan kelompok untuk memindahkan semuanya sekaligus. Ini membolehkan beban operasi, analitik dan AI dibina atas data yang disegerakkan secara berterusan.

3. Analisis Kesan Perusahaan

Struktur kos. ExaDB-XS dibilkan berdasarkan penggunaan ECPU dan storan, sekali gus menurunkan halangan percubaan dan permulaan Exadata; pengskalaan bebas Exascale mengurangkan pembaziran kapasiti rizab untuk beban puncak. Interconnect menggunakan harga sambungan bersatu dan tidak mengenakan caj pemindahan data, menjadikan perbelanjaan rangkaian merentas awan lebih hampir kepada item tetap yang boleh diramal. Perlu diingatkan bahawa jumlah kos merentas awan masih perlu dikira secara menyeluruh dengan menggabungkan peraturan pengebilan kedua-dua pihak; rangkaian hanyalah salah satu komponennya.

Mod penyebaran. Bagi pelanggan Oracle yang sudah menjalankan aplikasi di AWS, tidak perlu membina semula seni bina adalah faktor tarikan utama kemas kini ini: perkhidmatan pangkalan data berjalan pada infrastruktur OCI, namun ditempatkan berdekatan dengan aplikasi AWS. Migrasi berperingkat, seni bina aplikasi teragih, dan pengurangan pergantungan pada rangkaian awam, semuanya adalah senario yang boleh dilaksanakan terus.

Operasi dan sokongan. Penyatuan bil, penggunaan rantaian alat sedia ada, serta antara muka sokongan kolaboratif Oracle dan AWS, mengurangkan geseran organisasi pasukan merentas awan. Namun, kerumitan operasi berbilang awan tidak akan hilang begitu sahaja; ia hanya beralih daripada rangkaian binaan sendiri dan pengurusan kontrak kepada identiti bersekutu, pemantauan dan penentuan lokasi kerosakan.

Keselamatan dan pematuhan. Penyulitan MACsec lalai dan pautan peribadi mengurangkan pendedahan kepada rangkaian awam. Pengembangan wilayah pula merupakan respons langsung kepada isu pematuhan: Stockholm memenuhi keperluan residensi data untuk pasaran Nordik dan Eropah, San Jose mendekati kelompok teknologi dan perniagaan di barat Amerika Syarikat, manakala São Paulo meliputi pasaran Amerika Selatan. Bagi industri yang dikawal selia, pilihan wilayah seperti ini selalunya lebih mempengaruhi keputusan berbanding metrik prestasi.

4. Analisis Persaingan PasaranDari sudut persaingan, ciri terbesar kemas kini ini ialah persaingan secara tidak langsung. Oracle tidak bersaing secara langsung dengan penyedia awan hyperscale dalam lapisan IaaS untuk kuasa pengiraan umum, sebaliknya menganggap pangkalan data sebagai produk yang dihantar merentas awan, membolehkan AWS dan Google Cloud memperoleh lebih banyak beban kerja, manakala Oracle memperoleh penggunaan pangkalan data. Ini lebih menyerupai pakatan pelengkap: perjanjian kerjasama strategik jangka panjang (SCA) yang diumumkan oleh kedua-dua pihak pada 17 Jun telah mengukuhkan lagi hubungan ini. Menurut maklumat rasmi, setahun selepas Oracle AI Database@AWS dilancarkan, terdapat ratusan pelanggan yang menjalankan beban kerja perniagaan kritikal di atasnya.

Pihak yang mungkin mendapat manfaat termasuk: pelanggan perusahaan yang memiliki banyak aset pangkalan data Oracle tetapi ingin mengekalkan aplikasi mereka di awan lain; AWS dan Google Cloud, kerana menampung lebih banyak pangkalan data perusahaan dan beban kerja AI; serta saluran dan penyepadu yang beroperasi dengan AWS Marketplace dan komitmen belanjawan Google Cloud.

Pihak yang mungkin menghadapi tekanan termasuk: penyedia perkhidmatan pihak ketiga yang berfokus pada talian khusus merentas awan yang dibina sendiri dan pengehosan rangkaian, di mana cadangan nilai mereka dicairkan oleh sambungan terurus serta penetapan harga bersepadu; serta naratif bahawa pangkalan data perniagaan mesti ditulis semula sepenuhnya sebagai pangkalan data asli awan – sokongan dwi-versi Exascale dan 19c/26ai membolehkan lebih banyak perusahaan memilih laluan beransur-ansur iaitu berpindah dahulu, kemudian memodenkan. Sehubungan itu, halangan penggantian yang dihadapi oleh vendor pangkalan data asli awan dalam usaha merebut beban kerja sedia ada Oracle juga akan meningkat.

5. Pemerhatian Trend Industri

Fokus persaingan berbilang awan sedang beralih daripada sambungan kepada satah data. Beberapa tahun kebelakangan ini, masalah kejuruteraan berbilang awan terutamanya berkaitan interkoneksi rangkaian; namun keupayaan seperti Exascale, GoldenGate, dan carian vektor AI asli menunjukkan bahawa persaingan peringkat seterusnya berlaku pada bagaimana data mengalir merentas awan dan bagaimana ia digunakan oleh AI.

Arah graviti data telah berbalik. Amalan tradisional adalah memindahkan aplikasi ke sisi data, kini sebaliknya memindahkan perkhidmatan pangkalan data ke sisi aplikasi – pangkalan data berjalan di atas infrastruktur OCI, tetapi ditempatkan berhampiran kawasan AWS atau Google Cloud. Model awan dalam awan ini mungkin menjadi laluan penghijrahan lalai untuk sistem legasi perusahaan.

Kedaulatan dan penyerantauan menjadi ciri produk. Pelaksanaan berturut-turut di Stockholm, São Paulo, dan San Jose menunjukkan bahawa liputan serantau bukan lagi sekadar pengoptimuman kependaman, tetapi infrastruktur pematuhan untuk kediaman data dan kesinambungan perniagaan.

Sempadan antara AI dan pangkalan data terus kabur. Daripada penamaan produk hingga gabungan keupayaan (Autonomous AI Lakehouse, carian vektor AI asli, versi 26ai), Oracle sedang membenamkan keupayaan AI ke dalam lapisan pangkalan data, bukannya membenarkan perusahaan membina platform carian vektor dan ciri yang berasingan di luar pangkalan data.Perubahan-perubahan ini secara bersama menunjuk kepada satu penilaian: multi-cloud sedang berevolusi daripada pilihan seni bina rangkaian kepada pilihan seni bina data, dan persaingan infrastruktur awan lima tahun akan datang akan lebih banyak berkisar tentang kebolehpindahan perkhidmatan data.

CloudTechDaily Insight

Yang paling patut dicatatkan tentang kumpulan pengumuman ini bukanlah mana-mana ciri tertentu, tetapi unit penetapan harga untuk persaingan multi-cloud sedang berubah. Dahulunya, perusahaan menilai multi-cloud berdasarkan lebar jalur talian khusus, trafik keluar dan tenaga kerja operasi; kini yang diketengahkan ialah kos permulaan pangkalan data (dibilkan mengikut ECPU dan storan), cara penetapan harga sambungan antara awan (penetapan harga sambungan bersatu, tiada caj pemindahan data), dan sama ada data boleh digunakan oleh AI secara setempat. Apabila elemen-elemen ini diprodukkan, keputusan multi-cloud berubah daripada masalah kebolehlaksanaan teknikal kepada masalah yang boleh dikira dari segi kewangan dan pematuhan.

Bagi strategi IT perusahaan, terdapat tiga perkara yang patut dimasukkan dalam penilaian. Pertama, pangkalan data merentas awan bukan lagi titik akhir projek migrasi, tetapi boleh menjadi keadaan operasi jangka panjang, dan skop semakan seni bina perlu diselaraskan dengan sewajarnya. Kedua, selepas lapisan sambungan diuruskan secara terurus, kebolehramalan kos merentas awan meningkat, tetapi pergantungan juga semakin mendalam—pelanggan perlu menilai tahap pergantungan terhadap hubungan kerjasama jangka panjang dua pihak dan proses sokongan bersama. Ketiga, pengembangan wilayah membawa pilihan pematuhan dan bukan semata-mata faedah prestasi, industri yang dikawal selia harus memasukkan senarai wilayah ke dalam perancangan kediaman data dan kesinambungan.

Perlu diakui bahawa model ini masih bergantung kepada kesediaan kerjasama dan peta jalan produk penyedia awan hiperskala. Pendedahan pusingan ini tertumpu kepada AWS dan Google Cloud, liputannya masih belum lengkap; prestasi sebenar sokongan bersama dalam mengenal pasti kerosakan dan pembahagian tanggungjawab juga memerlukan lebih banyak pengesahan persekitaran pengeluaran. Oleh itu, pendekatan yang lebih pragmatik ialah: menggunakan kluster berskala kecil ExaDB-XS untuk mengesahkan prestasi dan pengalaman operasi pangkalan data perniagaan kritikal dalam persekitaran merentas awan, menggunakan perintis Interconnect untuk menggantikan rangkaian awam merentas awan sedia ada atau pautan binaan sendiri, dan melengkapkan semakan berganda model kos dan kediaman data sebelum memperluaskan skala.

Dalam jangka sederhana dan panjang, pangkalan data sebagai perkhidmatan merentas awan berkemungkinan besar, seperti pangkalan data terurus pada masa lalu, berubah daripada pengecualian kepada konfigurasi lalai industri. Sebaik sahaja pengeluar pangkalan data terkemuka melengkapkan langkah ini, tekanan untuk pengeluar lain dan penyedia awan mengikuti akan segera muncul—inilah kesan paling mendalam daripada peristiwa ini terhadap industri pengkomputeran awan.

---

Sumber rujukan: Blog rasmi Oracle 《Oracle Multicloud – What's News》, https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog