Archive for Şubat, 2020

PostgreSQL’de Ayrıcalık (Privilege)

Bir nesne oluşturulduğunda ona bir sahip atanır. Sahip, normalde oluşturma(create) sorgusunu yürüten roldür. Çoğu nesne türü için, ilk durum, yalnızca sahibin (veya bir süper kullanıcının) nesne ile her şeyi yapabilmesidir. Diğer rollerin onu kullanmasına izin vermek için, ayrıcalıkların(privilege lerin) verilmesi gerekir.

Farklı ayrıcalık türleri vardır; SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE ve USAGE. Belirli bir nesne için geçerli olan ayrıcalıklar, nesnenin türüne (tablo, işlev, vb.) bağlı olarak değişir.

Bir nesneyi değiştirme veya silme hakkı her zaman yalnızca sahibinin ayrıcalığına sahiptir. Nesne sahibinin özel ayrıcalıkları (DROP,GRANT,REVOKE vb.) her zaman sahibine aittir başkasına verilemez veya veya iptal edilemez. Ancak nesne için istenirse ALTER komutu ile sahibi değiştirilebilir, örneğin;

 ALTER TABLE table_name OWNER TO new_owner; 

Privilege leri atamak için GRANT komutu kullanılır. Örneğin, mustafa mevcut bir rolse ve hesaplar mevcut bir tablodaysa, tabloyu güncelleme yetkisi şunla verilebilir;

GRANT UPDATE ON hesaplar TO mustafa; 

ALL sözcüğünü kullanırsak bu nesne ile ilgili tüm ayrıcalıkları role verir.

GRANT ALL ON hesaplar TO mustafa; 

PUBLIC özel “rol” adı, sistemdeki her role bir ayrıcalık tanımak için kullanılabilir. Ayrıca, bir veritabanının birçok kullanıcısı olduğunda ayrıcalıkların yönetilmesine yardımcı olmak için “grup” rolleri ayarlanabilir. Aşağıdaki örnekle hesaplar tablosu için bütün rol lere SELECT yetkilesi verilmiştir.

GRANT SELECT ON hesaplar TO PUBLIC; 

Ayrıcalığı iptal etmek yani almak için aşağıdaki gibi REVOKE kelimesini kullanırız;

REVOKE SELECT ON hesaplar FROM PUBLIC; 

Normalde sadece nesnenin sahibi veya superuser nesne üzerinde ayrıcalıklar verebilir veya iptal edebilir. Ancak, istenirse bunu diğerlerine de verme hakkı veren “with grant option” bir ayrıcalık vermek mümkündür.

Mevcut ayrıcalıklar şunlardır:

  • SELECT : Nesnenin herhangi bir sütunundan veya belirli sütunlarından veri okumaya izin verir. COPY TO kullanımınada izin verir. SELECT yetkisi UPDATE ve DELETE içinde gereklidir.
  • INSERT : Yeni bir satırın bir nesneye eklenmesine izin verir. COPY FROM kullanımınada izin verir.
  • UPDATE : Bu yetki ile verilerin güncellemesi yetkisi kazanmış oluruz.
  • DELETE : Verilerin silinmesine izin verir.
  • TRUNCATE : Nesne üzerinde truncate’e izin verir. Yani nesneyi boşaltmaya izinli oluruz.
  • REFERENCES : Bir tabloya veya bir tablonun belirli sütunlarına referans foreign key constraint oluşturulmasına izin verir.
  • TRIGGER : Tablo veya view üzerinde trigger oluşturmaya izin verir.
  • CREATE : Veritabanları için, veritabanı içerisinde yeni schema oluşturulmasına izin verir. Schemalar için, schema içinde yeni nesnelerin oluşturulmasına izin verir. Tablespace için tablolar, indeksler ve geçici dosyaların tablespace içinde oluşturulmasına izin verir
  • CONNECT : Yetki alan kişinin veritabanına bağlanmasına izin verir. Bu ayrıcalık bağlantı başlangıcında kontrol edilir (pg_hba.conf tarafından getirilen kısıtlamaların kontrol edilmesine ek olarak).
  • TEMPORARY : Veritabanı kullanılırken geçici tabloların oluşturulmasına izin verir.
  • EXECUTE : Fonksiyonda kullanılan herhangi bir operatörün kullanımı dahil olmak üzere fonksiyon veya prosedürü çalıştırmaya izin verir.
  • USAGE : Şemalar için, şemada bulunan nesnelere erişime izin verir. Prosedürel diller için, o dilde işlevlerin oluşturulması için dilin kullanılmasına izin verir. Foreign-data wrapper kullanılarak yeni sunucuların oluşturulmasına izin verir. Sequence için currval ve nextval işlevlerinin kullanımına izin verir.

