Cara Memilih Penyimpanan Data Untuk Hal Mengkilap Baru Berikutnya

Catatan: Ini adalah posting blog teknis yang ditulis oleh Principal Engineer Silvia Botros dan pertama kali muncul di blog Sysadvent pada 25 Desember 2017.

Database bisa sulit. Anda tahu apa yang lebih sulit? Memilih satu di tempat pertama. Ini menantang apakah Anda berada di perusahaan baru yang masih menemukan kecocokan produk/pasarnya atau di perusahaan yang telah menemukan audiensnya dan hanya memperluas penawaran produk.

Saat membangun hal baru, salah satu bagian pertama dari proses desain itu adalah penyimpanan data apa yang harus kita gunakan dan haruskah itu tunggal atau jamak? Haruskah kita menggunakan toko relasional atau apakah kita perlu memilih penyimpanan nilai kunci? Bagaimana dengan pilihan waktu? Haruskah kita juga memercikkan beberapa replay log terdistribusi?

Jadi. Banyak. Pilihan…

Saya akan mencoba dalam artikel ini untuk menjelaskan proses yang diharapkan akan memandu keputusan itu dan, jika berlaku, menjelaskan bagaimana ukuran dan kedewasaan organisasi Anda dapat memengaruhi keputusan ini.

Persyaratan dasar

Data adalah sumber kehidupan dari setiap produk. Bahkan jika kami berencana dalam desain untuk menggunakan lebih banyak teknologi mutakhir untuk menyimpan status aplikasi (karena MySQL atau Postgres tidak lagi "keren"), apa pun yang kami pilih masih merupakan penyimpanan data dan karenanya mengharuskan kami menerapkan ketelitian saat membuat pilihan kami.

Yang penting untuk diingat adalah tidak ada yang gratis. Semua penyimpanan data datang dengan kompromi dan jika Anda tidak secara eksplisit tentang kompromi apa yang Anda ambil sebagai risiko bisnis, Anda akan mengambil risiko yang tidak diketahui yang akan muncul dengan sendirinya pada waktu yang paling buruk.

Manajer produk Anda mungkin tidak tahu atau bahkan perlu peduli dengan apa yang Anda gunakan untuk penyimpanan data Anda, tetapi mereka akan mendorong kebutuhan yang menyusutkan daftar opsi. Kadang-kadang bahkan itu perlu beberapa dorongan oleh tim pengembangan. Berikut adalah daftar hal-hal yang perlu Anda tanyakan kepada tim produk untuk membantu mendorong pilihan Anda:

• Tingkat pertumbuhan: Bagaimana data itu sendiri atau aksesnya diharapkan berubah seiring waktu?
• Bagaimana tim penagihan akan menggunakan data baru ini?
• Bagaimana tim ETL akan menggunakan data ini?
• Persyaratan akurasi/konsistensi apa yang diharapkan untuk fitur baru ini?
• Berapa rentang waktu untuk konsistensi itu yang dapat diterima? Apakah koreksi pasca pemrosesan dapat diterima?

Temukan konteks yang tidak dikatakan

Pilihan penyimpanan data bukanlah pilihan yang disediakan untuk DBA atau tim Ops atau bahkan hanya insinyur yang menulis kode.

Organisasi yang matang dengan pasar yang diketahui dapat dialamatkan perlu mengambil keputusan dari pemangku kepentingan dari seluruh organisasi.

Jika persyaratan dari tim produk sesuai dengan selusin penyimpanan data, bagaimana Anda menentukan persyaratan yang tidak dipanggil secara eksplisit?

Anda perlu memunculkan persyaratan tak terucapkan sesegera mungkin karena itu adalah jalan menuju harapan yang gagal di masa depan.

Banyak hal tersirat yang bisa membuat Anda gagal dalam jebakan 'terlalu banyak pilihan' ini. Ini termasuk tetapi tidak terbatas pada:

• Daftar fitur tidak lengkap
• Persyaratan kinerja yang tidak dicantumkan secara eksplisit
• Kebutuhan konsistensi yang diasumsikan
• Tingkat pertumbuhan yang tidak ditentukan
• Penagihan atau kebutuhan kueri ETL yang belum tersedia/diketahui

