Teknoloji Geçişi Stratejileri hakkında eksiksiz bir kılavuz: (Bölüm 3 – Veritabanı Geçişi)
Yayınlanan: 2020-12-25Yeni bir daire satın aldığınız, taşınmak için toplandığınız ve süreci dikkatlice planladığınız bir senaryo hayal edin. Hepiniz yeni evinize taşınmaya hazırsınız, sonra aniden fark ediyorsunuz – bir sorun var. Mobilya ve eserler yeni dairenize pek uymuyor.
Tüm mobilyalarınızı çöpe atmanız ve sıfırdan başlamanız gerekseydi nasıl hissederdiniz? Bu benzetmeyi daha da ileri götürerek, yeni daireyi yeni veritabanınız ve mobilyayı da veri olarak düşünün. Verilerin işletmeniz için mobilyalardan çok daha önemli olacağından eminiz ve bu nedenle, geçiş yapmayı planlarken verilerin her bir parçasını saklamak isteyeceksiniz.
Teknoloji geçişi serimizin devamı olarak, bu blogda, veritabanı geçişinin (DBM) temellerini, veritabanı geçişini gerçekleştirirken neleri anlaması, dikkate alması ve nelere dikkat etmesi gerektiğini ortaya çıkarmaya çalışacağız.
Veritabanı Geçişine neden ve ne zaman ihtiyaç duyulur?

Önceki uygulama geçişi blogumuzun bir devamı olarak, bugünün parçası veritabanı geçişi (şema geçişi olarak da bilinir) etrafında yoğunlaşıyor çünkü bu, esas olarak verileri bir veritabanı çerçevesinden diğerine aktarma/güncelleme ile ilgilenen en önemli geçişlerden biridir. bir diğer.
Temel olarak, veritabanı geçişi ihtiyacı, bir iş gereksinimine veya hatta çeşitli düzenleyiciler tarafından oluşturulan en son çoklu düzenleyici politikaları karşılamaya özel olabilir. DBM'nin gerekli olduğu tanımlanmış durumlar bulunmamakla birlikte, bunun kaçınılmaz olduğu bazı durumları listeledik:
- Yaygın bir neden, eski sisteminizi iş gereksinimlerinizi ve modern veri ihtiyaçlarınızı karşılayan bir sisteme taşımaktır. Büyük Veri çağında yeni ve modern depolama teknikleri bir zorunluluk haline geldi.
- Bazı düzenleyiciler, verilerin yalnızca belirli bir coğrafyada kalmasını zorunlu kılmıştır. Bu nedenle, dağıtılmış verilerin tek bir konuma taşınmasını gerektirir.
- Bazı Şirketler, şirket içi bir veritabanını bir bulut veritabanına taşımayı tercih eder. Bu genellikle, verileri desteklemek için gereken altyapı ve uzmanlık kaynaklarından tasarruf sağlar ve ayrıca sistemleri daha hızlı hale getirir.
- Yeni bir platforma geçiş, kapsamlı veri bütünlüğü sağlar. Depolama ve medya maliyetlerini azaltır, bu da yatırım getirisinde önemli iyileşme sağlar.
- Günümüzün birçok şirketi, tüm verilerini tek bir yerde tutmak istiyor. Bu şekilde verilere şirketin tüm departmanları tarafından erişilebilir.
Veritabanı sistemini yeni bir platforma taşımak, günlük iş operasyonlarında meydana gelen kesintiyi azaltır. Yeni bir veritabanı platformunun seçimi akıllıca yapılırsa, bu minimum manuel çabayla yapılabilir.
Veritabanları Türleri
Veritabanı taşıma işlemine geçmeden önce, farklı veritabanları türlerine bir göz atalım:

