Mana yang lebih baik – Oracle atau Redis atau Bagaimana untuk mewajarkan pilihan platform

"Ini perlu," katanya dengan kuat, tidak bercakap kepada sesiapa. - Ini perlu! Inilah yang dikatakan: tugas utama syarikat adalah untuk membuat keuntungan demi kepentingan pemegang saham. Nah, fikirkanlah! Mereka tidak takut apa-apa!

Yuliy Dubov, "Lesser Evil"

Setelah melihat tajuk sedemikian, anda mungkin telah memutuskan bahawa artikel itu sama ada kebodohan atau provokasi. Tetapi jangan tergesa-gesa membuat kesimpulan: pekerja syarikat besar, terutamanya syarikat dengan penyertaan negara, selalunya perlu membandingkan platform yang berbeza, termasuk yang sama sekali berbeza - contohnya, yang ada dalam tajuk.

Mana yang lebih baik – Oracle atau Redis atau Bagaimana untuk mewajarkan pilihan platform

Sudah tentu, tiada siapa yang membandingkan DBMS dengan cara ini, kerana kekuatan dan kelemahan mereka diketahui umum. Sebagai peraturan, platform yang menyelesaikan beberapa masalah aplikasi tertakluk kepada perbandingan. Dalam artikel saya akan menunjukkan metodologi yang digunakan dalam kes ini, menggunakan contoh pangkalan data sebagai subjek yang biasa kepada pembaca Habr secara langsung. Jadi,

Motivasi

Apabila anda memulakan projek pendidikan atau projek hobi, motivasi untuk memilih platform boleh menjadi sangat pelbagai: "ini adalah platform yang paling saya tahu", "Saya berminat untuk memahami yang ini", "ini adalah dokumentasi terbaik" ... Dalam kes syarikat komersial, kriteria pemilihan adalah sama: berapa banyak yang perlu saya bayar dan apa yang akan saya perolehi untuk wang ini.

Sememangnya, anda mahu membayar lebih sedikit dan mendapat lebih. Walau bagaimanapun, anda perlu memutuskan apa yang lebih penting - membayar lebih sedikit atau mendapat lebih, dan menetapkan pemberat pada setiap nod. Katakan bahawa penyelesaian berkualiti tinggi adalah lebih penting kepada kami daripada penyelesaian yang murah, dan kami akan menetapkan berat 40% pada nod "Kos", dan 60% kepada nod "Peluang".

Mana yang lebih baik – Oracle atau Redis atau Bagaimana untuk mewajarkan pilihan platform

Dalam syarikat besar, sebaliknya biasanya benar - berat kos tidak jatuh di bawah 50%, dan mungkin lebih daripada 60%. Dalam contoh model, semua yang penting ialah jumlah berat nod anak mana-mana nod induk mestilah 100%.

Syarat terputus

laman web db-engines.com Terdapat kira-kira 500 sistem pengurusan pangkalan data yang diketahui. Sememangnya, jika anda memilih platform sasaran daripada begitu banyak pilihan, anda mungkin mendapat artikel ulasan, tetapi bukan projek komersial. Untuk mengurangkan ruang pilihan, kriteria cut-off dirumuskan, dan jika platform tidak memenuhi kriteria ini, maka ia tidak dipertimbangkan.

Kriteria pemotongan mungkin berkaitan dengan ciri teknologi, contohnya:

  • jaminan ASID;
  • model data hubungan;
  • Sokongan bahasa SQL (perhatikan, ini tidak sama dengan "model perhubungan");
  • kemungkinan penskalaan mendatar.

Mungkin terdapat kriteria umum:

  • ketersediaan sokongan komersial di Rusia;
  • sumber terbuka;
  • ketersediaan platform dalam Daftar Kementerian Telekom dan Komunikasi Massa;
  • kehadiran platform dalam beberapa penilaian (contohnya, dalam ratus pertama penilaian db-engines.com);
  • kehadiran pakar dalam pasaran (contohnya, berdasarkan hasil carian untuk nama platform dalam resume di laman web hh.ru).

Lagipun, mungkin terdapat kriteria khusus perusahaan:

  • ketersediaan pakar mengenai kakitangan;
  • keserasian dengan sistem pemantauan X atau sistem sandaran Y, di mana semua sokongan berasaskan...

Perkara yang paling penting ialah terdapat senarai kriteria cut-off. Jika tidak, pasti akan ada pakar (atau "pakar") yang menikmati kepercayaan istimewa daripada pihak pengurusan yang akan berkata "mengapa anda tidak memilih platform Z, saya tahu ia adalah yang terbaik."

Anggaran kos

