Mana yang lebih baik - Oracle atau Redis atau Bagaimana menjustifikasi pilihan platform

"Yah, ini perlu," katanya keras tanpa berbicara dengan siapa pun. - Yah ini perlu! Jadi itu ditulis langsung - tugas utama perusahaan adalah untuk menghasilkan keuntungan untuk kepentingan pemegang saham. Anda pikir! Mereka tidak takut pada apa pun!



Julius Dubov, "The Lesser Evil"

Melihat tajuk utama seperti itu, Anda mungkin telah memutuskan bahwa artikel tersebut adalah kebodohan atau provokasi. Tetapi jangan langsung mengambil kesimpulan: karyawan perusahaan besar, terutama perusahaan dengan partisipasi negara, cukup sering harus membandingkan platform yang berbeda, termasuk yang sama sekali berbeda, misalnya, seperti yang ada dalam judul.







Tentu saja, tidak ada yang membandingkan DBMS seperti itu, karena kekuatan dan kelemahan mereka sudah diketahui. Sebagai aturan, platform yang memecahkan masalah yang diterapkan harus dibandingkan. Dalam artikel tersebut, saya akan menunjukkan teknik yang digunakan pada saat yang sama, menggunakan contoh database sebagai subjek yang tidak terlalu umum untuk pembaca Habr. Begitu,

Motivasi

Ketika Anda memulai proyek pendidikan atau proyek hobi, motivasi untuk memilih platform bisa sangat beragam: "Saya tahu platform ini terbaik", "Saya tertarik memahami yang ini", "ini dokumentasi terbaik" ... Dalam kasus perusahaan komersial, kriteria pemilihannya adalah: berapa yang harus saya bayar dan apa yang akan saya dapatkan untuk uang ini.



Secara alami, Anda ingin membayar lebih sedikit dan mendapatkan lebih banyak. Namun, perlu untuk memutuskan mana yang lebih penting - membayar lebih sedikit atau menerima lebih banyak, dan menetapkan bobot untuk setiap node. Mari kita asumsikan bahwa solusi berkualitas tinggi lebih penting bagi kita daripada yang murah, dan kami menetapkan simpul "Biaya" berat 40%, dan simpul "Peluang" - 60%.







Dalam perusahaan besar, yang terjadi biasanya sebaliknya - bobot nilainya tidak turun di bawah 50%, dan mungkin lebih dari 60%. Dalam contoh model, hanya penting bahwa berat total node anak dari setiap simpul orangtua harus 100%.

Kondisi cutoff

Situs db-engines.com mengenal sekitar 500 sistem manajemen basis data. Tentu saja, jika Anda memilih platform target dari begitu banyak opsi, Anda mungkin berakhir dengan artikel ulasan, tetapi bukan proyek komersial. Untuk mengurangi ruang pilihan, kriteria cutoff dirumuskan, dan jika platform tidak memenuhi kriteria ini, maka itu tidak dipertimbangkan.



Kriteria cutoff dapat berhubungan dengan fitur teknologi, misalnya:

• Jaminan ASAM;
• model data relasional;
• Dukungan bahasa SQL (perhatikan, ini tidak sama dengan "model relasional");
• kemungkinan penskalaan horizontal.

Mungkin ada kriteria umum:

• ketersediaan dukungan komersial di Rusia;
• open source;
• ketersediaan platform dalam Daftar Kementerian Telekomunikasi dan Komunikasi Massa;
• keberadaan platform di beberapa peringkat (misalnya, dalam seratus pertama peringkat db-engines.com);
• ketersediaan pakar di pasar (misalnya, berdasarkan hasil pencarian nama platform di resume di situs web hh.ru).

Bagaimanapun, mungkin ada kriteria khusus perusahaan:

• ketersediaan spesialis dalam staf;
• kompatibilitas dengan sistem pemantauan X atau dengan sistem cadangan Y, di mana semua perawatan terikat ...

Yang paling penting adalah memiliki daftar kriteria cut-off. Kalau tidak, pasti akan ada beberapa ahli (atau "ahli") yang menikmati kepercayaan khusus dari manajemen, yang akan mengatakan "mengapa Anda tidak memilih platform Z, saya tahu itu yang terbaik."