(continue reading…)

 102 total views,  2 views today


Postgresql’de Schema Kavramı

Bir önceki yazımda PostgreSQL’de schema kavramından ve obje hiyerarşi’sinden bahsetmiştim. Bu yazımızda schema kavramını detaylandıracağız. Önceki yazıdada bahsettiğim gibi PostgreSQL veritabanı cluster, bir veya daha fazla veritabanı içerebilir. Roller ve diğer birkaç nesne türü, tüm cluster genelinde paylaşılır yani global nesnelerdir. Sunucuya ise client bağlantısı, yalnızca bağlantı isteğinde, belirtilen tek bir veritabanındaki verilere erişebilir.

Veritabanı ise tabloları ve objeleri içeren bir veya daha fazla schema’ya sahip olabilir, yani her schema yalnızca bir veri tabanına ait olabilirken  bir veri tabanında birden çok schema yaratılabilir. Farklı isimdeki iki schema, aynı isimde objeler içerebilir. Aslında burada schema kavramı veritabanı objeleri için namespace anlamına gelmektedir. Veri tabanı objesine erişmek istendiği zaman schema_name.object_name isimlendirmesi kullanılır. Veritabanlarından farklı olarak, schemalar katı bir şekilde ayrılmaz: bir kullanıcı, yetkileri varsa, bağlı oldukları veritabanındaki schemaların herhangi birindeki objelere erişebilir.  Schemaları kullanmak istemenin birkaç nedeni vardır;

  • Birçok kullanıcının birbirine müdahale etmeden, veritabanını kullanmasına izin vermek için.
  • Veritabanı objelerini daha yönetilebilir hale getirmek için mantıksal gruplar halinde düzenlemek.
  • Üçüncü taraf uygulamalar, diğer objelerin adlarıyla çakışmaması için ayrı schemalara yerleştirilebilir.
  • Schemalar, işletim sistemi düzeyindeki dizinlere benzer, ancak schemalar iç içe olamaz.

(continue reading…)

 110 total views,  2 views today


PostgreSQL’de Rol, Kullanıcı ve Grup Kavramı


Postgresql’de role, group role, user, schema gibi kavramları daha kolay anlayabilmek adına önce Postresql’de nesne hiyerarşisini bir resim ile kısaca göstermek istedim.

Postgresql-ROLE-USER-SCHEMA

Resimden de anlaşılacağı gibi; initdb yaptımız noktadan itibaren veritabanı clusterımız oluşur,  veritabanı cluster’ın altında ise roller, veritabanları ve tablespaceler vardır. Veritabanı le tablo,index, sequence vb objelerin arasında ise schema diye bir katman vardır.

İlk dikkat etmemiz gereken nokta roller ve tablespacelerin veritabanı ile aynı seviyede olması, yani hemen veritabanı cluster’ın altında olması. Bunun nedeni bir kullanıcı ve tablespace oluşturduğumuzda bu nesnelerin veritabanına ait olmaması yada bir diğer deyişle bu nesneleri globel nesne olması. Buradan şunuda anlayabiliriz roller ve tablespaceleri birden fazla veritabanında kullanabileceğimiz.