- İlişkisel Veritabanı – İlişkisel veritabanları, veritabanı endüstrisinin işgücü olarak bilinir. Bu veritabanları bir dizi tablo tarafından sınıflandırılır. Tablolar, satırın veri örneğini içerdiği ve sütunun belirli bir kategori için veri girişini içerdiği satır ve sütunlardan oluşur. SQL – Structured Query Language, İlişkisel Veritabanı için standart bir programlama arabirimidir.
- Dağıtılmış Veritabanı – Adından da anlaşılacağı gibi, veriler herhangi bir kuruluşun çeşitli sitelerinde dağıtılır. Siteleri birbirine bağlamak için iletişim bağlantıları kullanılır. Bu, dağıtılmış veritabanına kolayca erişmeye yardımcı olur.
- Nesneye Yönelik Veritabanı – Bu tür veritabanı, ilişkisel veritabanı ve nesne yönelimli programlamanın özniteliklerini birleştirir. C++ ve Java'da oluşturulan çeşitli öğeler ilişkisel veritabanlarında saklanabilir, ancak nesne yönelimli bir veritabanı onlar için daha uygundur.
- NoSQL Veritabanı – NoSQL veritabanı, birden çok sanal sunucuda depolanan büyük yapılandırılmamış verileri verimli bir şekilde analiz edebilir. Buna karşılık, ilişkisel bir veritabanı bazı büyük veri performanslarını verimli bir şekilde işleyemez. NoSQL veritabanları bu tür durumları kolayca yönetebilir ve büyük bir dağıtılmış veri kümesi için kullanılır.
- Bulut Veritabanı – Bulut Veritabanı, kullanım başına ödeme esnekliği sağlayan sanal bir ortamdır. Kullanıcının yalnızca gereksinimlerine uygun bant genişliği ve depolama kapasitesi için ödeme yapması gerekir.
- Grafik Veritabanı – Basit bir ifadeyle, bir grafik, düğümler ve kenarlar topluluğudur. Grafik Veritabanı, varlıkları temsil eden düğümleri içerir ve uç, bu varlıklar arasındaki ilişkileri tanımlar. Bir tür NoSQL veritabanıdır ve ilişkileri haritalamak, depolamak ve sorgulamak için grafik teorisini kullanır.
- Merkezi Veritabanı – Bu tür veritabanı ile veriler tek bir merkezi konumda depolanır. Veritabanı, esasen, kullanıcıların DB'ye uzak konumlardan da erişmesine izin veren uygulama prosedürlerini içerir.
Veritabanı Taşıma Yaklaşımları
Verileri bir veritabanı platformundan diğerine geçirmek çok önemli bir görev olabilir. Geçiş, CANLI bir Ortamda planlanıyorsa, geçiş çok dikkatli yapılmalıdır. Veri geçişi ile ilerlemeden önce uygun bir geçiş süresi seçilmelidir. Canlı sistemler, veriler yeni bir veritabanına aktarılırken genellikle kesinti yaşar.
Veritabanı geçişi için temel olarak iki yaklaşım vardır:
Büyük Patlama Veri Göçü:
Bu yaklaşım, sınırlı bir zaman çerçevesinde bir kerede tüm veritabanını taşımayı seçtiği yerdir. Büyük patlama veri geçişi daha az karmaşık görünse de, canlı web sitesi için yeterli kesinti süresi gerektirir. Ayrıca, bu yaklaşımla, geçişin herhangi bir anda başarısız olması durumunda geçiş sürecinin tamamen geri alınması kolay olmayabilir.
Trickle Veri Taşıma
Bu yaklaşımla, göç sürecini daha küçük parçalara veya fazlara bölmek gerekir. Neredeyse geçişe çevik bir yaklaşım gibi, tek bir aşama başarısız olursa, yalnızca o aşamanın geri alınması ve sürecin tekrarlanması gerekir. Ancak, Trickle veri geçişi oldukça zaman alıcıdır ve bu nedenle proje maliyetini artırabilir.
Farklı Göç Türleri