Estimasi biaya

Biaya solusi jelas terdiri dari biaya lisensi, biaya pemeliharaan dan biaya peralatan.



Jika sistemnya kurang lebih kelas yang sama (misalnya, Microsoft SQL Server dan PostgreSQL), maka untuk kesederhanaan, kita dapat mengasumsikan bahwa jumlah peralatan untuk kedua solusi akan kurang lebih sama. Ini akan memungkinkan Anda untuk tidak mengevaluasi peralatan, sehingga menghemat banyak waktu dan tenaga. Jika Anda harus membandingkan sistem yang sama sekali berbeda (katakanlah, Oracle vs Redis), maka jelas bahwa untuk penilaian yang benar perlu dilakukan pengukuran (perhitungan jumlah peralatan). Mengukur sistem yang tidak ada adalah tugas yang sangat tidak berterima, jadi mereka masih mencoba menghindari perbandingan seperti itu. Sangat mudah untuk melakukan ini: nol kehilangan data dan model relasional ditulis dalam kondisi kliping, atau sebaliknya - beban 50 ribu transaksi per detik.



Untuk mengevaluasi lisensi, cukup menanyakan kepada vendor atau mitranya mengenai biaya lisensi untuk sejumlah core dan dukungan untuk periode yang tetap. Sebagai aturan, perusahaan sudah memiliki hubungan yang kuat dengan vendor perangkat lunak, dan jika departemen operasi database tidak dapat menjawab pertanyaan biaya sendiri, maka satu huruf sudah cukup untuk menerima informasi ini.



Vendor yang berbeda mungkin memiliki metrik lisensi yang berbeda: dengan jumlah inti, jumlah data, atau jumlah node. Database siaga bisa gratis, atau bisa dilisensikan dengan cara yang sama seperti yang utama. Jika hanya beberapa perbedaan dalam metrik yang ditemukan, Anda harus mendeskripsikan secara detail dudukan model dan menghitung biaya lisensi untuk dudukan tersebut.



Poin penting untuk perbandingan yang benar adalah kondisi dukungan yang sama. Sebagai contoh, dukungan Oracle biaya 22% dari harga lisensi per tahun, dan dukungan PostgreSQL tidak ada biaya. Apakah benar membandingkan? Tidak, karena kesalahan yang tidak dapat dihilangkan dengan sendirinya memiliki konsekuensi yang sama sekali berbeda: dalam kasus pertama, spesialis dukungan akan dengan cepat membantu memperbaikinya, dan dalam kasus kedua, ada risiko keterlambatan proyek atau waktu henti sistem selesai untuk jangka waktu yang tidak ditentukan.



Ada tiga cara untuk menyamakan kondisi perhitungan:

1. Gunakan Oracle tanpa dukungan (pada kenyataannya, ini tidak terjadi).
2. Beli dukungan PostgreSQL - misalnya, dari Postgres Professional.
3. Sertakan risiko yang terkait dengan kurangnya dukungan.

Misalnya, perhitungan risiko mungkin terlihat seperti ini: jika terjadi kegagalan basis data yang fatal, waktu henti sistem adalah 1 hari kerja. Keuntungan yang direncanakan dari penggunaan sistem adalah 40 miliar tugriks Mongolia per tahun, frekuensi kecelakaan diperkirakan 1/400, dengan demikian, risiko kurangnya dukungan diperkirakan sekitar 100 juta tugriks Mongolia per tahun. Jelas, "keuntungan yang direncanakan" dan "perkiraan tingkat kecelakaan" adalah jumlah virtual, tetapi jauh lebih baik untuk memiliki model seperti itu daripada tidak memilikinya.



Pada kenyataannya, sistem mungkin terlalu penting, dan kerugian reputasi akibat downtime yang berkepanjangan tidak dapat diterima, sehingga dukungan akan diperlukan. Jika downtime diperbolehkan, maka menjatuhkan dukungan terkadang bisa menjadi cara yang baik untuk menghemat uang.