Kos penyelesaian jelas terdiri daripada kos lesen, kos sokongan dan kos peralatan.

Jika sistem adalah lebih kurang kelas yang sama (contohnya, Microsoft SQL Server dan PostgreSQL), maka untuk kesederhanaan kita boleh mengandaikan bahawa jumlah peralatan untuk kedua-dua penyelesaian adalah lebih kurang sama. Ini akan membolehkan anda tidak menilai peralatan, dengan itu menjimatkan banyak masa dan usaha. Jika anda perlu membandingkan sistem yang sama sekali berbeza (katakan, Oracle vs. Redis), maka adalah jelas bahawa untuk penilaian yang betul adalah perlu untuk melakukan saiz (pengiraan jumlah peralatan). Mengukur sistem yang tidak wujud adalah tugas yang sangat tidak berterima kasih, jadi mereka masih cuba mengelakkan perbandingan sedemikian. Ini mudah dilakukan: dalam keadaan cut-off, kehilangan data sifar dan model hubungan ditulis, atau sebaliknya - beban 50 ribu transaksi sesaat.

Untuk menilai lesen, cukup untuk meminta vendor atau rakan kongsinya untuk kos lesen untuk bilangan teras dan sokongan tetap untuk tempoh tetap. Sebagai peraturan, syarikat sudah mempunyai hubungan yang kukuh dengan vendor perisian, dan jika jabatan operasi pangkalan data tidak dapat menjawab soalan kos sendiri, maka satu huruf sudah cukup untuk mendapatkan maklumat ini.

Vendor yang berbeza mungkin mempunyai metrik pelesenan yang berbeza: mengikut bilangan teras, volum data atau bilangan nod. Pangkalan siap sedia boleh menjadi percuma, atau ia boleh dilesenkan dengan cara yang sama seperti yang utama. Jika sebarang perbezaan dalam metrik ditemui, anda perlu menerangkan pendirian model secara terperinci dan mengira kos lesen untuk pendirian itu.

Perkara penting untuk perbandingan yang betul ialah syarat sokongan yang sama. Sebagai contoh, sokongan Oracle berharga 22% daripada harga lesen setahun, tetapi anda tidak perlu membayar untuk sokongan PostgreSQL. Betul ke nak bandingkan macam ni? Tidak, kerana ralat yang tidak dapat dibetulkan sendiri mempunyai akibat yang berbeza: dalam kes pertama, pakar sokongan akan segera membantu anda membetulkannya, tetapi dalam kes kedua, terdapat risiko melambatkan projek atau masa henti kerja yang telah siap. sistem untuk tempoh yang tidak ditentukan.

Anda boleh menyamakan syarat pengiraan dalam tiga cara:

  1. Gunakan Oracle tanpa sokongan (sebenarnya ini tidak berlaku).
  2. Beli sokongan untuk PostgreSQL - contohnya, daripada Postgres Professional.
  3. Ambil kira risiko yang berkaitan dengan kekurangan sokongan.

Sebagai contoh, pengiraan risiko mungkin kelihatan seperti ini: sekiranya berlaku kegagalan pangkalan data yang membawa maut, masa henti sistem ialah 1 hari perniagaan. Unjuran keuntungan daripada menggunakan sistem itu ialah 40 bilion MNT setahun, kadar kemalangan dianggarkan 1/400, justeru risiko kekurangan sokongan dianggarkan kira-kira 100 juta MNT setahun. Jelas sekali, "keuntungan yang dirancang" dan "anggaran kekerapan kemalangan" adalah nilai maya, tetapi adalah lebih baik untuk memiliki model sedemikian daripada tidak memilikinya.

Pada hakikatnya, sistem mungkin terlalu penting sehingga kos reputasi masa henti jangka panjang tidak dapat diterima, jadi sokongan akan diperlukan. Jika masa rehat dibenarkan, maka menolak sokongan kadangkala boleh menjadi cara yang baik untuk menjimatkan wang.

Mari kita anggap bahawa selepas semua pengiraan, kos operasi platform A selama 5 tahun ternyata menjadi 800 juta MNT, kos pengendalian platform B ialah 650 juta MNT, dan kos operasi platform C ialah 600 juta MNT. Platform C, sebagai pemenang, menerima mata penuh untuk harga, manakala platform A dan B menerima sedikit kurang, mengikut kadar berapa kali lebih mahal. Dalam kes ini – 0.75 dan 0.92 mata, masing-masing.

Penilaian peluang

