“Ini perlu,” katanya keras, tanpa berbicara kepada siapa pun. - Ini perlu! Inilah yang dikatakan: tugas utama suatu perusahaan adalah memperoleh keuntungan demi kepentingan pemegang saham. Nah, pikirkanlah! Mereka tidak takut pada apapun!
Yuliy Dubov, “Kejahatan yang Lebih Kecil”
Setelah melihat judul seperti itu, Anda mungkin sudah memutuskan bahwa artikel tersebut adalah kebodohan atau provokasi. Namun jangan terburu-buru mengambil kesimpulan: karyawan perusahaan besar, terutama perusahaan dengan partisipasi negara, seringkali harus membandingkan platform yang berbeda, termasuk platform yang sangat berbeda - misalnya, yang ada di judul.
Tentu saja, tidak ada yang membandingkan DBMS dengan cara ini, karena kekuatan dan kelemahannya sudah diketahui dengan baik. Sebagai aturan, platform yang memecahkan beberapa masalah aplikasi harus dibandingkan. Dalam artikel ini saya akan menunjukkan metodologi yang digunakan dalam kasus ini, dengan menggunakan contoh database sebagai subjek yang familiar bagi pembaca Habr secara langsung. Jadi,
Motivasi
Saat Anda memulai proyek pendidikan atau proyek hobi, motivasi memilih platform bisa sangat beragam: “ini adalah platform yang paling saya kenal”, “Saya tertarik untuk memahami yang ini”, “inilah dokumentasi terbaik” ... Dalam kasus perusahaan komersial, kriteria pemilihannya sama: berapa yang harus saya bayar dan apa yang akan saya dapatkan untuk uang tersebut.
Tentu saja, Anda ingin membayar lebih sedikit dan mendapatkan lebih banyak. Namun, Anda perlu memutuskan mana yang lebih penting - membayar lebih sedikit atau mendapatkan lebih banyak, dan memberikan bobot pada setiap node. Mari kita asumsikan bahwa solusi berkualitas tinggi lebih penting bagi kita daripada solusi murah, dan kita memberikan bobot sebesar 40% pada node “Biaya”, dan 60% pada node “Peluang”.
Di perusahaan besar, yang terjadi justru sebaliknya - bobot biaya tidak turun di bawah 50%, dan mungkin lebih dari 60%. Dalam contoh model, yang penting adalah bobot total node anak dari setiap node induk harus 100%.
Kondisi pemutusan hubungan kerja
Lokasi Ada sekitar 500 sistem manajemen basis data yang dikenal. Tentu saja, jika Anda memilih platform target dari begitu banyak pilihan, Anda mungkin akan mendapatkan artikel ulasan, tetapi bukan proyek komersial. Untuk mengurangi ruang pilihan, kriteria batas dirumuskan, dan jika platform tidak memenuhi kriteria ini, maka platform tersebut tidak dipertimbangkan.
Kriteria batas mungkin 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;
- sumber terbuka;
- ketersediaan platform dalam Daftar Kementerian Telekomunikasi dan Komunikasi Massa;
- kehadiran platform di beberapa peringkat (misalnya, di seratus peringkat pertama db-engines.com);
- kehadiran pakar di pasar (misalnya, berdasarkan hasil pencarian nama platform dalam resume di situs hh.ru).
Bagaimanapun, mungkin ada kriteria khusus perusahaan:
- ketersediaan staf spesialis;
- kompatibilitas dengan sistem pemantauan X atau sistem cadangan Y, yang menjadi dasar semua dukungan...
Yang terpenting ada daftar kriteria batasnya. Jika tidak, pasti akan ada beberapa pakar (atau “pakar”) yang mendapat kepercayaan khusus dari manajemen yang akan berkata “mengapa Anda tidak memilih platform Z, saya tahu itu yang terbaik.”
Estimasi biaya
Biaya penyelesaiannya jelas terdiri dari biaya perizinan, biaya dukungan dan biaya peralatan.
Jika sistemnya memiliki kelas yang kira-kira sama (misalnya, Microsoft SQL Server dan PostgreSQL), maka untuk kesederhanaan kita dapat berasumsi bahwa jumlah peralatan untuk kedua solusi akan kira-kira sama. Ini akan memungkinkan Anda untuk tidak mengevaluasi peralatan, sehingga menghemat banyak waktu dan tenaga. Jika Anda harus membandingkan sistem yang benar-benar berbeda (misalnya, Oracle vs. Redis), maka jelas bahwa untuk penilaian yang benar perlu dilakukan sizing (perhitungan jumlah peralatan). Mengukur sistem yang tidak ada adalah tugas yang sangat sia-sia, jadi mereka tetap berusaha menghindari perbandingan seperti itu. Ini mudah dilakukan: dalam kondisi cut-off, nol data hilang dan model relasional ditulis, atau sebaliknya - beban 50 ribu transaksi per detik.
Untuk mengevaluasi lisensi, cukup menanyakan kepada vendor atau mitranya mengenai biaya lisensi untuk jumlah inti yang tetap dan dukungan untuk jangka waktu tertentu. Biasanya, 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 memperoleh informasi ini.
Vendor yang berbeda mungkin memiliki metrik lisensi yang berbeda: berdasarkan jumlah inti, volume data, atau jumlah node. Basis siaga bisa gratis, atau bisa dilisensikan dengan cara yang sama seperti basis utama. Jika ada perbedaan dalam metrik yang ditemukan, Anda harus mendeskripsikan model stand secara rinci dan menghitung biaya lisensi untuk stand tersebut.
Poin penting untuk perbandingan yang benar adalah kondisi support yang sama. Misalnya, dukungan Oracle berharga 22% dari harga lisensi per tahun, namun Anda tidak perlu membayar untuk dukungan PostgreSQL. Apakah benar membandingkan seperti ini? Tidak, karena kesalahan yang tidak dapat Anda perbaiki sendiri memiliki konsekuensi yang sangat berbeda: dalam kasus pertama, spesialis dukungan akan segera membantu Anda memperbaikinya, tetapi dalam kasus kedua, ada risiko penundaan proyek atau waktu henti proyek yang sudah selesai. sistem untuk jangka waktu tidak terbatas.
Anda dapat menyamakan kondisi perhitungan dengan tiga cara:
- Gunakan Oracle tanpa dukungan (pada kenyataannya hal ini tidak terjadi).
- Beli dukungan untuk PostgreSQL - misalnya, dari Postgres Professional.
- Pertimbangkan risiko yang terkait dengan kurangnya dukungan.
Misalnya, penghitungan risiko mungkin terlihat seperti ini: jika terjadi kegagalan database yang fatal, waktu henti sistem akan menjadi 1 hari kerja. Proyeksi keuntungan dari penggunaan sistem ini adalah 40 miliar MNT per tahun, tingkat kecelakaan diperkirakan 1/400, sehingga risiko kurangnya dukungan diperkirakan sekitar 100 juta MNT per tahun. Tentu saja, “keuntungan yang direncanakan” dan “perkiraan frekuensi kecelakaan” adalah nilai virtual, namun jauh lebih baik jika memiliki model seperti itu daripada tidak memilikinya.
Pada kenyataannya, sistem ini mungkin terlalu penting sehingga kerugian reputasi akibat downtime jangka panjang tidak dapat diterima, sehingga dukungan akan diperlukan. Jika waktu henti diperbolehkan, menolak dukungan terkadang bisa menjadi cara yang baik untuk menghemat uang.
Mari kita asumsikan setelah semua perhitungan, biaya pengoperasian platform A selama 5 tahun ternyata 800 juta MNT, biaya pengoperasian platform B adalah 650 juta MNT, dan biaya pengoperasian platform C adalah 600 juta MNT. Platform C, sebagai pemenang, menerima poin penuh untuk harganya, sedangkan platform A dan B menerima poin lebih sedikit, sebanding dengan berapa kali harganya lebih mahal. Dalam hal ini – masing-masing 0.75 dan 0.92 poin.
Penilaian peluang
Penilaian peluang dibagi menjadi banyak kelompok yang jumlahnya hanya dibatasi oleh imajinasi orang yang melakukan penilaian. Pilihan terbaik tampaknya adalah membagi kemampuan menjadi beberapa tim yang akan menggunakan kemampuan tersebut; dalam contoh kita, mereka adalah pengembang, administrator, dan petugas keamanan informasi. Mari kita asumsikan bobot fungsi-fungsi ini didistribusikan sebagai 40:40:20.
Fungsi pengembangan meliputi:
- kemudahan manipulasi data;
- penskalaan;
- kehadiran indeks sekunder.
Daftar kriteria dan bobotnya sangat subyektif. Bahkan ketika memecahkan masalah yang sama, daftar, bobot item, dan jawaban ini akan sangat bervariasi tergantung pada komposisi tim Anda. Misalnya, Facebook menggunakan MySQL untuk menyimpan data, dan Instagram dibangun di atas Cassandra. Kecil kemungkinannya pengembang aplikasi ini mengisi tabel seperti itu. Orang hanya bisa menebak bahwa Mark Zuckerberg memilih model relasional yang lengkap, membayarnya dengan kebutuhan penerapan sharding, sementara Kevin Systrom membangun penskalaan menggunakan platform, mengorbankan kemudahan akses ke data.
Fungsi administrasi meliputi:
- kemampuan sistem cadangan;
- kemudahan pemantauan;
- kemudahan manajemen kapasitas – disk dan node;
- kemampuan replikasi data.
Harap dicatat bahwa pertanyaan harus disusun secara kuantitatif. Anda bahkan dapat menyepakati cara mengevaluasi fungsi tertentu. Sebagai contoh, mari kita coba menilai alat pencadangan menggunakan contoh alat yang disertakan dengan Oracle DBMS:
Alat
Komentar
Evaluasi
imp/exp
Mengunggah dan memuat data
0.1
memulai/mengakhiri pencadangan
Menyalin file
0.3
RMMAN
Kemampuan penyalinan tambahan
0.7
ZDLRA
Hanya penyalinan tambahan, pemulihan tercepat
1.0
Jika tidak ada kriteria evaluasi yang jelas, masuk akal untuk meminta beberapa ahli untuk memberikan penilaian dan kemudian membuat rata-ratanya.
Terakhir, kami hanya mencantumkan fungsi keamanan informasi:
- ketersediaan kebijakan manajemen kata sandi;
- kemampuan untuk menghubungkan alat otentikasi eksternal (LDAP, Kerberos);
- teladan akses;
- kemampuan audit;
- enkripsi data pada disk;
- enkripsi selama transmisi melalui jaringan (TLS);
- perlindungan data dari administrator.
Pengujian kinerja
Secara terpisah, saya ingin memperingatkan agar tidak menggunakan hasil tes beban apa pun yang tidak Anda buat sebagai argumen.
Pertama, struktur data dan profil beban aplikasi yang diuji mungkin berbeda secara signifikan dari masalah yang ingin Anda selesaikan. Sekitar 10-15 tahun yang lalu, vendor database senang memamerkan hasil yang dicapai dalam pengujian TPC, tetapi sekarang tampaknya tidak ada yang menganggap serius hasil tersebut.
Kedua, kinerja sistem sangat bergantung pada platform apa kode tersebut awalnya ditulis dan pada peralatan apa pengujian dilakukan. Saya telah melihat banyak tes dimana Oracle dibandingkan dengan PostgreSQL. Hasilnya berkisar dari keunggulan tanpa syarat suatu sistem hingga keunggulan sistem lain yang juga tidak bersyarat.
Dan terakhir, ketiga, Anda tidak tahu apa-apa tentang siapa yang melakukan tes tersebut. Kedua kualifikasi tersebut penting, karena memengaruhi kualitas pengaturan OS dan platform, serta motivasi, yang memengaruhi hasil tes lebih dari gabungan semua faktor lainnya.
Jika kinerja merupakan faktor penting, lakukan pengujian sendiri, sebaiknya dengan bantuan orang yang akan mengkonfigurasi dan memelihara sistem produksi.
Hasil
Terakhir, hasil dari semua pekerjaan yang dilakukan harus berupa spreadsheet tempat semua perkiraan digabungkan, dikalikan, dan dijumlahkan:
Seperti yang Anda pahami, dengan mengubah skala dan menyesuaikan peringkat, Anda dapat mencapai hasil apa pun yang diinginkan, tetapi itu adalah cerita yang sama sekali berbeda...
Sumber: www.habr.com