Ini semua adalah cara yang mungkin yang dapat membuat tim teknik berputar terlalu lama untuk memeriksa daftar panjang pilihan penyimpanan data hanya karena kriteria eksplisit yang mereka kerjakan terlalu permisif atau tidak lengkap.

Untuk lebih banyak produk 'greenfield', seperti yang saya sebutkan sebelumnya, tujuan Anda adalah fleksibilitas. Jadi tujuan yang lebih umum, kualitas yang diketahui, penyimpanan data akan membantu Anda lebih dekat dengan hasil, dengan pengetahuan bahwa di masa depan, Anda mungkin perlu pindah ke penyimpanan data yang lebih sesuai dengan skala baru Anda.

Buat daftar Anda

Saatnya untuk menyaring solusi potensial dengan daftar persyaratan Anda. Daftar yang dihasilkan harus tidak lebih dari beberapa kemungkinan penyimpanan data. Jika daftar database potensial yang dapat Anda gunakan lebih dari itu, maka persyaratan Anda terlalu permisif dan Anda perlu kembali dan mencari informasi lebih lanjut.

Untuk perusahaan yang lebih muda dan kurang matang, persyaratan penyimpanan data adalah area yang paling tidak diketahui. Anda mungkin sedang membangun hal baru yang belum pernah ditawarkan oleh siapa pun sehingga hal-hal seperti ukuran pasar total dan tingkat pertumbuhan mungkin relatif tidak diketahui dan sulit diukur.

Dalam hal ini yang Anda butuhkan adalah untuk tidak membatasi diri Anda terlalu dini dalam masa hidup perusahaan baru Anda dengan menggunakan one trick pony datastore. Ya, pada titik tertentu data Anda akan tumbuh dengan cara baru dan tidak terduga, tetapi yang Anda butuhkan saat ini adalah fleksibilitas saat Anda mencoba menemukan ceruk pasar Anda dan mempelajari seperti apa pertumbuhan data Anda dan fitur skalabilitas spesifik apa yang akan menjadi penting untuk pertumbuhan Anda.

Jika Anda adalah perusahaan yang lebih besar dengan semakin banyak pelanggan yang membayar, tugas Anda di sini adalah mengecilkan daftar opsi ke penyimpanan data yang sudah Anda miliki dan pertahankan. Ketika Anda sudah memiliki banyak pelanggan yang membayar, risiko menambahkan penyimpanan data baru yang tidak dikenal oleh tim Anda menjadi lebih tinggi dan, tergantung pada konteks datanya, tidak dapat diterima.

Hal lain yang perlu diingat adalah alat apa yang sudah ada untuk penyimpanan data dan apa artinya mengadopsi yang baru sejauh pekerjaan awal yang harus dilakukan tim Anda. Manajemen konfigurasi, skrip cadangan, skrip pemulihan data, pemeriksaan pemantauan baru, dasbor baru untuk membangun dan membiasakan diri. Daftar biaya operasional penyimpanan data baru, terlepas dari risikonya, bukanlah hal yang sepele.

Pilih racunmu

Jadi, inilah rahasia yang dijaga ketat oleh DBA. Basis data semuanya mengerikan dalam sesuatu. Bahkan ada seluruh teorema tentang itu. Bukan hanya basis data dalam pengertian tradisional, tetapi teknologi apa pun yang menyimpan status akan mengerikan dengan cara yang unik untuk cara Anda menggunakannya.

Itu hanya fakta kehidupan yang lebih baik Anda internalisasikan sekarang. Tidak, saya tidak mengatakan Anda harus menghindari penggunaan salah satu dari teknologi ini, saya mengatakan menjaga harapan Anda tetap waras dan tahu bahwa ANDA dan hanya Anda dan tim Anda pada akhirnya yang memenuhi janji yang Anda buat.

Apa artinya ini dalam istilah non-abstrak? Setelah Anda memiliki gagasan yang kuat tentang penyimpanan data apa yang akan menjadi bagian dari apa yang Anda bangun, Anda harus mulai dengan mengetahui kelemahan penyimpanan data ini. Kelemahan-kelemahan tersebut termasuk namun tidak terbatas pada:

• Apakah penyimpanan data ini berfungsi dengan baik di bawah kueri pemindaian?
• Apakah datastore ini mengandalkan protokol gosip untuk replikasi data? jika demikian, bagaimana menangani partisi jaringan? Berapa banyak data yang terlibat dalam gosip itu?
• Apakah datastore ini memiliki satu titik kegagalan?
• Seberapa dewasa pengemudi di komunitas untuk berbicara dengannya atau apakah Anda perlu menggulung sendiri?
• Daftar ini bisa sangat besar