Penilaian peluang dibahagikan kepada banyak kumpulan, yang jumlahnya hanya dihadkan oleh imaginasi orang yang membuat penilaian. Pilihan optimum nampaknya adalah untuk membahagikan keupayaan kepada pasukan yang akan menggunakan keupayaan ini; dalam contoh kami, ini adalah pembangun, pentadbir dan pegawai keselamatan maklumat. Mari kita andaikan bahawa pemberat fungsi ini diedarkan sebagai 40:40:20.

Fungsi pembangunan termasuk:

  • kemudahan manipulasi data;
  • penskalaan;
  • kehadiran indeks sekunder.

Senarai kriteria, serta beratnya, adalah sangat subjektif. Walaupun semasa menyelesaikan masalah yang sama, senarai ini, berat item dan jawapan akan berbeza dengan ketara bergantung pada komposisi pasukan anda. Sebagai contoh, Facebook menggunakan MySQL untuk menyimpan data, dan Instagram dibina pada Cassandra. Tidak mungkin pembangun aplikasi ini mengisi jadual sedemikian. Seseorang hanya boleh meneka bahawa Mark Zuckerberg memilih model hubungan yang lengkap, membayarnya dengan keperluan untuk sharding yang digunakan, manakala Kevin Systrom membina penskalaan menggunakan platform, mengorbankan kemudahan akses kepada data.

Fungsi pentadbiran termasuk:

  • keupayaan sistem sandaran;
  • kemudahan pemantauan;
  • kemudahan pengurusan kapasiti – cakera dan nod;
  • keupayaan replikasi data.

Sila ambil perhatian bahawa soalan mesti ditulis secara kuantitatif. Anda juga boleh bersetuju tentang cara menilai fungsi tertentu. Mari, sebagai contoh, cuba menilai alat sandaran menggunakan contoh alat yang dibekalkan dengan Oracle DBMS:

Alat
Komen
Penilaian

imp/exp
Memuat naik dan memuatkan data
0.1

sandaran mula/tamat
Menyalin fail
0.3

TUDUNG
Keupayaan salinan tambahan
0.7

ZDLRA
Hanya penyalinan tambahan, pemulihan terpantas ke titik
1.0

Jika tidak ada kriteria penilaian yang jelas, adalah wajar untuk meminta beberapa pakar untuk memberikan penilaian dan kemudian meratakannya.

Akhir sekali, kami hanya menyenaraikan fungsi keselamatan maklumat:

  • ketersediaan dasar pengurusan kata laluan;
  • keupayaan untuk menyambung alat pengesahan luaran (LDAP, Kerberos);
  • model peranan akses;
  • keupayaan audit;
  • penyulitan data pada cakera;
  • penyulitan semasa penghantaran melalui rangkaian (TLS);
  • perlindungan data daripada pentadbir.

Ujian prestasi

Secara berasingan, saya ingin memberi amaran agar tidak menggunakan keputusan sebarang ujian beban yang tidak anda buat sebagai hujah.

Pertama, struktur data dan profil beban aplikasi yang diuji mungkin berbeza dengan ketara daripada masalah yang akan anda selesaikan. Kira-kira 10-15 tahun yang lalu, vendor pangkalan data suka memamerkan keputusan yang dicapai dalam ujian TPC, tetapi kini, nampaknya, tiada siapa yang mengambil keputusan ini dengan serius.

Kedua, prestasi sistem sangat bergantung pada platform apa kod itu pada asalnya ditulis dan pada peralatan apa ujian itu dijalankan. Saya telah melihat banyak ujian di mana Oracle dibandingkan dengan PostgreSQL. Hasilnya berkisar dari keunggulan tanpa syarat satu sistem kepada keunggulan yang sama tanpa syarat sistem yang lain.

Dan akhirnya, ketiga, anda tidak tahu apa-apa tentang siapa yang melakukan ujian. Kedua-dua kelayakan adalah penting, mempengaruhi kualiti penyediaan OS dan platform, serta motivasi, yang mempengaruhi keputusan ujian lebih daripada semua faktor lain yang digabungkan.

Jika prestasi adalah faktor kritikal, jalankan ujian sendiri, sebaik-baiknya dengan bantuan orang yang akan mengkonfigurasi dan menyelenggara sistem pengeluaran.

Keputusan

Akhir sekali, hasil daripada semua kerja yang dilakukan hendaklah berupa hamparan di mana semua anggaran digabungkan, didarab dan disimpulkan:

Mana yang lebih baik – Oracle atau Redis atau Bagaimana untuk mewajarkan pilihan platform

Seperti yang anda faham, dengan menukar skala dan melaraskan penilaian anda boleh mencapai sebarang hasil yang diingini, tetapi itu cerita yang sama sekali berbeza...

Sumber: www.habr.com

Tambah komen