Sistem akuntansi perusahaan ditandai dengan peningkatan bertahap dalam volume basis data karena akumulasi informasi historis. Seiring waktu, ukuran basis data dapat mencapai dimensi sedemikian rupa sehingga memicu sejumlah masalah dengan kinerja, pemeliharaan, ruang disk yang tersedia, dan banyak lagi. Hari ini kami mempertimbangkan dua pendekatan untuk memecahkan masalah ini: meningkatkan sumber daya perangkat keras dan melipat data historis.
Pendahuluan
Artikel ini membahas masalah pelipatan basis data besar pada platform MS SQL Server. Solusi untuk masalah ini dijelaskan menggunakan teknologi replikasi DBREPLICATION dari Softpoint.
Masalah
Setiap jenis sistem akuntansi dapat mulai mewujudkan fitur spesifiknya sendiri. Misalnya, dalam sistem berbasis pada platform 1C, muncul masalah dengan operasi rutin seperti memperbarui konfigurasi, memperbarui platform 1C. Seiring bertambahnya basis data, situasi berangsur-angsur memburuk, cepat atau lambat, tindakan harus diambil.
Pendekatan No. 1: perangkat keras
Solusi yang paling jelas dan transparan secara teknis adalah meningkatkan sumber daya perangkat keras. Ini bisa berupa pembelian server yang lebih produktif, penyimpanan disk, dll., Atau penyewaan peralatan yang lebih kuat di pusat data pihak ketiga atau cloud.
Jika Anda pergi dengan cara ini, maka opsi yang baik adalah menempatkan database di cloud Microsoft Azure. Azure menyediakan beberapa opsi arsitektur untuk hosting database: MS SQL pada mesin virtual Azure, dan tiga opsi untuk Azure SQL Database di cloud. Oleh karena itu, dimungkinkan untuk memilih opsi penempatan paling optimal tergantung pada karakteristik basis data tertentu dan kondisi operasinya.
Azure memiliki sejumlah keunggulan dibandingkan dengan membeli peralatan sendiri. Salah satu yang utama adalah kemampuan perangkat keras besar yang Azure dapat sediakan. Serta pendekatan yang fleksibel untuk penggunaan kapasitas ini tergantung pada beban aktual. Misalnya, Anda dapat membeli kapasitas tambahan untuk periode "musim tinggi" bisnis Anda, atau pada akhir periode pelaporan, sehingga puncak dapat lewat tanpa masalah. Dan sisanya, gunakan konfigurasi sumber daya yang lebih murah. Jadi, di satu sisi, pada saat yang tepat, Anda memiliki akses ke potensi sumber daya Azure yang sangat besar (yang, omong-omong, terus tumbuh sepanjang waktu), dan di sisi lain, Anda tidak dapat membayar lebih untuk kapasitas berlebih saat Anda tidak membutuhkannya.
Namun, meskipun relatif sederhana, meningkatkan sumber daya perangkat keras bukanlah solusi universal. Pertama, efek positif seringkali jauh dari proporsional dengan investasi keuangan (ada banyak investasi - ada sedikit efek). Kedua, efeknya bersifat sementara, karena pangkalan terus tumbuh dan membutuhkan lebih banyak sumber daya, lebih banyak investasi keuangan.
Bagaimanapun, pendekatan ini memiliki hak untuk hidup, dan digunakan secara luas. Tetapi kita tidak akan memikirkannya lagi, karena tujuan utama artikel ini bukanlah pendekatan "perangkat keras", tetapi "perangkat lunak", yang dijelaskan di bawah ini.
Pendekatan No. 2: belokan pangkalan
Solusi yang lebih radikal adalah konvolusi basis data, yaitu penghapusan data historis yang tidak relevan darinya. Dalam database yang runtuh hanya ada data untuk periode operasional yang relatif kecil, biasanya tidak lebih dari 1-2 tahun. Jelas, tingkat pengurangan dalam setiap kasus berbeda, dan sulit untuk menyebutkan nomor tertentu. Namun, untuk pedoman, kami akan mengambil indikator penurunan basis sebesar 50-70%, yaitu, sekitar 2-3 kali, tentang jumlah yang sama paling sering dan ternyata dalam praktiknya, lebih sedikit atau sebaliknya lebih - jarang terjadi.
Kami tidak akan memikirkan hasil kemenangan. Jelas, jika basis berkurang 2-3 kali atau lebih, efek kinerja akan sangat kuat dan jangka panjang, dan investasi tambahan dalam komponen perangkat keras dapat dihindari. Dan mekanisme konvolusi, setelah dikembangkan dan dijalankan, dapat digunakan kembali di masa depan. Secara umum, ini adalah solusi yang sangat efektif dengan hasil yang terjamin.
Kompleksitas implementasi konvolusi
Tetapi untuk semua efektivitasnya, konvolusi memiliki satu masalah yang sangat besar. Dan itu bahkan bukan masalah mengembangkan mekanisme konvolusi itu sendiri. Ya, pengembangan ini juga merupakan tugas yang sulit, tetapi entah bagaimana diselesaikan. Masalahnya berbeda. Ketika database memiliki ukuran beberapa ratus gigabyte atau telah melewati garis terabyte, ternyata secara fisik sangat sulit untuk melakukan operasi pelipatan. Tak pelak, seluruh kerumitan kesulitan yang saling berkaitan muncul, mari kita pertimbangkan.
- Intensitas sumber daya dari operasi lipat - peralatan sangat banyak dimuat.
- Selama konvolusi, tidak hanya sejumlah besar data yang dihapus secara fisik, tetapi juga banyak operasi intensif sumber daya terkait dilakukan: berbagai pilihan, pemeriksaan, pengelompokan, pengindeksan, pencatatan, pemindahan data antar tabel dan sebagainya. Fakta ini sangat penting karena database yang dapat dilipat, sebagai suatu peraturan, sudah sangat dimuat, dan tidak memiliki kelebihan kapasitas.
- Gangguan kepada pengguna.
- Sangat sulit atau tidak mungkin untuk melakukan konvolusi secara langsung dalam database yang bekerja secara paralel dengan kerja pengguna karena tingginya beban tambahan dan kunci yang dibuat oleh proses konvolusi.
- Tidak ada jendela teknologi.
- Jendela teknologi dengan durasi yang cukup, ketika pengguna tidak bekerja, sama sekali tidak tersedia untuk berbelit-belit. Setelah semua, proses pelipatan untuk database ukuran ini biasanya puluhan jam atau beberapa hari.
- Risiko tinggi saat melipat langsung ke pangkalan kerja.
- Pendekatan, ketika algoritma konvolusi diterapkan langsung ke pangkalan kerja, itu sendiri sangat berisiko karena sejumlah alasan. Salah satunya - kemungkinan untuk verifikasi akhir dari hasil konvolusi sangat terbatas (tidak ada waktu).
- Durasi pendekatan iteratif yang tidak dapat diterima.
- Anda dapat mencoba untuk menghindari kemacetan - jendela teknologi, dan memotong langsung di basis produksi dalam porsi kecil iteratif, memilih ukuran setiap bagian sehingga cocok dengan jendela teknologi yang ada. Tetapi jalur ini juga paling sering tidak dapat diterapkan, karena, pertama, proses pemangkasan membentang untuk periode yang sangat lama (berminggu-minggu atau berbulan-bulan), dan kedua, kompleksitas mekanisme pelipatan meningkat tajam, total biaya untuk memastikan proses pemangkasan yang tidak terputus untuk waktu yang lama. , risiko proyek secara keseluruhan meningkat secara radikal.
- Bagaimana cara mengompres void dalam file data !?
- Selama penghapusan informasi historis dari database, file datanya tidak benar-benar berkurang (dan seringkali bahkan sedikit meningkat), itu hanya menciptakan kekosongan besar di dalamnya. Dan Anda perlu entah bagaimana menyingkirkan mereka sehingga file data berkurang. Jika tidak, keuntungan hilang dalam hal ruang disk. Salah satu opsi adalah untuk mengeksekusi SHRINK yang khas. Dan pada volume seperti itu, ini adalah prosedur yang sangat panjang (berjam-jam, atau bahkan puluhan jam).
Dengan demikian, konvolusi adalah tugas yang sangat sepele. Tidak cukup untuk mengembangkan mekanisme konvolusi, juga perlu diterapkan. Apalagi aplikasi sering menjadi hambatan.
Catatan: Selanjutnya, kita meninggalkan tanda kurung pengembangan mekanisme konvolusi itu sendiri (dengan kata lain, algoritma untuk menghapus data historis), tidak peduli apa artinya itu dibuat. Dan kami hanya fokus pada penerapan mekanisme yang sudah diterapkan dalam pertempuran.
Solusi Menggunakan DBREPLICATION
Tampaknya jalan buntu. Namun masih ada solusi. Ada teknik yang efektif yang memungkinkan Anda untuk mengurai seluruh kesulitan, menghilangkan risiko dan dijamin untuk mencapai tujuan. Ini melibatkan penggunaan teknologi pertukaran data DBREPLICATION. Solusi ini cocok untuk opsi infrastruktur tradisional dan Microsoft Azure berbasis cloud. Secara singkat, intinya adalah sebagai berikut.
- Klon basis data dibuat, pertukaran data satu arah antara klon dan basis data utama dikonfigurasikan menggunakan DBREPLICATION. Diijinkan bahwa basis data utama dan / atau klonnya berada (keduanya atau salah satunya) di cloud Microsoft Azure.
- Dalam klon, pengguna tidak bekerja, di sana proses konvolusi dimulai. Karena proses pelipatan tidak mengganggu siapa pun, ia dapat bertahan di sana sepanjang hari tanpa gangguan selama yang diperlukan. Dengan demikian, tautan ke durasi jendela teknologi menghilang!
- Pengguna tanpa gangguan bekerja di basis data utama. Dan teknologi DBREPLICATION secara otomatis mentransfer semua perubahan dari database utama ke yang dapat dilipat dengan kecepatan tinggi. Dengan demikian, klon terbaru dalam hal data operasional.
- Setelah penyelesaian konvolusi, sebagai suatu peraturan, verifikasi terperinci hasil dilakukan dengan melibatkan spesialis teknis dan pengguna bisnis Pelanggan. Dan proses ini bisa bertahan cukup lama (beberapa jam atau berhari-hari). Dalam metodologi yang dipertimbangkan, praktis tidak ada batasan waktu, oleh karena itu, verifikasi dapat dialokasikan sebanyak waktu yang diperlukan.
- Setelah menyelesaikan konvolusi dan verifikasi, semua pengguna beralih ke klon terpotong, dan sejak saat itu menjadi basis utama. Dan pangkalan yang tidak disunat asli berfungsi sebagai arsip data historis.
- Keuntungan tambahan adalah kemampuan untuk mengubah replikasi ke arah yang berlawanan ketika pengguna beralih ke database yang diminimalkan. Ini memberikan keamanan tambahan, karena jika “ada masalah”, Anda dapat dengan cepat mengalihkan pengguna kembali ke database yang tidak disunat tanpa kehilangan data yang dimasukkan.
- Jika ada kebutuhan untuk tetap memperbarui basis data arsip, Anda dapat mengalihkan replikasi ke arah yang berlawanan dan mentransfer perubahan dari basis data yang diperkecil ke basis data arsip.
Fig. 1. Diagram skematik pemangkasan basis data menggunakan teknologi DBREPLICATION.
Fig. 2. Opsi untuk meng-host basis data yang dapat dilipat di cloud MS Azure.
Dengan demikian, teknik konvolusi yang dijelaskan dalam basis data klon memperluas semua kemacetan. Menghilangkan ketergantungan pada jendela teknologi. Dalam klon, paket tidak mengganggu siapa pun, dan tidak ada yang mengganggunya. Anda dapat dengan aman menggunakan sumber daya maksimum dari klon, dan juga cukup memperhatikan verifikasi akhir.
Masih harus dipahami teknologi pertukaran mana yang dapat digunakan dalam skema ini? Mengapa DBReplikasi?
Mengapa DBReplikasi?
Dalam metodologi yang dijelaskan, elemen kunci adalah teknologi pertukaran, yang memastikan sinkronisasi database yang dipangkas dengan yang utama. Pada prinsipnya, teknologi pertukaran dapat berupa apa saja jika memenuhi tiga syarat utama:
- Kompatibilitas dengan platform aplikasi bisnis, yang pangkalannya runtuh.
Contoh: Jika kita meruntuhkan basis data 1C, maka tidak setiap teknologi pertukaran kompatibel dengan struktur dasar 1C, khususnya, Replikasi Transaksi MS klasik tidak kompatibel, karena membuat perubahan pada struktur tabel.
- Performa. Teknologi pertukaran harus dijamin untuk mengatasi aliran perubahan yang terjadi di pangkalan kerja selama konvolusi.
Penjelasan: dalam artikel ini, kami terutama berarti database yang sangat banyak dengan tingkat perubahan data yang tinggi. Konvolusi akan berlangsung puluhan jam, mungkin beberapa hari, bahkan mungkin akan ada lebih dari satu iterasi konvolusi. Selama waktu ini, pengguna akan membuat perubahan besar. Banyak teknologi berbagi tidak bisa mengatasinya. Dan Anda tidak perlu hanya mengatasinya, disarankan untuk mengatasi pasokan.
- Penerapan utama untuk kondisi masalah.
Penjelasan: mungkin poin ini tampak jelas, tetapi bagaimanapun kita dapat memilihnya. Yaitu: jangan lupa bahwa data dalam database sumber dan dalam klon tidak sama satu sama lain! Fakta ini secara otomatis menyapu seluruh kelas teknologi yang kuat dan produktif berdasarkan sinkronisasi log transaksi - selalu aktif, pengiriman log, mirroring, dll.
Selain itu, teknologi pertukaran harus efektif dalam hal indikator lain:
- Keandalan dan otonomi berfungsi. Karena kita berbicara tentang transfer data dalam jumlah besar, dan untuk beberapa waktu, tim proyek tidak akan memiliki kemampuan fisik untuk secara manual menangani masalah pertukaran, tabrakan dan kegagalan, kontrol kualitas data, dll. Oleh karena itu, teknologi pertukaran harus seandal mungkin dalam hal kualitas data yang dikirimkan, seotonom dan seotomatis mungkin.
- Antarmuka pengguna yang berkualitas untuk kontrol dan manajemen.
- Mudah digunakan dan dikonfigurasikan. Teknologi pertukaran tidak boleh memaksakan persyaratan yang terlalu tinggi pada kualifikasi spesialis untuk penyesuaiannya.
Tanpa kualitas-kualitas ini, teknologi pertukaran mengancam untuk berubah dari elemen kunci yang menyelamatkan dari metodologi ke dalam “mata rantai yang lemah”, memperkenalkan risiko serius dan mengancam seluruh proyek. Dan kemudian ide aslinya kehilangan artinya.
Namun, teknologi DBReplication tentu memenuhi semua persyaratan dan memastikan keberhasilan proyek rollup.
Perhatikan faktor-faktor utama yang menyebabkan DBReplication berhasil dalam tugas ini:
- Nilai tukar yang sangat tinggi. Perhatikan beberapa fitur yang memberikan kecepatan:
- DBReplication adalah replikasi transaksional, setiap perubahan mulai ditransmisikan segera setelah transaksi dilakukan;
- Dalam arsitektur internal subsistem transportasi, solusi seperti pemrosesan antrian paralel multithreaded, pendekatan pipelined, kompresi aliran, pemrosesan transaksi batch, penggunaan Bulk Insert dan lainnya digunakan.
- Transport dilaksanakan berdasarkan layanan Windows, dilengkapi dengan banyak fitur untuk memastikan kelancaran operasi. Ini termasuk: pemulihan pertukaran otomatis setelah gangguan komunikasi, bekerja pada saluran komunikasi lemah yang tidak stabil, pemrosesan otomatis konflik versi (untuk pertukaran dua arah), adaptasi otomatis jika terjadi perubahan dalam struktur tabel tabel aplikasi bisnis, dan lainnya.
- Mekanisme pengiriman data terjamin. Kepatuhan yang ketat terhadap integritas transaksional dan konsistensi dalam mentransfer perubahan.
- Tidak mengubah struktur tabel aplikasi bisnis. Oleh karena itu, khususnya, dapat berhasil digunakan saat melipat basis data 1C.
- Antarmuka pengguna yang dikembangkan yang memungkinkan Anda mengelola sistem pertukaran "dari satu jendela" secara terpusat, semua informasi layanan dikumpulkan dan ditampilkan secara online.
- Mudah digunakan dan dikonfigurasikan.
- Diadaptasi untuk platform 1C. Pengguna tidak bekerja dengan tabel, tetapi dengan objek metadata 1C akrab.
- Semua versi MS SQL, mulai dari 2005, dari Standard hingga Enterprise, keduanya disebarkan secara lokal dan berlokasi di cloud MS Azure; dari sudut pandang Azure, baik hosting mesin virtual dan opsi hosting Azure SQL DB diizinkan, termasuk contoh yang dikelola dari Database SQL Azure ( Instance yang Dikelola ).
- DBReplication adalah solusi andal yang siap pakai yang telah diuji oleh banyak proyek dalam berbagai kondisi dan tugas.
- Jika DBREPLICATION digunakan dalam mode pertukaran satu arah, arah pertukaran dapat diaktifkan.
Selain itu, kami mencatat satu fitur penting:
- DBREPLICATION dapat beroperasi dalam mode pertukaran dua arah, ketika dimungkinkan untuk memasukkan / mengubah data secara bersamaan di semua database yang berpartisipasi dalam pertukaran. Jumlah pangkalan yang dapat dimasukkan dalam sirkuit pertukaran tidak terbatas.
Contoh aplikasi praktis
Perusahaan besar Rusia memiliki sistem akuntansi aplikasi berbasis pada platform 1C 8 + MS SQL Server. Basis operasional utama telah lama melangkah lebih dari 2 terabyte dan terus berkembang. Pada saat yang sama, beban semakin meningkat: transaksional dan analitik. Pada akhirnya, sejumlah alasan dibentuk untuk konvolusi pangkalan. Diputuskan untuk memangkas data historis untuk awal 2017. Teknik yang dijelaskan di sini menggunakan DBReplication dipilih.
Dalam dirinya sendiri, algoritma konvolusi diputuskan untuk diimplementasikan terutama oleh TSQL dengan inklusi kecil dari alat 1C yang khas. Tugas ini diperumit oleh fakta bahwa tidak semua objek yang diterapkan (tabel) dapat runtuh pada tanggal yang dijadwalkan, karena fitur bisnis mensyaratkan bahwa dalam sejumlah subsistem terbesar, data historis hadir secara penuh hingga kedalaman 5-7 tahun. Oleh karena itu, dari sudut pandang volume database, efek konvolusi tidak sebesar yang kita inginkan. Analisis pendahuluan dilakukan, yang menunjukkan bahwa, dengan mempertimbangkan batasan obyektif, sekitar 33% dari volume awal akan terpotong. Tetapi ini dievaluasi oleh Pelanggan sebagai hasil yang baik, karena keuntungan tidak hanya dalam volume basis data seperti itu, tetapi juga dalam kecepatan masing-masing tabel, dan tabel subsistem yang runtuh menurun volumenya lebih dari 33% - dari 46% menjadi 77% (dalam 2- 3 kali).
Mari kita lihat lebih dekat beberapa indikator dan fakta penggunaan konvolusi yang sebenarnya. Durasi konvolusi data langsung adalah sekitar 12 jam. Sinkronisasi akumulasi perubahan menggunakan DBREPLICATION memakan waktu sekitar 1 jam. Salah satu poin utama dari proyek ini adalah verifikasi akhir dari pangkalan yang diminimalkan, yang dilakukan oleh spesialis Pelanggan. Penting untuk diperhatikan durasinya - proses ini memakan waktu sekitar 1 minggu. Durasi ini disebabkan oleh fakta bahwa verifikasi sangat mendalam dan komprehensif, dengan keterlibatan spesialis dari berbagai profil, termasuk pembangunan model data dalam sistem eksternal. Selama ini, markas yang diperkecil secara otomatis disinkronkan dengan database pertarungan saat ini melalui DBREPLICATION. Verifikasi berhasil. Dan pengguna dialihkan ke database yang diciutkan. Basis data sebelumnya dipindahkan ke status arsip, dengan akses hanya baca. Tidak perlu sinkronisasi berikutnya, jadi replikasi dinonaktifkan.
Ringkasan Proyek:
- Teknik yang diterapkan benar-benar terbayar, berkat itu ada cukup waktu untuk menyelesaikan konvolusi itu sendiri, serta untuk memverifikasi data secara komprehensif, yang secara radikal meminimalkan risiko melewatkan kesalahan tertentu dan beralih ke database yang runtuh.
- Konvolusi berhasil diselesaikan:
- Total volume database operasional menurun sebesar 33%. Itu tidak mungkin untuk mencapai efek yang lebih besar pada volume database karena alasan obyektif, karena pembatasan pada lipatan beberapa subsistem besar.
- Volume tabel yang digunakan secara aktif dari subsistem yang runtuh menurun 46-77% (2-3 kali).
Kesimpulan
DBReplication adalah solusi andal yang siap pakai yang telah hadir di pasar selama bertahun-tahun, diuji oleh banyak proyek dalam berbagai kondisi. Dalam teknik konvolusi yang sedang dipertimbangkan, DBReplication sepenuhnya mengambil salah satu sub-tugas utama - sinkronisasi basis data. Dalam kasus database yang sangat besar, persyaratan yang sangat ketat diberlakukan pada sistem pertukaran, dan DBReplication sepenuhnya memuaskan mereka. Ini menyelesaikan tugasnya dengan andal dan efisien, sehingga memastikan keberhasilan proyek secara keseluruhan.
Untuk tugas apa lagi Anda bisa menggunakan DBREPLICATION
Serangkaian fitur dan keunggulan kompetitif memungkinkan DBReplication digunakan untuk menyelesaikan sejumlah masalah. Untuk referensi, kami mencantumkannya.
- Redundansi database dan toleransi kesalahan.
- Load balancing: mendistribusikan ulang antara 2 atau lebih contoh database yang sinkron.
- Transisi terkendali ke versi perangkat lunak baru (MS SQL, 1C), teknik ini mirip dengan teknik konvolusi.
- Membangun sistem informasi terdistribusi dengan pertukaran kecepatan tinggi berdasarkan DBReplication. Secara khusus, mengganti teknologi pertukaran perusahaan yang ada dengan DBREPLICATION yang lebih produktif dan efisien.