Tantangan
Saya menyadari bahwa ada praktik seperti hanya menambahkan objek database, yaitu tabel dan kolom, tidak pernah memodifikasi atau menghapusnya
Di satu perusahaan tempat saya bekerja, jendela data mentah yang bergulir setara dengan sekitar 6 bulan dan menghabiskan 10 TB. Data kemudian diolah menjadi format RDBMS yang biayanya 6 TB dari data yang dapat digunakan yang menyumbang sekitar 10 tahun data yang dapat dilaporkan. Intinya adalah bahwa pada skala, praktik semacam ini tidak praktis. Penyimpanan itu mahal - mungkin biaya komputasi terbesar. Ini memberikan beberapa tantangan menarik:
- Cadangan - plugin innodb bagus dan semuanya, tetapi waktu pencadangan pada data sebanyak itu tidak praktis
- Pulihkan waktu - untuk kumpulan data besar - terutama jika Anda perlu replikasi untuk mengejar ketinggalan setelah pemulihan kembali ke kondisi operasional dapat memakan waktu berhari-hari atau bahkan berminggu-minggu.
- Membuat / menyemai contoh baru - Seringkali pekerjaan yang mungkin Anda lakukan dalam dev / test melibatkan pekerjaan ETL (Extract, Transform and Load) pada dataset Anda. Ini perlu divalidasi menggunakan unit pengujian QA, tetapi ini perlu dilakukan secara non-destruktif sehingga dataset produksi asli dipertahankan. Sementara dalam bencana, Anda mungkin bersedia untuk berurusan dengan waktu pemulihan yang lama dengan pengertian bahwa cadangan adalah polis asuransi dan tujuannya adalah untuk menghindarinya, alur kerja pengembangan DevOps mengharuskan, pada dasarnya, Anda dapat melakukan pemulihan atau salinan data Anda secara berkala (mungkin beberapa kali sehari)
- Kapasitas - Membawa data sebanyak itu pada skala yang baru saja saya jelaskan bisa sangat intensif I / O. Anda tidak hanya perlu mengatasi masalah yang dijelaskan dalam 1-3, tetapi Anda harus melakukannya dengan cara yang tidak menyebabkan gangguan atau gangguan kinerja pada sistem produksi Anda.
Meskipun pertimbangan di atas mungkin tidak menjadi perhatian pada skala yang lebih kecil, pada skala yang lebih besar, ini menjadi masalah besar. Ini berarti bahwa sangat penting bagi Anda menentukan persyaratan dan memperkirakan ukuran dataset Anda.
Menentukan persyaratan
Akibatnya, Anda perlu menetapkan beberapa persyaratan:
- RTO - RTO atau Restore Time Objective untuk cadangan adalah salah satu penggerak terpenting dari solusi cadangan basis data. Sementara, pada awalnya itu mungkin tidak tampak relevan dengan sebagian besar masalah lain, itu menjadi sangat relevan ketika Anda bertanya "Bagaimana jika saya menggunakan solusi cadangan saya untuk membuat atau menabur contoh baru?". Saya akan membahas beberapa teknik untuk melakukannya di bagian selanjutnya.
- RPO - RPO atau Restore Point Objective untuk backup mendefinisikan A) seberapa jauh kembali Anda dapat mengembalikan (menit, jam, hari, minggu, bulan, atau tahun) B) Interval cadangan di tingkatan yang berbeda dan C) bagaimana granularly Anda dapat mengembalikan . Misalnya, untuk database E-mail, Pencadangan Level Pesan - memulihkan e-mail tertentu - sering dicari. Demikian pula, Anda mungkin menemukan bahwa data selama beberapa hari sama sekali tidak berguna - jadi tidak ada gunanya mengembalikan satu tahun.
- Ukuran dataset Anda - Ini penting karena untuk database 1MB, RTO Anda dapat dicapai dengan sebagian besar produk dan solusi cadangan. Untuk database 10TB Namun, Anda akan menemukan bahwa penuh, tingkat baris cadangan untuk LTO 3 tape mungkin tidak akan mencapai RTO dan bisa mengganggu RPO Anda karena backup mulai melebihi jendela cadangan Anda. Anda tidak bisa hanya melakukan mysqldump pada set data yang besar ini, tetapi mungkin bisa lolos begitu saja pada database 1MB.
- Konsistensi basis data - Hal terakhir yang membuat perbedaan besar dalam penerapan berkelanjutan, keandalan situs, skalabilitas, dan ketersediaan tinggi ketika bekerja dengan database adalah kebutuhan Anda (atau ketiadaan) untuk konsistensi. Ada tiga tipe dasar: konsistensi langsung, konsistensi Just-In-Time (JIT) dan konsistensi akhirnya
Selain pertimbangan utama di atas, Anda juga perlu mempertimbangkan persyaratan lisensi dan dukungan (sumber terbuka atau sumber tertutup; dukungan internal, dukungan pihak ketiga atau dukungan vendor) persyaratan aplikasi / bahasa (konektor untuk banyak basis data dapat menjadi penting; aplikasi Anda dikompilasi? Apakah Anda memiliki akses ke kode sumber? Dapatkah Anda mengkompilasi ulang, atau disediakan oleh vendor? Atau apakah itu berjalan pada bahasa yang ditafsirkan?) persyaratan politik (Apakah organisasi Anda hanya mempercayai Oracle? Apakah mereka membenci oracle? "Apakah mereka tidak mempercayai MySql? Bagaimana perasaan Anda tentang MariaDB atau Postgres?) Dan mesin basis data (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Dan persyaratan historis atau kompabilitas (kami menggunakan PL / SQL selama bertahun-tahun dan setengah kode kami) dibangun ke dalam mesin oracle! Bagaimana kita bisa port ke MariaDB?!?)
Semua hal ini (secara signifikan) berdampak pada alat yang tersedia untuk Anda.
Beberapa Opsi untuk manajemen data in-house
Catatan: Berikut ini sama sekali tidak lengkap, dan pengguna SE lainnya harus berpadu dengan saran tambahan.
Dengan pertimbangan generik yang menghalangi, izinkan saya memberi Anda beberapa teknik dan teknologi untuk mengatasi hal di atas. Pertama, tanyakan pada diri Anda apakah Anda benar - benar perlu menggunakan RDBMS atau jika data tidak terstruktur dengan sesuatu seperti Hadoop, CouchDB atau bahkan Object Oriented Storage (sesuatu seperti swift) adalah sebuah pilihan.
Kedua, pertimbangkan untuk mencari solusi berbasis cloud. Ini mengalihdayakan sebagian dari sakit kepala ini dan menyisakan masalah rumit bagi individu yang sangat berkualifikasi (dan dibayar). Namun pada skala, Anda dapat menemukan ini benar-benar memakan anggaran Anda (penyedia cloud DO membuat untung pada ini, dan pada skala tertentu, Anda hanya bisa mampu mempekerjakan para ahli ini sendiri), atau jika Anda bekerja di bawah keamanan atau politik tertentu persyaratan (baca: kami tidak bisa melakukan cloud) pertimbangkan hybrid NFS / FibreChannel Filer. Sebagian besar dari pelapor ini, seperti yang dilakukan oleh NetApp, Pure Storage, dan Tegile mendukung teknik snapshotting dan kloning berbasis delta yang dapat sangat berguna untuk A) mengambil cadangan, B) Memulihkan cadangan, dan C) Mencari cadangan baru.
Pada titik ini, saya perlu mencatat bahwa saya bukan ahli cadangan dan penyimpanan, jadi ada beberapa bagian dari masalah ini yang tidak pernah bisa saya pecahkan sebelum saya pindah ke masalah lain (dan padang rumput yang lebih hijau).
Namun demikian, produk-produk ini memungkinkan Anda untuk mengambil snapshot diferensial di bawah databse Anda. Anda perlu membuat skrip penuh "tabel kunci dengan kunci baca" pada salah satu contoh basis data Anda (disarankan hanya menggunakan slave) dan membuang posisi binlog atau GTID Anda, tetapi untuk pelapor ini, setelah melakukannya, Anda dapat untuk menggunakan buncis ini untuk membuat instance baru dari database Anda. Anda akan ingin menempatkan binlog pada partisi yang terpisah dan hanya menempatkan data database Anda pada partisi ini. Setelah melakukannya, Anda dapat mengkloning partisi ini (di NetApps, ini dikenal sebagai " FlexClone "
Ini karena untuk setiap blok baca filer harus menentukan apakah data berada di snapshot asli yang dibekukan, atau di delta. Untuk volume / toko dengan banyak foto, ini mungkin perlu diperiksa beberapa kali. Anda dapat mengatasinya dengan menyegarkan data (artinya, membuang foto Anda dan mengkloningnya kembali secara berkala - yang mungkin terjadi secara alami dan organik untuk lingkungan penyebaran yang baik terus-menerus) Atau dengan membelah volume secara permanen (dikenal sebagai "Flex Split" dalam terminologi NetApp ) yang akan membutuhkan waktu untuk menyelesaikan secara permanen delta dan membuat volume yang sama sekali baru dan terpisah.
Klon delta ini memiliki manfaat tambahan untuk mengurangi kebutuhan penyimpanan Anda secara keseluruhan - Anda dapat menelurkan beberapa klon atau instance dari data basis data produksi Anda untuk melakukan pengembangan, pengujian, dan validasi. Jika Anda hanya menyimpan satu salinan set data besar Anda ditambah delta (apa yang kemungkinan besar), Anda mengurangi keseluruhan biaya penyimpanan dan jejak kaki Anda.
Satu-satunya trik di sini adalah bahwa ini mungkin bukan merupakan solusi cadangan penuh karena "cadangan" masih berada di filer Anda. Untuk ini, Anda mungkin perlu menggunakan sesuatu yang NetApp sebut sebagai Snap Mirror yang akan mencerminkan data (menggunakan teknologi gaya rsync) antara pelapor dan bahkan pusat data, atau menggunakan beberapa jenis solusi cadangan terintegrasi yang dapat mencadangkan untuk merekam salah satu foto delta Anda atau flex-clone.
Namun ini memiliki satu kelemahan utama: Semua data Anda - dev, test dan prod masih menggunakan I / O pada filer dan kepala penyimpanan yang sama. Untuk mengatasinya, pertimbangkan untuk membuat instance database slave pada filer kedua yang dapat menjadi titik penyemaian untuk Anda. Test dan / atau dev filer, atau pertimbangkan untuk menggunakan pengontrol pengiriman penyeimbang muatan / aplikasi untuk lapisan aplikasi Anda untuk merefleksikan permintaan produksi ke dalam permintaan Anda. menguji (dan / atau dev) lingkungan. Ini memiliki manfaat tambahan dari membuang lalu lintas produksi di lingkungan QA / Tes Anda sebelum mempromosikan ke produksi untuk masalah yang mungkin tidak segera diketahui. Anda kemudian dapat memeriksa kesalahan log Anda berdasarkan lalu lintas produksi dan perilaku pengguna.
Ini kemudian akan memungkinkan Anda untuk menggunakan beberapa skrip untuk secara program menelurkan dan menghancurkan seluruh set data (dan besar) untuk digunakan dengan metodologi penyebaran berkelanjutan.
Skalabilitas dan Ketersediaan Tinggi
Saat Anda bertanya tentang penerapan berkelanjutan, DevOps memperhatikan lebih dari sekadar penerapan berkelanjutan - jadi saya akan menyertakan beberapa bit tentang redundansi, skalabilitas, dan ketersediaan tinggi.
Saya sebutkan, JIT, konsistensi langsung dan akhirnya. Di sinilah berbagai mesin RDBMS masuk. Konsistensi akhirnya relatif mudah dengan hanya mengkonfigurasi replikasi asinkron melingkar. Namun ini dapat menyebabkan beberapa tabrakan * (bagaimana jika lapisan aplikasi Anda memperbarui data di satu sisi cluster dan di sisi lain dari cluster sebelum replikasi selesai?) Untuk konsistensi segera, lihat kluster Galera yang akan memaksa replikasi sinkron, tetapi menyebabkan masalah skalabilitas (bagaimana Anda akan mereplikasi ke situs Disaster Recovery Anda atau memuat keseimbangan secara geografis tanpa menimbulkan latensi yang signifikan karena penundaan proposisi pada lapisan jaringan?) Anda juga dapat melihat apakah Anda dapat melakukan replikasi sinkron di dalam pusat data dan replikasi asinkron antara situs, tetapi ini tampaknya yang terburuk dari kedua dunia.
Namun biasanya, sebagian besar poeple tidak memerlukan replikasi sepenuhnya sinkron - ini biasanya hanya diperlukan untuk lingkungan penulisan tinggi yang sangat spesifik (dan eksotis) di mana multi-master diperlukan dengan table sharding. Sebagian besar aplikasi dapat menangani konsistensi Just-In-Time menggunakan proxy database. Misalnya, ScaleArc akan memantau status replikasi dan melacak di mana penulisan baru saja berjalan (untuk mengirim permintaan baca subesquent hingga replikasi menyusul) untuk memberikan konsistensi dan penampilan Just-In-Time.konsistensi basis data. ScaleArc kompatibel dengan Postgres, MySQL, MariaDB, Oracle dan MSSQL dan dapat menggunakan ekspresi reguler untuk shard / partisi database Anda untuk aplikasi yang tidak dapat menggunakan kunci shard. Ini juga memiliki API REST yang kuat untuk berinteraksi dengan perangkat lunak manajemen konfigurasi Anda - dan tim dukungan mereka luar biasa
Demikian pula, Anda mungkin ingin mempertimbangkan alternatif gratis, MaxScale dikembangkan oleh tim MariaDB untuk MariaDB. Namun tidak memiliki GUI dan beberapa fitur caching dari ScaleArc.
Akhirnya, fabric MySQL (dan MySQL Cluster hanya dalam RAM - jika Anda mampu membeli RAM sebesar itu) adalah potensi lain - terutama dengan proxy baru MySQL. Ini dapat memberikan komponen skalabilitas dan redundansi untuk lingkungan Anda.
Postgres dan Oracle harus memiliki fitur replikasi dan sharding yang Anda butuhkan, tetapi ScaleArc akan berpasangan dengan baik jika Anda memerlukan proxy.
Pada akhirnya, semua peices ini menambah lingkungan yang sangat fleksibel yang cocok untuk penyebaran dan pengembangan berkelanjutan jika Anda tidak dapat menggunakan lingkungan berbasis cloud dan membiarkan penyedia cloud Anda mengatasi masalah di atas untuk Anda.