İlişkisel DB'den İlişkisel DB'ye
Bu yaklaşım en yalındır geçiştir. Bu tür geçişi oldukça verimli, neredeyse %100 etkili gerçekleştiren tonlarca araç mevcuttur.
İlişkisel DB'den İlişkisel Olmayan DB'ye ve tam tersi
Bu göç, yukarıda bahsedilene göre daha zordur. İlişkisel DB ve İlişkisel Olmayan DB temelde farklı olduğundan, geçişleri %100 verimli olmayabilir. Esasen, İlişkisel Olmayan DB'ye geçiş, bir veritabanının ölçeklenebilirliğini garanti eden ACID özelliklerinden (atomik, tutarlı, yalıtılmış ve dayanıklı) fedakarlık etmek anlamına gelir.
Ancak, İlişkisel'den İlişkisel Olmayan DB'ye veritabanı geçişini destekleyen birden fazla ücretsiz araç vardır. Bu araçlar sistemin şema yapısını desteklemediğinden ve çoğu sistem gereksinimlerini uyarlamak için çok katı göründüğünden, bunların kullanılması yaygın olarak önerilmemektedir.
Düşünebileceğimiz bu tür bir geçiş için sunabileceğimiz bazı temel dönüşüm ipuçları olsa da (kolaylık olması için MySQL'i İlişkisel Veritabanımız ve MongoDB'yi İlişkisel Olmayan Veritabanımız olarak düşünelim)

- MySQL String veri türünü MongoDB'de String'e dönüştürün. Bu, karakter, varchar, blob, metin vb. içerebilir.
- MySQL Sayısal veri türünü MongoDB'de Sayıya dönüştürün. Bu, int, float, decimal, double, vb. içerebilir.
- MySQL Date veri türünü MongoDB'de Date'e dönüştürün. Bu tarih, yıl, zaman damgası vb. içerebilir.
- MongoDB'de MySQL Bool & Boolean veri türünü Boolean'a dönüştürün.
- Diğer durumları da aynı şekilde değerlendirebilirsiniz.
Hibrit Modelle Taşıma
Hibrit model tasarımı, iki popüler veritabanı modelini tek bir çerçevede birleştirirken, her sistemin dezavantajlarını azaltır. Örneğin, veri yoğun girişimler için ilişkisel olmayan bir DB ile birlikte daha az talepkar işlemler için İlişkisel DB'den yararlanabileceğimiz hibrit bir yaklaşımla her zaman gidebiliriz.
Veri yedekleme
Yürütme öncesinde geçiş stratejisini planlamak, sorunsuz bir geçiş süreci sağlayabilir. Bununla birlikte, her zaman bir Plan B'ye ihtiyacımız var. Bazı veri kayıplarının olduğu veya geçiş yapılırken verilerin bozulduğu en kötü durum senaryosunu varsayarsak; yeniden denemeden önce verileri orijinal durumuna geri yüklemeye hazır olmalısınız. Bu nedenle Veri Yedekleme, DBM (Veritabanı Geçişi) sırasında oldukça zorunlu bir adımdır. Peki, güvenli veri yedeklemesi sağlamak için hangi seçenekler var, hadi bakalım.

Bulut yedekleme

Geçiş girişiminizi korumanın en verimli ve güvenli yöntemlerinden biri, bulut depolamaya yedekleme yapmaktır. Temel olarak, verilerinizi bulut depolamaya yedeklediğinizde dosyalarınız site dışında depolanır. Bu, sorunlara neden olabilecek yerel donanım güvenlik açıklarını ortadan kaldırır. Peki, neden bir bulut yedeklemesi?
- Bulut yedeklemeleri, yalnızca kullanım başına ödeme yapmanız gerektiğinden ekonomiktir.
- Bulut yedeklemesi, uçtan uca şifreleme sağladığı için güvenlidir.
- Kolay felaket kurtarma ve veri geri yüklemesi sağlar
- Güçlü bulut yedekleme seçenekleri, sistem görüntüsünün tüm yedeklemesini içerir. Bu nedenle, işletim sistemini yeniden yüklemeniz gerekmez. Bilgisayarlar ve sunucular, çalışan son sürüme geri yüklenir.
Dosya paylaşım yazılımı