İkinci dikkat etmemiz gerekn nokta ise schema kavramı bu kavramı başka bir yazıda detaylıca anlatacağım ama kavram karmaşası olmaması adına kısaca değinmek istiyorum. Öncelikle bir veritabanında bir veya daha fazla schema olabilir, hatta aynı nesne ismi aynı veritabanında farklı schemalarda kullanılabilir. Veritabanlarından farklı olarak schemalar katı bir şekilde ayrılmaz: bir kullanıcı, yetkileri varsa, bağlı oldukları veritabanındaki schemaların herhangi birindeki nesnelere erişebilir. Schemaları  kullanmak istemenin birkaç nedeni vardır:

  • Birçok kullanıcının birbirine müdahale etmeden bir veritabanını kullanmasına izin vermek için.
  • Veritabanı nesnelerini daha yönetilebilir hale getirmek için mantıksal gruplar halinde düzenlemek.
  • Üçüncü taraf uygulamalar, diğer nesnelerin adlarıyla çakışmaması için ayrı schemalara yerleştirilebilir.
  • Schemalar, işletim sistemi düzeyindeki dizinlere benzer, ancak schemalar iç içe olamaz.

PostgreSQL’de ROL Kavramı

Gelelim bugünkü asıl konumuz olan rol kavramına; PostgreSQL, roller kavramını kullanarak veritabanı erişim izinlerini yönetir. Bir rol, rolün nasıl ayarlandığına bağlı olarak bir veritabanı kullanıcısı veya bir veritabanı kullanıcısı grubu olarak düşünülebilir.  Bu koyu yazdığım yer işin can alıcı noktası, Postgresql’de user diye bir kavram yoktur user dediğimiz nesne, rolün LOGIN yetkili halidir. Bu dediğimin anlaşılabilmesi adına 3 farklı nesne oluşturacağım ve daha sonra \du  komutu veya pg_user/pg_roles sistem viewleri ile bu nesnelere bakacağız;

NOT : Rol kavramı, “user” ve ” groups ” kavramlarını kapsar. 8.1’den önceki PostgreSQL sürümlerinde, user ve groups farklı türde varlıklardı, ancak şimdi yalnızca roller var. Herhangi bir rol bir kullanıcı, bir grup veya her ikisi olarak hareket edebilir. (continue reading…)

 118 total views


PostgreSQL Mimarisi

Proses Mimarisi

Postgresql, multi-process mimarisine sahip istemci-sunucu tipli ilişkisel veritabanı yönetim sistemidir ve tek bir sunucuda çalışır. İstemci, PostgreSQL sunucusuna bir istek gönderir ve PostgreSQL sunucusu istemci isteğine bir yanıt verir. İstemci ve sunucu genelde farklı sunucularda çalışırken aralarındaki bağlantı TCP/IP ağ bağlantısı üzerinden olur. PostgreSQL sunucusu, istemciden gelen birden çok sessionları eşzamanlı  yönetir, bunu her session için bir proses başlatarak sağlar.

Sunucu prosesi olan postgres prosesi veritabanı dosyalarını yönetir, istemci uygulamalarından gelen bağlantıları kabul eder ve istemci adına eylemler gerçekleştirir. Ana sunucu prosesi olan postgres prosesinin, her yeni bağlantı için yeni bir proses açtığını zaten yukarıda söylemiştik. Bu nedenle istemci ve sunucu prosesleri, ana sunucu prosesinin müdahalesi olmadan birbirleriyle iletişim kurar.  PostgreSQL sunucusu aşağıdaki gibi kabaca dört alt sisteme bölünebilir:

  • Process manager
  • Query processor
  • Utilities
  • Storage manager

Process manager

