From: | burhan ozy <boetsid(at)gmail(dot)com> |
---|---|
To: | Ali Mumcu <alimumcu1077(at)gmail(dot)com> |
Cc: | pgsql-tr-genel(at)postgresql(dot)org |
Subject: | Re: Postgresql 11 - Büyük Boyutlu Tablo Ölçeklendirme |
Date: | 2019-03-14 13:06:07 |
Message-ID: | CAM=v7=eKBtDhFvr-Lk7Rk=9qu+uFzmKTe71AqPmrAPB1byj4+w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-tr-genel |
Merhaba,
pdf, resim gibi ham veriyi dosya sistemi üzerinde tutmanızı tavsiye ederim.
Veritabanında ise unique id ve path bilgileri tutulabilir. Eğer amacınız
Full Text Search(FTS) özelliğinden yararlanmak ise Solr veya Elasticsearch
ile dışardan çözmeniz veritabanı performansını etkilemeyeceği için daha
ölçeklenebilir olacaktır.
İyi günler.
Burhan Özerdem
www.apkbilisim.com
On Thu, Mar 14, 2019 at 3:46 PM Ali Mumcu <alimumcu1077(at)gmail(dot)com> wrote:
> Merhabalar Arkadaşlar,
>
> Yıllık Yaklaşık 5 Tb büyümesi öngörülen bir tablomuz var(pdf resim vs
> tututalacak) , bunu henüz planlama aşamasındayız tabloyu
> ölçeklendirmemiz gerekip , gerekmediği konusunda ve yönteminde
> kararsız kaldık,.
> Sizce bu tabloyu local de parititioning mi yapmam daha mantıklı yoksa
> Foreign tablo olarak farklı sunuculara partitition yapmam mı daha
> mantıklı ve efektif olur sizce,?
>
>
> Parititioned Tabloya başka bir tablodan referens gösterilmesine izin
> verilmiyor , bölümlendirme yapacağımız tabloya başka tablolardan
> referans yapılıyorsa bu durumu nasıl çözebiliriz?
> Ayrıca Foreign Parititioned table'da ise zaten primary keye bile izin
> vermiyor.
>
>
>
> (citus denedik fakat çok fazla limitasyona(recursive query vs )
> takıldığımız için vazgeçtik.)
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Metin Güler | 2019-03-14 14:50:24 | Re: Postgresql 11 - Büyük Boyutlu Tablo Ölçeklendirme |
Previous Message | Fırat Güleç | 2019-03-14 13:01:53 | RE: Postgresql 11 - Büyük Boyutlu Tablo Ölçeklendirme |