Sharding, parçalama işlemine göre sistemin verileri farklı kaynaklarda tutmasına yardımcı olan çok önemli bir kavramdır.
“Shard”kelimesi” bir bütünün küçük bir parçası anlamına gelir. Dolayısıyla Sharding, daha büyük bir parçayı daha küçük parçalara bölmek anlamına gelir.
DBMS’de, Sharding, büyük bir veri tabanın bölündüğü veya daha küçük verilere bölündüğü, ayrıca parça olarak da bilinen bir Veri Tabanı bölümleme türüdür. Bu parçalar yalnızca daha küçük değil, aynı zamanda daha hızlı ve dolayısıyla kolayca yönetilebilir.
Sharding Gereksinimi
Sharding yapılmamış çok büyük bir veritabanı düşünün. Örneğin, tüm kolejdeki tüm öğrenci kayıtlarının (şimdiki ve geçmiş) tek bir veritabanında tutulduğu bir kolejin veritabanını alalım. Bu nedenle, çok çok sayıda veri, diyelim ki 100.000 kayıt içerecektir.
Şimdi bu veritabanından bir öğrenci bulmamız gerektiğinde, öğrenciyi bulmak için her seferinde 100.000 civarında işlem yapılması gerekiyor ki bu çok çok maliyetli.
Şimdi aynı üniversite öğrencilerinin yıllara göre daha küçük veri parçalarına ayrılmış kayıtlarını düşünün. Artık her veri parçasında yalnızca yaklaşık 1000-5000 öğrenci kaydı olacaktır. Böylece sadece veritabanı çok daha yönetilebilir hale gelmekle kalmadı, aynı zamanda her seferinde işlem maliyeti de Sharding ile elde edilen büyük bir faktör tarafından azaltıldı.
Bu nedenle Sharding’e ihtiyaç duyulur.
Sharding’in Özellikleri:
Sharding, veritabanını küçültürSharding, veritabanını daha hızlı hale getirirSharding, veritabanını çok daha kolay yönetilebilir hale getirirSharding, bazen karmaşık bir işlem olabilirSharding, veritabanının işlem maliyetini azaltır
Sharding’in Faydaları
Bir veritabanını Shardingin ana cazibesi, yatay ölçeklendirmeyi kolaylaştırmaya yardımcı olabilmesidir, buna ölçeklendirme de denir. Yatay ölçeklendirme, yükü dağıtmak ve daha fazla trafiğe ve daha hızlı işlemeye izin vermek için mevcut bir yığına daha fazla makine ekleme uygulamasıdır. Bu genellikle, genellikle daha fazla RAM veya CPU ekleyerek mevcut bir sunucunun donanımını yükseltmeyi içeren, ölçeklendirme olarak da bilinen dikey ölçeklendirme ile karşılaştırılır.
Tek bir makinede çalışan bir ilişkisel veritabanına sahip olmak ve bilgi işlem kaynaklarını yükselterek gerektiği gibi ölçeklendirmek nispeten basittir. Nihayetinde, dağıtılmamış herhangi bir veritabanı, depolama ve hesaplama gücü açısından sınırlı olacaktır, bu nedenle yatay olarak ölçekleme özgürlüğüne sahip olmak kurulumunuzu çok daha esnek hale getirir.
Bazılarının parçalanmış bir veritabanı mimarisi seçmesinin bir başka nedeni de sorgu yanıt sürelerini hızlandırmaktır. Parçalanmamış bir veritabanında sorgu gönderdiğinizde, aradığınız sonuç kümesini bulabilmesi için sorguladığınız tablodaki her satırı araması gerekebilir. Büyük, yekpare bir veritabanına sahip bir uygulama için sorgular aşırı derecede yavaşlayabilir. Ancak bir tabloyu birden çok tabloya bölerek, sorguların daha az satırı aşması gerekir ve sonuç kümeleri çok daha hızlı döndürülür.
Sharding, kesintilerin etkisini azaltarak bir uygulamayı daha güvenilir hale getirmeye de yardımcı olabilir. Uygulamanız veya web siteniz paylaşılmamış bir veritabanına dayanıyorsa, bir kesinti tüm uygulamayı kullanılamaz hale getirme potansiyeline sahiptir. Bununla birlikte, parçalanmış bir veritabanıyla, bir kesintinin yalnızca tek bir parçayı etkilemesi olasıdır. Bu, uygulamanın veya web sitesinin bazı bölümlerinin bazı kullanıcılar tarafından kullanılamamasına neden olsa da, genel etki, tüm veritabanının çökmesinden daha az olacaktır.
Sharding’in Dezavantajları
Bir veritabanını parçalamak, ölçeklendirmeyi kolaylaştırabilir ve performansı iyileştirebilirken, belirli sınırlamalar da getirebilir. Burada, bunlardan bazılarını ve neden tamamen parçalamayı önlemek için nedenler olabileceğini tartışacağız.
İnsanların parçalama ile karşılaştığı ilk zorluk, parçalanmış bir veritabanı mimarisini düzgün bir şekilde uygulamanın katıksız karmaşıklığıdır. Yanlış yapılırsa, parçalama işleminin veri kaybına veya tabloların bozulmasına yol açması gibi önemli bir risk vardır. Doğru yapıldığında bile, parçalamanın ekibinizin iş akışları üzerinde büyük bir etkisi olması muhtemeldir. Bir kişinin verilerine tek bir giriş noktasından erişmek ve bunları yönetmek yerine, kullanıcıların, bazı ekipler için potansiyel olarak kesintiye yol açabilecek birden çok parça konumunda verileri yönetmesi gerekir.
Kullanıcıların bir veritabanını parçaladıktan sonra bazen karşılaştıkları bir sorun, parçaların sonunda dengesiz hale gelmesidir. Örnek olarak, iki ayrı parçaya sahip bir veritabanınız olduğunu varsayalım, biri soyadı A ile M arası harflerle başlayan müşteriler için, diğeri ise isimleri N ile Z arasındaki harflerle başlayanlar için. Ancak, uygulamanız aşırı miktarda hizmet veriyor. Soyadı G harfi ile başlayan kişilerin oranı. Buna göre, AM parçası kademeli olarak NZ’den daha fazla veri toplayarak, kullanıcılarınızın önemli bir kısmı için uygulamanın yavaşlamasına ve durmasına neden olur. AM parçası, bir veritabanı etkin noktası olarak bilinen hale geldi. Bu durumda, veritabanını parçalamanın tüm faydaları, yavaşlamalar ve çökmeler tarafından iptal edilir. Daha eşit bir veri dağıtımına izin vermek için veritabanının büyük olasılıkla onarılması ve yeniden paylaşılması gerekir.
Diğer bir önemli dezavantaj ise, bir veri tabanı parçalandıktan sonra, onu parçalanmamış mimarisine döndürmenin çok zor olabilmesidir. Veritabanının parçalanmadan önce yapılan yedekleri, bölümlemeden sonra yazılan verileri içermez. Sonuç olarak, orijinal paylaşılmamış mimarinin yeniden oluşturulması, yeni bölümlenmiş verilerin eski yedeklerle birleştirilmesini veya alternatif olarak, bölümlenmiş DB’yi tekrar tek bir DB’ye dönüştürmeyi gerektirir; bunların her ikisi de maliyetli ve zaman alıcı çabalar olacaktır.
Dikkate alınması gereken son bir dezavantaj, parçalamanın her veritabanı motoru tarafından yerel olarak desteklenmemesidir. Örneğin, PostgreSQL veritabanını manuel olarak parçalamak mümkün olsa da, PostgreSQL otomatik parçalamayı bir özellik olarak içermez. Otomatik parçalamayı içeren bir dizi Postgres çatalı vardır, ancak bunlar genellikle en son PostgreSQL sürümünün gerisinde kalır ve diğer bazı özelliklerden yoksundur. MySQL Cluster veya MongoDB Atlas gibi belirli bir hizmet olarak veritabanı ürünleri gibi bazı özel veritabanı teknolojileri, bir özellik olarak otomatik parçalamayı içerir, ancak bu veritabanı yönetim sistemlerinin vanilya sürümleri içermez. Bu nedenle, parçalama genellikle “kendi yuvarlanma” yaklaşımını gerektirir. Bu, parçalama belgelerinin veya sorun giderme sorunlarına ilişkin ipuçlarının bulunmasının genellikle zor olduğu anlamına gelir.
Bunlar, elbette, parçalamadan önce dikkate alınması gereken bazı genel konulardır. Kullanım durumuna bağlı olarak bir veritabanını parçalamanın daha birçok olası dezavantajı olabilir.