Memikirkan kelemahan dari solusi potensial yang masih ada dalam daftar Anda akan membuat lebih banyak opsi keluar dari daftar. Sekarang ini adalah kenyataan yang memenuhi janji-janji tinggi teknologi.

Spreadsheet dan panggang!

Setelah daftar pilihan Anda tinggal sedikit, sekarang saatnya untuk memasukkan semuanya ke dalam spreadsheet dan mulai menggali lebih dalam. Anda memerlukan kolom pro dan kolom kontra dan pada titik ini, Anda perlu meluangkan waktu di setiap dokumentasi database untuk mengetahui detail seluk beluk tentang cara melakukan tugas tertentu.

Jika ini adalah data yang Anda harapkan memiliki tingkat pertumbuhan yang besar, Anda perlu mengetahui opsi mana yang lebih mudah untuk diskalakan. Jika ini adalah fitur yang melakukan banyak pencarian fuzzy, Anda perlu mengetahui penyimpanan data mana yang dapat menangani pemindaian atau pencarian melalui sejumlah besar baris dengan lebih baik dan dengan desain apa. Target pada tahap ini adalah untuk mengurangi daftar menjadi idealnya 2 atau 3 opsi melalui dokumentasi saja karena jika fitur baru ini cukup penting untuk kesuksesan perusahaan, Anda harus membandingkan ketiganya.

Mengapa benchmark Anda katakan? Karena tidak ada 2 perusahaan yang menggunakan datastore yang sama dengan cara yang sama. Karena terkadang dokumentasi menyiratkan peringatan yang hanya terungkap dalam cerita perang orang lain.

Karena tidak ada yang memiliki stabilitas, keandalan, dan prediktabilitas penyimpanan data ini selain Anda.

Rancang tolok ukur Anda terlebih dahulu. Idealnya, Anda menyiapkan instance lengkap dari penyimpanan data dalam daftar Anda dengan spesifikasi tingkat produksi dan menghasilkan data pengujian yang tidak terlalu kecil untuk membuat pengujian beban tidak berguna. Pastikan untuk tidak hanya melakukan benchmark untuk 'beban normal' tetapi juga untuk menguji beberapa skenario kegagalan.

Harapannya, melalui benchmark, Anda dapat menemukan peringatan apa pun yang cukup parah sehingga Anda harus mengunjungi kembali daftar opsi sekarang daripada nanti ketika semua kode ditulis dan Anda sekarang berada pada fase latihan kebakaran dengan banyak waktu. dan upaya berkomitmen untuk pilihan yang Anda buat.

Dokumentasikan pilihan Anda

Apa pun yang Anda lakukan, Anda harus mendokumentasikan dan menyiarkan secara internal metode yang Anda gunakan untuk mencapai pilihan Anda dan alternatif-alternatif yang diselidiki dalam perjalanan menuju keputusan itu. Dengan asumsi ada cetak biru arsitektur menyeluruh tentang bagaimana fitur baru ini akan dibuat dan semua komponennya, Anda pastikan untuk membuat bagian yang didedikasikan untuk penyimpanan data yang mendukung fitur baru ini dengan tautan ke semua tolok ukur yang dilakukan untuk mencapai keputusan yang diambil oleh tim .

Ini bukan hanya untuk keuntungan karyawan baru di masa depan, tetapi juga untuk keuntungan tim Anda sekarang. Sebuah dokumen yang orang-orang dapat membaca dan mengembangkan opini secara asinkron menyediakan cara untuk menjaga proses pengambilan keputusan tetap transparan, menumbuhkan rasa niat terbaik di antara anggota tim dan dapat mendatangkan kritik dari perspektif yang tidak Anda duga sebelumnya.

Bawa pulang

Langkah-langkah ini tidak hanya akan mengarah pada keputusan berdasarkan data saat mengembangkan penawaran bisnis, tetapi juga akan mengarah pada infrastruktur yang kuat dan pendekatan yang lebih disiplin tentang kapan dan di mana Anda menggunakan bidang teknologi yang terus berkembang untuk memberikan nilai bagi pembayaran Anda. pelanggan.