Misalkan setelah semua perhitungan, biaya platform operasi A selama 5 tahun ternyata menjadi 800 juta tugriks Mongolia, biaya platform operasi B - 650 juta tugriks, dan biaya platform operasi C - 600 juta tugriks. Platform C, sebagai pemenang, menerima poin penuh untuk biaya, dan platform A dan B - sedikit lebih rendah, sebanding dengan berapa kali mereka lebih mahal. Dalam hal ini - 0,75 dan 0,92 poin, masing-masing.

Penilaian peluang

Penilaian peluang dibagi menjadi banyak kelompok, yang jumlahnya hanya dibatasi oleh imajinasi orang yang membuat penilaian. Pilihan terbaik tampaknya adalah pembagian kemampuan menjadi tim yang akan menggunakan kemampuan ini; dalam contoh kami, ini adalah pengembang, administrator, dan petugas keamanan informasi. Mari kita asumsikan bahwa bobot fungsi-fungsi ini didistribusikan sebagai 40:40:20.



Fungsi pengembangan meliputi:

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

Daftar kriteria, seperti bobotnya, sangat subyektif. Bahkan ketika memecahkan masalah yang sama, daftar, bobot dan jawaban item ini akan berbeda secara signifikan tergantung pada komposisi tim Anda. Misalnya, Facebook menggunakan MySQL untuk menyimpan data, dan Instagram dibangun di atas Cassandra. Tidak mungkin bahwa pengembang aplikasi ini mengisi tabel tersebut. Orang hanya bisa menebak bahwa Mark Zuckerberg memilih model relasional penuh, membayarnya dengan kebutuhan untuk sharding terapan, sementara Kevin Systrom meletakkan penskalaan melalui platform, mengorbankan kenyamanan akses data.



Fungsi administrasi meliputi:

• kemampuan sistem cadangan;
• kemudahan pemantauan;
• kenyamanan manajemen kapasitas - disk dan node;
• kemampuan replikasi data.

Harap dicatat bahwa kata-kata dari pertanyaan harus dapat diukur. Anda bahkan dapat menyetujui cara mengevaluasi fungsi tertentu. Misalnya, mari kita beri peringkat alat pencadangan menggunakan contoh alat yang disertakan dengan DBMS Oracle:





Jika tidak ada kriteria penilaian yang jelas, masuk akal untuk meminta beberapa ahli untuk memberikan nilai dan kemudian meratakannya.



Terakhir, mari kita daftarkan fitur keamanan informasi:

• ketersediaan kebijakan manajemen kata sandi;
• kemampuan untuk menghubungkan alat otentikasi eksternal (LDAP, Kerberos);
• model peran akses;
• ;
• ;
• (TLS);
• .

Secara terpisah, saya ingin memperingatkan agar tidak menggunakan hasil tes beban apa pun yang tidak Anda lakukan sebagai argumen.



Pertama, struktur data dan memuat profil aplikasi yang sedang diuji mungkin berbeda secara signifikan dari tugas yang akan Anda selesaikan. Sekitar 10-15 tahun yang lalu, vendor database senang memamerkan hasil benchmark TPC, tetapi sekarang tidak ada yang menganggap serius hasil ini.



Kedua, kinerja sistem sangat tergantung pada platform yang kode awalnya ditulis dan pada perangkat keras apa pengujian dilakukan. Saya telah melihat banyak tolok ukur membandingkan Oracle dengan PostgreSQL. Hasil berkisar dari superioritas tanpa syarat dari satu sistem ke superioritas tanpa syarat yang sama dari yang lain.



Dan akhirnya, ketiga, Anda tidak tahu apa-apa tentang siapa yang melakukan tes. Kedua kualifikasi, yang memengaruhi kualitas OS dan kustomisasi platform, adalah penting, juga motivasi, yang memengaruhi hasil tes lebih banyak daripada gabungan semua faktor lain.



Jika kinerja merupakan faktor penting, lakukan pengujian sendiri, lebih disukai dengan bantuan spesialis yang akan mengonfigurasi dan memelihara sistem produksi.

Hasil

Akhirnya, hasil dari semua pekerjaan yang dilakukan harus berupa spreadsheet, di mana semua taksiran disatukan, dikalikan dan disimpulkan:







Seperti yang Anda pahami, mengubah bobot dan menyesuaikan taksiran dapat mencapai hasil yang diinginkan, tetapi ini adalah cerita yang sama sekali berbeda ...