Re: Re: [pgsql-tr-genel] PostgreSQL Çok Kullanıcılı Veritabanı Tasarlama

Can hocamın ilk yöntemi bence daha makul. O kadar çok schema kullanmak
yönetilebilirlik yönünden sorun oluşturuyor. Biz de şuan ilk senaryoya
benzer bir mantıkla çalışıyoruz. Neticede part edebileceğiniz key
elinizde çok net, user_id. 9.5 ile gelen row based permission ile
otomatik olarak güvenliği sağlamış oluyorsunuz, user'a özel inherited
tablo ile de böl/parçala/yönet yapıyorsunuz ;)

On 04/22/2016 07:04 PM, N. Can KIRIK wrote:
> Merhaba,
>
> Çok iyi bir fikir olmayabilir ama "user_id" bazında PARTITION yaparak
> bir ana tablo altında her kullanıcıya ayrı tablo yapabilirsiniz. Tablo
> silme yapmanız gerekmeyeceği için de bir fonksiyon ile iş çözülebilir.
> Ana tablo üzerinden de rahat rahat toplu sorgulama yapabilirsiniz.
> CREATE TABLE "public"."tablo" ( ... ); CREATE TABLE
> "public"."tablo_123456" ( CHECK ( "kullanici_id" = 123456 ) ) INHERITS
> ( "public"."tablo" ); CREATE OR REPLACE FUNCTION
> "public"."tablo_insert_trigger_fn"() RETURNS TRIGGER AS ..... ; CREATE
> TRIGGER "public"."tablo_insert_trigger" BEFORE INSERT ON
> "public."tablo" FOR EACH ROW EXECUTE PROCEDURE
> "public"."tablo_insert_trigger_fn"(); ...
> http://www.postgresql.org/docs/9.5/static/ddl-partitioning.html
>
>
> Bir diğer alternatif de "user_id" bazında tablo yerine SCHEMA açarak,
> PARTITION tablolarını da bu şemalara asıl isimleri ile yerleştirmeniz
> olabilir. Bu durumda ana schema altında tüm tabloları kapsayan
> tablolar kullanarak hem yarı izole hem ortak kullanımlı bir yapınız
> olabilir.
> CREATE SCHEMA "kullanici_123456"; SET search_path TO
> "kullanici_123456"; CREATE TABLE "kullanici_123456"."tablo" ( )
> INHERITS ( "public"."tablo" ); ....
> http://www.postgresql.org/docs/9.5/static/ddl-schemas.html
>
>
> /N. Can KIRIK
> ePati Bilişim Teknolojileri
> http://www.epati.com.tr//
>
> 2016-04-22 17:56 GMT+03:00 Metin Guler <eng(dot)metin(at)gmail(dot)com
> <mailto:eng(dot)metin(at)gmail(dot)com>>:
>
> Merhabalar,
>
> Üzerinde çalıştığım bir web SPA projesi için PostgreSQL kullanmayı
> başladık. Çoklu kullanıcı desteği için ilk yaptığımız tek bir
> veritabanı oluşturup bir 'user_id' kolonu ile kullanıcıları
> ayırmak oldu. Yalnız kafama takılan bir kaç durum var.
>
> 1. Proje aktif kullanılmaya başlandiktan belirli bir süre sonra
> 2000 kullanıcı için 100 milyon satırı geçen tablolar olabilir. Bu
> kadar kullanıcının aynı tabloya erişimi performans konusunda
> tedirgin ediyor.
> 2. Kullanıcıların veritabanları mantıksal olarak birbirinden
> tamamen izole olduğu için aynı tabloda tutulmaları gibi bir
> gereklilik yok. Buda 1. maddeyi bizim için biraz daha rahatsız
> edici kılıyor.
> 3. Ayrı veritabanında tutmakta kullanıcıya verilen desteği daha
> kolay ve risksiz kılıyor.
>
> Bu durumda yapılabilecek çözümlerden biri uygulamayı tek
> kullanıcılı yapıp, her kullanıcı için docker gibi bir araçla
> buluta deploy etmek olurdu. Yalnız uygulama bize verilecek
> serverda tutulmak zorunda.
>
> PostgreSQL de çoklu veritabanı yapmak performanslı ve mantıklı
> görünmüyor. Hem database güncellemeleri ve bakımı sebebiyle, hemde
> nodejs server'ın sürekli farklı database değiştirirken yaşayacağı
> performans problemleri.
>
> Veritabanın küçük bir kısımını yaptığımız için database
> değiştirebiliriz. Belki CouchDB gibi doğal olarak database per
> user şeklinde çalışan bir döküman tabanlı bir sistemde
> kullanılabilir. Yalnız tutulacak veriler ilişkisel durumda, ağaç
> (b-tree) şeklinde tasarlamak ne kadar uygun bilemiyorum.
>
> Burada öncelikle merak ettiğim şu anki postressql senaryonusunun
> uygun olup olmadığı. Yazdıklarım içinde kaçırdığım veya bilmediğim
> bir nokta varsa, veya daha iyi bir öneriniz varsa çok memnun olurum.
>
> İyi çalışmalar,
> Metin Güler.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe ve unsubscribe komutlarýný
> majordomo(at)postgresql(dot)org <mailto:majordomo(at)postgresql(dot)org>
>
>

--

M.Atıf Ceylan