Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
PostgreSQL için Azure Veritabanı hizmetindeki elastik kümeler, PostgreSQL'in yatay parçalanması için postgreSQL'e açık kaynak Citus uzantısının yönetilen bir teklifidir.
Citus yalnızca bir uzantı olsa da, birden çok PostgreSQL örneğini bağlar. Citus ile PostgreSQL için Azure Veri Tabanı esnek bir sunucu dağıttığınızda, birden çok PostgreSQL örneğinin yönetimini ve yapılandırmasını tek bir kaynak olarak işler. Ayrıca düğümleri otomatik olarak kurar ve bunları Citus uzantısına tanıtır.
Hizmet üzerindeki elastik kümeler iki parçalama modeli sunar: satır tabanlı parçalama ve şema tabanlı parçalama. Daha fazla bilgi edinmek için parçalama modelleri hakkındaki açık kaynak belgelerine bakın.
Architecture
Elastik küme, PostgreSQL için Azure Veri Tabanı esnek sunuculardan oluşan bir veya daha fazla düğümden oluşur. Bu örnekler otomatik olarak birbirini bulur ve bir Citus kümesi oluşturmak için birbirine bağlanır. Düğümler aynı işlem ve depolama katmanında olmalıdır ve bunları eşit şekilde daha yüksek veya daha düşük katmanlara ölçeklendirebilirsiniz.
Elastik kümeler, "paylaşılan hiçbir şey" mimarisinde birbirleriyle eşgüdüm sağlamak için esnek sunucuların (düğümler olarak adlandırılır) örneklerini kullanır. Mimari ayrıca kümeye daha fazla düğüm ekleyerek veritabanının ölçeklendirilmesini sağlar.
Elastik kümeler , paylaşılan hiçbir şey mimarisinde birbirleriyle eşgüdüm sağlamak için esnek sunucuları (düğümler olarak adlandırılır) kullanır. Mimari ayrıca kümeye daha fazla düğüm ekleyerek veritabanının ölçeklendirilmesini sağlar.
PostgreSQL için Cosmos DB'nin aksine düğüm adresleri dışarıdan kullanıma sunulmaz. gibi pg_dist_nodeCitus meta veri tablolarına bakarsanız, örnektekiyle 10.7.0.254 aynı IP adresine ancak farklı bağlantı noktası numaralarına sahip tüm düğümleri fark edebilirsiniz.
select nodeid, nodename, nodeport from pg_dist_node;
nodeid | nodename | nodeport
--------+------------+----------
1 | 10.7.0.254 | 7000
2 | 10.7.0.254 | 7001
(2 rows)
Azure'ın altyapısında, bu düğümler aynı makinede farklı bağlantı noktaları gibi görünse de farklı sanal makinelerde yaşar.
Citus hakkında daha fazla bilgi edinmek için resmi açık kaynak proje belgelerine bakın.
Varsayılan olarak, Citus ile oluşturulan tablolar ve şemalar küme arasında otomatik olarak dağıtılamaz. Bir parçalama modeline karar vermeniz ve şemaları dağıtmaya veya tablo verilerinizi satır tabanlı parçalama ile dağıtmaya karar vermeniz gerekir.
Dağıtılmış tablolardaki her sorgu için sorgulanan düğüm onu tek bir düğüme yönlendirir veya birkaç düğüm arasında paralelleştirir. Karar, gerekli verilerin tek bir düğümde mi yoksa birden çok düğümde mi yer aldığına bağlıdır. Şema tabanlı parçalama ile koordinatör sorguları doğrudan şemayı barındıran düğüme yönlendirir. Hem şema tabanlı parçalama hem de satır tabanlı parçalamada düğüm, meta veri tablolarına danışarak ne yapacağına karar verir. Bu tablolar düğümlerin konumunu ve sistem durumunu ve düğümler arasında veri dağılımını izler.
Veriler parçalama modellerinden biri kullanılarak dağıtıldıktan sonra, DML (Veri Değiştirme Dili) işlemlerini (SELECT, UPDATE, INSERT, DELETE) gerçekleştirmek için düğümlerden herhangi birine bağlanabilirsiniz. Tüm düğümler, sorgu için gereken verileri bulmak için gereken meta verileri içerir ve sorguyu yanıtlamak için bu verileri alabilir.
DDL (Veri Tanım Dili) işlemleri ve küme genelindeki işlemler şu anda koordinatör rolünü barındıran düğümle sınırlıdır. 7432 numaralı bağlantı noktasını kullanmak yerine 5432 numaralı bağlantı noktasına bağlanarak DDL ve küme genelinde işlemler gerçekleştirdiğinizden emin olun.
Yeni düğümler ekleyerek ve üzerindeki verileri yeniden dengeleme yoluyla elastik kümenin ölçeğini genişletebilirsiniz. Yeniden dengeleme çevrimiçi bir işlemdir ve çalışan iş yüklerini engellemez.
Parçalar
Önceki bölümde dağıtılmış tabloların çalışan düğümlerinde parça olarak nasıl depolandığı açıklanmıştır. Bu bölümde, bu parçalar hakkında daha fazla teknik ayrıntı ele alınmaktadır.
Meta pg_dist_shard veri tablosu, sistemdeki her dağıtılmış tablonun her parçası için bir satır içerir. Satır, bir parça tanımlayıcısını (shardid) bir karma uzayındaki (shardminvalue, shardmaxvalue) tamsayı aralığıyla eşleştirir.
SELECT * from pg_dist_shard;
logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
github_events | 102026 | t | 268435456 | 402653183
github_events | 102027 | t | 402653184 | 536870911
github_events | 102028 | t | 536870912 | 671088639
github_events | 102029 | t | 671088640 | 805306367
(4 rows)
Düğüm, github_events öğesinin bir satırını hangi shard’ın barındırdığını belirlemek istiyorsa, satırdaki dağıtım sütununun değerini hash’ler. Ardından düğüm, hangi parça aralığının karma değeri içerdiğini denetler. Karma işlevinin görüntüsü, aralıkların ayrık birleşimi olacak şekilde tanımlanır.
Parça yerleşimleri
Varsayalım ki parça 102027, söz konusu satırla ilişkilidir. Satır, çalışanlardan birindeki github_events_102027 adlı tabloda okunur veya yazılır. Uzantı, meta veri tablolarında depolanan bilgileri kullanarak hangi çalışanın kullanılacağını belirler. Parçanın çalışana atanması, parça yerleşimi olarak bilinir.
Düğüm, sorguları github_events_102027 gibi belirli tablolara atıfta bulunan parçalara yeniden yazar ve bu parçaları uygun çalışanlar üzerinde çalıştırır. Aşağıda, 102027 tanımlayıcılı shard’ı barındıran düğümü bulmak için arka planda yürütülen bir sorgu örneği verilmiştir.
SELECT
shardid,
node.nodename,
node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
ON placement.groupid = node.groupid
AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;
┌─────────┬───────────┬──────────┐
│ shardid │ nodename │ nodeport │
├─────────┼───────────┼──────────┤
│ 102027 │ localhost │ 5433 │
└─────────┴───────────┴──────────┘