Oracle vs PostgreSQL. Mengapa memilih Oracle mungkin merupakan keputusan yang cerdas

Membaca banyak artikel di hub tentang migrasi sukses dari Oracle ke PostgreSQL, pembaca yang tidak berpengalaman mungkin mendapat kesan bahwa PostgreSQL tidak lebih buruk, atau bahkan lebih baik daripada Oracle. Dan pilihannya jelas. Dan ratusan ribu perusahaan yang akhirnya membayar miliaran dolar untuk Oracle hanya membuang-buang uang mereka. Tetapi saya akan mencoba meyakinkan Anda, di mana, di mana, dan di perusahaan besar mereka tahu cara menghitung uang. Dan keputusan mereka sama sekali tidak salah.

Tujuan artikel ini adalah untuk menciptakan keraguan dalam jiwa pembaca yang mencoba membuat pilihan antara database relasional yang bekerja dalam mode berversi. Mengapa tepatnya mode versi? Di sini pilihannya tidak besar, tetapi di blocker ada pesaing yang layak dan pilihannya bahkan lebih sulit. (Apa versi DB2 gratis untuk biaya database kecil?)

Saya bukan ahli dalam database Oracle, meskipun saya telah bekerja dengan database ini selama bertahun-tahun dan tidak hanya dengan itu. Yang bisa saya lakukan adalah menggunakan kelebihannya dan mencapai kinerja yang optimal. Selain itu, saya bukan ahli PostgreSQL (saya tidak pernah menggunakannya dalam produksi).

Membaca artikel tentang migrasi yang sukses - Saya mengerti bahwa perusahaan-perusahaan ini bahkan tidak memerlukan Oracle atau database awalnya dipilih secara salah. Mereka hanya menggunakan sebagian kecil dari kemampuan database ini. Hanya karena itu mereka dapat membuat keputusan tentang migrasi dan mengimplementasikannya. Sederhananya, jika Anda menggunakan kekuatan penuh dari database ini, Anda tidak akan pernah memiliki keinginan untuk bermigrasi karena ini sama dengan menulis aplikasi Anda dari awal.

Akhirnya mari kita bicara tentang manfaat kinerja yang disediakan Oracle dan berdasarkan informasi ini Anda akan menemukan jawabannya sendiri.

  1. Partisi (8i) . Partisi - memungkinkan pertumbuhan volume data dengan hampir tidak berpengaruh pada kinerja keseluruhan. Bonus yang bagus dan penting adalah pembagian indeks. Partisi PostgreSQL hanya akan muncul di versi 10. Sebelum ini, warisan (Warisan) adalah hack kotor. Dan kemampuan partisi di Oracle meningkat dengan setiap versi.
  2. Gabungkan (8i) . Ya, ya, Gabung yang sama yang telah ada di MSSQL selama bertahun-tahun (2008) dan yang bahkan tidak akan ada di PostgreSQL 11. Ini memberikan peningkatan kecepatan sepuluh kali lipat dibandingkan dengan operasi tunggal. Ya, saya tahu PostgreSQL mendukung subkueri dan Anda dapat mengimplementasikan semuanya melalui Sisipkan pilih dan pembaruan rumit. Tapi ini jauh dari sama.
  3. RESULT_CACHE (Pilih) (11g). Di Oracle teknologi ini muncul relatif baru. Jika Anda menggunakan teknologi ini dengan bijak - itu memberi keuntungan dalam beberapa hal puluhan atau ratusan kali. Yang utama adalah belajar bagaimana menggunakannya dengan cerdas.
  4. Opsi INMEMORY ( 12 ) Tidak ada analog di PostgreSQL. Pertumbuhan nyata pada beberapa permintaan ratusan kali.
  5. Penyetelan pengoptimal + permintaan . Dimulai dengan 11g, itu berubah menjadi hampir satu klik next-> next di EM. PostgreSQL lebih rumit dengan ini, dan kurangnya analog EM secara keseluruhan sangat tidak nyaman.

    PL / SQL. Ya, saya tahu tentang berbagai bahasa di PostgreSQL. Tetapi Oracle terus meningkatkan bahasa dengan fokus pada kinerja.
    • Kompilasi . Kode sandi terjadi selama save (dalam PostgreSQL selama panggilan pertama dalam sesi + rencana kueri selama eksekusi pertama). Dimulai dengan 10g, Oracle dapat dikompilasi ke dalam kode asli.
    • Native Integer - secara signifikan mempercepat pekerjaan dengan angka. PostgreSQL dapat menggunakan bahasa lain yang lebih cocok (penerjemah). Di Oracle, ini juga bisa diselesaikan menggunakan Java dan C.
    • Mengganti "konteks" PL / SQL. Oracle sangat peduli untuk mengoptimalkan metrik ini, memperbaikinya dari versi ke versi. Untuk mengurangi penundaan Switching the "context" datang dengan BULK COLLECT dan FORALL dan banyak lagi.

      Mengingat keadaan bahasa PostgreSQL, tugas ini sama sekali tidak penting pada tahap ini.
    • Cache Hasil (fungsi) (11g) Dengan penggunaan yang tepat, respons aplikasi secara keseluruhan dapat tumbuh beberapa kali sementara tidak memerlukan banyak usaha. Pada beberapa pertanyaan puluhan kali.

Yah, seperti kata mereka, iblis ada dalam detail, dan Oracle telah mengerjakan detail ini jauh lebih baik. Oracle tidak pernah berhenti memukau dengan setiap versi. Dan tidak masalah basis data yang Anda transfer setelah Oracle - Anda akan selalu memiliki perasaan: Ya ampun, di Oracle sudah lama, atau di Oracle itu lebih baik dilakukan.

Saya hampir yakin bahwa dengan perangkat keras yang sama dan menggunakan semua fitur PostgreSQL dan Oracle, Anda bisa mendapatkan kinerja yang lebih baik, dengan sedikit usaha di ORACLE.

PS Dalam hal apapun tidak menganggap artikel ini sebagai database PR Oracle.

Saya mengerti betul bahwa selalu ada hal-hal yang lebih baik dilakukan di PostgreSQL. Namun secara umum, Oracle di segmen ini dari basis data nomor 1.

Saya secara khusus tidak menyentuh hal-hal yang berkaitan dengan administrasi. Bayangkan saja Anda dapat mentransfer file tanggal dari disk ke disk atau mengembalikan "blok rusak" dalam keadaan Online. Dan Anda dapat melakukan transisi ke server baru tanpa menghentikan database. Dan ini bukan fitur baru. Di Oracle, semuanya jauh lebih baik di sana, dan saya bukan admin DB.

Sebelumnya, di suatu tempat hingga versi 10, admin hampir selalu dibutuhkan. Sekarang kebutuhan untuk admin telah turun secara dramatis, meskipun kualifikasi dari admin sekarang dibutuhkan lebih tinggi. Mungkin, dalam versi 15, konsep "admin" DB akan menjadi sesuatu di masa lalu :)

Ya, dan Pl / SQL lebih bijaksana daripada yang lain, meskipun tentu saja ini bukan C # :). Benar, ini murni individu.

Yah, saya tidak menyentuh pada hal-hal yang kurang membantu dalam kecepatan.

PSS Dan ya, saya hampir tidak ingat semua kemungkinan. Hanya mereka yang ada di "permukaan" Jadi tambahkan komentar. Saya akan memasukkan dalam upd.

Source: https://habr.com/ru/post/id422669/


All Articles