Dropbox gibi yazılım paketleri, kullanıcılarının ihtiyaçlarını karşılamak için büyüyor. Dropbox, gerektiğinde geri yüklenebilecek dosya sürümlerini korur. Bulut yedeklemeye benzer şekilde, bu seçenek uygun maliyetlidir ve dosyalar site dışında depolanır. Avantajları nelerdir?
- Dosyalar herhangi bir konumdaki herhangi bir sisteme geri yüklenebilir.
- Ücretsizdir ve işbirliğini destekler.
- Son derece güvenli (bulut depolama, aktarım sırasında dosyalarınızı şifreler)
- Çevrimdışı Çalışma Yetenekleri
Ancak bir dezavantajı, restorasyonun otomatik olmamasıdır. Verileri kaydetmek için dosya paylaşım dizini yapısına kopyalayıp yapıştırmanız gerekir. Dosyalar tanımlanmış bir yapıda bulunmalıdır, aksi takdirde yedeklenmezler. Dosyalar paylaşılan bir klasörde veya dizindeyse, bu dosyaları yedeklemek için muhtemelen daha fazla bant genişliğine ihtiyacınız olacaktır.
Genel olarak konuşursak, bir flash sürücüye veya harici sabit sürücüye yedekleme gibi yedekleme için mevcut başka ortamlar da vardır. Ancak bu seçenekler, bulut yedekleme veya dosya paylaşım yazılımlarına kıyasla tamamen güvenli olmadıkları için önerilmez. Örneğin, bir sabit sürücüdeki herhangi bir fiziksel hasar veri kaybına neden olabilir. Ayrıca, fidye yazılımı saldırılarına ve kripto virüslerine karşı daha savunmasız ve hassastırlar.
Verilerin güvenli olduğundan nasıl emin olunur?
Veri taşıma işlemini gerçekleştirirken, hassas verilerin ihlal edilmediğinden veya değiştirilmediğinden emin olmanız gerekir. Geçiş yanlış giderse, daha büyük sonuçlara yol açabilir ve 2020'de burada belirtilen örneklerde olduğu gibi veri sızıntılarına veya veri kaybına neden olabilir.
Ne yazık ki, veri sızıntıları müşterinin itibarına zarar verebilir, iş ve müşteri kaybına yol açabilir; veya bazı durumlarda yasal işlemlere neden olabilir. Tüm bu sonuçlardan kaçınmak için, geçiş stratejisini göz önünde bulundurarak önceden bir güvenlik planı hazırlamanız gerekir.
- Başlangıç olarak, güvenilir ve güvenli sunucu erişimi ve veri erişimi öncelik listenizde olmalıdır.
- Veri aktarımı için gerekli izinlerin sayısını artırın. Daha büyük kuruluşlarda, güvenlik departmanları sunuculara erişimi sınırlar ve ilgili sunucular arasındaki veri geçişini tanımlar.
- Daha fazla taraf söz konusu olduğunda veriler yüksek risk altındadır. Bu nedenle, taşınabilir depolama aygıtları veya e-postalar aracılığıyla taraflar arasında aktarım yapmaktan kaçının. Bu gibi durumlarda, veriler kolayca tehlikeye girebilir.
- Verilerin güvenli erişimini, depolanmasını ve alınmasını sağlamak için sürekli olarak şifreleme ve şifre çözme uygulaması yapılmalıdır. Maksimum veri güvenliğini sağlamak için hibrit şifreleme algoritmalarını kullanabilirsiniz. Ama bu herkese tavsiye edilmez. Taşıma başarısız olursa, veriler dağınık hale gelir ve veri bozulmasına veya veri kaybına neden olabilir.
Güvenli geçişi sağlamak için ilkel araçları kullanmaktan kaçının. İlkel araçları kullanmak, sisteminizi zayıflatabilir ve bilgisayar korsanlarının erişmesi için boşluklar bırakabilir. İşlevsel olarak spesifik olan veri geçişi için sağlam araçlar kullanmalısınız.
Veri Taşıma Süreci
Veri geçişi temelde çok aşamalı bir süreçtir ve veri kaybını önlemek ve güvenli veri tabanı geçişini sağlamak için aşağıdaki adımlar izlenmelidir.
- Değerlendirme :
- İş gereksinimleri analizini toplayın ve DBM ile ulaşılması gereken temel hedefi tanımlayın.
- Kapsamı tanımlayın
- Kapsamlı Veri profili oluşturma:
- Kaynak verileri, veri biçimini gözden geçirin, şema yapısını, içeriği ve veri örnekleri arasındaki ilişkileri gözden geçirin
- Hedef sistemi anlayın
- Paydaşları tanımlayın
- Tüm aktiviteyi bütçeleyin
- Veri yedekleme
- Taşımakta olduğunuz verilerin güvenli bir şekilde yedeklendiğinden emin olun. Bulut yedekleme kullanılması önerilir.
- Hedefin temiz olduğundan ve herhangi bir veri hackine karşı korunduğundan emin olun.
- Kaynak kullanılabilirliği :
- Hedef sistem için geçiş ve kapalı kalma süresi için kullanılabilirlik süresi.
- İşe alınan insan kaynağının doğru becerilere sahip olduğundan emin olun.
- Doğru aracı ve komut dosyalarını belirleyin.
- Veri Taşıma Yürütme :
- Geçiş süreci, verileri taşımak için komut dosyası oluşturma, ETL araçları veya diğer karşılaştırılabilir araçları içerebilir.
- Geçiş sırasında verileri dönüştürecek, veri türlerini normalleştirecek ve sonunda olası hataları kontrol edeceksiniz.
- Test ve Ayarlama :
- Ekip ve müşteri ekibinin, tüm verilerin doğru şekilde taşındığından kritik olarak emin olması gerekir.
- Bu nedenle verilerin doğru taşınıp taşınmadığını, verilerin eksiksiz olup olmadığını kontrol edin ve eksik değer olmadığından emin olun.
- Ayrıca, verilerin geçerli olduğundan ve herhangi bir boş değer içermediğinden emin olun.
- Herhangi bir veri uyuşmazlığı olması durumunda veri geri alma işlemi yapılmalı ve tüm süreç yeniden başlatılmalıdır.
- Denetim
Yeni veritabanı canlı olduğunda, verileri denetlemek için bir sistem kurulabilir. Bu, veritabanı geçişinin doğruluğunu sağlayacak ve eksik ve yanlış verilere dikkat çekecektir.
Veritabanı Taşımayla İlgili Potansiyel Riskler

Veritabanı Geçişi oldukça karmaşık bir prosedürdür ve riski ve belirsizliği ile birlikte gelir. Doğru planlama ve uygulama ile bunların üstesinden her zaman gelebilirsiniz. Karşılaşılabilecek riskler şunlardır:
- Güncel olmayan kaynak sistemleri: Burada, veri kaynağı güncel değil, Yedekli, Eski veya Önemsiz olabilir.
- Farklı veritabanı mimarisi: Bu senaryoda, kaynak veritabanları birden fazla yerde bulunabilir ve birbirlerinden tamamen farklı mimarilere sahip olabilirler, ancak hedef veritabanının her şeyin senkronize olması gerekir.
- Uzatılmış Kesinti Süresi: Planlanan geçişin beklenenden daha uzun sürdüğü durumlar vardır ve bu nedenle sistem için uzun bir arıza süresi vardır. Bu, son müşteri için iş kaybına neden olabilir ve kabul edilebilir olmayabilir.
- Potansiyel Veri kaybı: Test aşamasında tüm veri kayıpları tespit edilemez. Bazı veri kaybı örnekleri, sistem yeterli trafik aldığında sonunda tanımlanabilir.
Gerçek zamanlı bir veritabanından geçiş: Herhangi bir yüksek işlem web sitesi için, sürekli veri güncellemeleri yapıldığından, veritabanını taşımak her zaman zordur; ve canlı ve gerçek zamanlı verilerin taşınması mümkün değildir. Herhangi bir göçün gerçekleşmesi için bir kesinti süresi olmalıdır.
Son Açıklamalar
Veritabanı Taşıma konusunda her zaman üçüncü taraf uzmanlardan rehberlik isteyebilirsiniz. Biz Creole Studios'uz, Veritabanı geçişlerinde uzmanız ve bu tür herhangi bir çabaya yardımcı olmaktan veya danışmanlık yapmaktan memnuniyet duyarız. Teknoloji geçişi serisinin dördüncü ve son blogu için sıkı sıkıya bağlı kalın.