NoSQL ve SQL veritabanları hakkındaki tartışmalarda bazen şirketlerin şemasız NoSQL veritabanlarını kullanmayı tercih ettiklerini duyuyorum çünkü şemayı yeni bir sürüme geçirmek sorunlu. Ama bu yükseltme yaparken gerçekten büyük bir sorun mu? İlişkisel veritabanları bu tür işlemler için kötü mü?
Bu blog gönderisini MongoDB blogunda okudum : Neden Schemaless?
Yanıtlar:
NoSql veritabanınızın geleneksel anlamda bir şemaya sahip olmaması, değiştikçe uğraşmanız gereken mantıksal bir şema olmadığı anlamına gelmez. MongoDb kullanan tipik bir uygulama durumunda, büyük olasılıkla kodunuz json nesnesinin belirli alanlarının belirli şekillerde davranmasını bekler. Davranışı değiştirirseniz, veritabanında zaten var olan verileri güncellemek isteyebilirsiniz. Şimdi, geleneksel RDBMS ile bu büyük ölçüde çözülmüş bir sorundu - sadece altta yatan tabloları değiştirmek zorunda kaldı. Ancak bu yeni oluşturulmuş NoSQL veritabanlarıyla bir kararınız var - tüm nesnelerinizi karıştırmak ve güncellemek için bir komut dosyası yazar mısınız? Yoksa anında sürümler arasında dönüştürmek için kod ekliyor musunuz? Öyleyse, v1 nesnelerini ne kadar süreyle destekliyorsunuz? Sonsuza dek? V3'e kadar?
Ben MongoDb blog yazı kullanılan örnek biraz basit ve RDBMS ne olursa olsun iyi bir güncelleme işlemi varsa işlemek için çok kolay bir durum olduğunu ekleyeceğiz; bir alan eklemek nadiren acıyor. Eğer ayrılmaya karar vermesi zaman olduğu Nameiçine alan FirstNameve LastNameo heyecanlı şeylerin olsun.
Ama bu yükseltme yaparken gerçekten büyük bir sorun mu?
Olabilir.
Bazı kuruluşlar - iyi dağınıktır ve şema göçü konusunda çok kötü bir iş çıkarırlar.
"Göç Haftasonu". Sunucuları durdurun. Tüm verileri yedekleyin ve dışa aktarın. Yeni şemayı oluşturun (genellikle varolan şemayı değiştirerek). Verileri yeniden yükleyin veya yerinde yeniden yapılandırmayı deneyin.
"Sürekli Düzenleme". Tabloları SQL'in izin verdiği ölçüde değiştirin. ALTER dizisi izlenmeden gerçekleştirildi. Önceki şema sürümüne geri dönmenin yolu yok. Gerektiğinde, mevcut tablolardan yeni tablolar oluşturun ve umarım tüm uygulamaları yeni tabloları kullanacak şekilde ayarlayın. Ama - iyi KG eksik - "her durumda" yerinde eski tabloları bırakarak.
"Tam Panik". Şema değişikliklerini önleyin. Büyük bir pislik yap. Riskin çok yüksek olduğunu iddia edin. Bu yöndeki tüm çabaları engelleyin. Daha mantıklı bir yaklaşım benimsemeye kadar şemayı rehin alın.
İlişkisel veritabanları bu tür işlemler için kötü mü?
Herhangi bir şema göç etmek için bir acıdır.
En büyük sorun teknik değil.
Anlamsaldır.
Şema değişikliğinin temel nedenlerinden biri, önceki şemanın sorun etki alanıyla çok iyi eşleşmemesidir. Anlambilim değiştiği için, veritabanının (ve uygulamaların) değişmesi gerekir. Bazen bunlar, uygulamaların verilerle çalışma şeklini yeniden düşünmeyi gerektiren derin değişikliklerdir.
Veritabanının anlambilimini gözden geçirmek çok zor olabilir.
İnsanların şema değişiklikleri yerine yaptıkları, fiziksel şemayı kötüye kullanmaktır. Mevcut alanlara yanlış veri yüklemeye başlarlar çünkü yapabilirler. Bir "yorum" alanı aniden önemli bir müşteri yönetimi bilgisi ve ardından "//" ve ardından gerçek yorum ile başlar. Bu "parça 1 - alan 2 // yorum" veri parçaları için büyümek. "Gerçek" uygulama yazılımı, BT'nin değiştirmeyi reddettiğini değiştirmek zor bir şemaya sahip olduğundan, kullanıcılar bu ek verileri yorum alanından ayıklayan bir e-tabloya sahiptir.
Üretim veritabanlarını sorunsuz bir şekilde tablolar ve (nulllable) sütunlar ekleyerek güncelliyoruz. Uygulamanın önceki sürümleri yükseltilmiş veritabanı ile iyi çalışır, sadece yeni şeylere başvurmazlar. Tabloları veya sütunları kaldırmaktan veya mevcut verilerin saklanma biçimini değiştirmekten kaçınırız, ancak bu gerektiğinde uygun dönüşüm komut dosyaları üretiriz. Veritabanınızda belirtilen türde bir güvenli şema olsun ya da olmasın, veri yapısındaki değişiklikler yeni yapı ile etkileşim için veri dönüştürme ve uygulama yükseltmeleri gerektirir.
Değişir.
İlk olarak, birden fazla makineye yayılan gerçekten büyük bir veritabanınız varsa, her şey (sadece veritabanı güncellemesi değil) acı olacaktır. (önceden ne kadar planlamış olursanız olun).
İkincisi, bir veritabanını güncellemek sadece bir veritabanı işi değildir - aynı zamanda DB'nin parçası olduğu daha büyük sisteme de bağlıdır. Bu ayrıca veritabanı dağıtımını da içerir (birçok veritabanı sunucusu, birden çok veri merkezi, master-slave kurulumu vb.)
Ağ, sistem bileşenlerini DB şema değişikliği olayının bir çeşit 'bilişine' sahip olacak şekilde yapılandırarak hafifletebilir. Bu, tüm sistemin şema değişikliklerine toleranslı olması ve ona 'akılcı' bir şekilde yanıt verebileceği anlamına gelir.
MySQL şema güncellemelerini ele almak için Facebook tarafından geliştirilen bir yardımcı programa göz atabilirsiniz .
Ayrıca, sizi salt okunur şekilde ustalaştırmak, kölelerde veya geliştirme kopyasında değişiklik yapmak gibi standart en iyi uygulamalar vardır.
Her durumda, tam bir yedekleme ve kapsamlı test paketi olması bir zorunluluktur. Ancak o zaman, değişiklikleri güvenli ve güvenli bir şekilde yapabilirsiniz.