PostgreSQL’i başlattığımızda başlatılan ilk proses /usr/pgsql-12/bin/postgres daemon prosesidir. Bu prosesin recovery, shared data structures/memory  alanlarını başlatmak, zorunlu ve isteğe bağlı prosesleri başlatmak gibi pek çok sorumluluğu vardır. Bu prosesler aynı zamanda utility prosesler olarak da adlandırılır ve bgwriter, checkpointer, autovacuum launcher, log writer, stats collector prosesleri gibi prosesleri içerir. Ayrıca, daemon prosesi bağlantı isteklerini dinler, istemcilerden bağlantı istekleri alır ve istemci için sunucuda backend prosesi oluşturur. (continue reading…)

 180 total views


PostgreSQL’in Mantıksal ve Fiziksel Yapısı


Detaylara girmeden önce kavramları netleştirmemiz gerektiğini düşünüyorum çünkü kavramlar farklı veritabanları için değişebiliyor hatta aynı veritabanı için aynı kavram veritabanı yöneticisi ve yazılımcı için bile farklı anlamlara gelebiliyor. Bu nedenle Postgresql’deki kavramları kısaca anlatmak istiyorum.

PostgreSQL’de her tablo, sütun koleksiyonunun isimlendirlmiş halidir. Tablolar, veritabanları halinde gruplandırılır yani veritabanları tablo koleksiyonlarıdır ve tek bir PostgreSQL instance(verilere erişimi idare eden) tarafından yönetilen veritabanı koleksiyonuna, veritabanı cluster denir. Bu kısmı önemsediğim için elimden geldiğince kısa ve öz yazmaya çalıştım ve bu parağrafdan anlaşılmasını istedikleirm PostgreSQL’de tablo, veritabanı, veritabanı cluster ve instance kavramları.

Bir sunucuda birden fazla cluster çalışabilir ama her cluster kendi data dizininde çalışması gerekir yani başka bir deyişle bir data dizininde sadece bir tane cluster çalışabilir. Bu arada bir sunucuda birden fazla cluster çalışıyorsa her cluster için farklı port kullanılması gerekir eğer aynı port kullanılsın isteniyorsa o zaman da sunucuda birden fazla ip olması lazım.

NOT : Yukarıdaki özellikle instance ve cluster kavramlarını Oracle veritabanlarındaki anlamlarıyla karıştırmamak gerekir.

Cluster’ın Mantıksal Yapısı

Cluster, PostgreSQL sunucusu tarafından yönetilen veritabanı koleksiyonudur. PostgreSQL’deki “veritabanı cluster” terimi, “bir grup veritabanı sunucusu” anlamına gelmez. Bir PostgreSQL sunucusu, tek bir ana bilgisayarda çalışır ve tek bir veritabanı clusterını yönetir. Veritabanı, veritabanı nesnelerinin bir koleksiyonudur. İlişkisel veritabanı teorisinde, veritabanı nesnesi verileri depolamak veya referans vermek için kullanılan veri yapısıdır. PostgreSQL’de veritabanları aynı zamanda veritabanı nesneleridir ve mantıksal olarak birbirlerinden ayrılırlar. Diğer tüm veritabanı nesneleri (örn. Tablolar, dizinler, vb.) İlgili veritabanlarına aittir. Aslında aşağıdaki resim herşeyi özetliyor.

PostgreSQL Cluster

PostgreSQL’deki tüm veritabanı nesneleri, 4 baytlık integer olan unique bir OID (object id) değeri bulunur. Veritabanı nesneleri ve ilgili OID’ler arasındaki ilişkiler, nesnelerin türüne bağlı olarak uygun sistem kataloglarında saklanır. Örneğin, veritabanlarının OID’leri ve heap tabloları sırasıyla pg_database ve pg_class’da saklanır, böylece aşağıdaki gibi sorgular çalıştırarak bilmek istediğiniz OID’leri bulabilirsiniz: (continue reading…)

 1,042 total views


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress