none
Büyük verilerde ID kolonu RRS feed

  • Soru

  • Merhaba,

    Yaklaşık 10 milyon kayıtlı bir tablom ve bu tabloda ID (bigint - primary key) isimli bir kolonum var. var ve burada sürekli ortalama tek seferde 200.000 kayıt siliniyor sonra 200.000 kayıt yeniden ekleniyor. Bu durumda benim ID kolonum sürekli değişmekte. ID kolonunun türü bigint olsa da sonuçta bu şekilde sil ekle işlemi yapıldıkça bir yerde bigint de maksimum değerine ulaşacak.. Bunun için aklıma ID kolonunu sayısal değil de varchar tanımlayıp bu kolona da yazılım tarafından Guid değeri kaydedeyim..

    1 - Bu doğru bir mantık mı yoksa bigint dursun mu dersiniz?

    2 - Guid değerinin bir makinada her seferinde farklı değer vereceği söyleniyor. Bu ne kadar doğrudur?

    3 - Bir sunucuda guid ile belirlenmiş id kolonuna sahip kayıtlarım var diyelim. Ben daha sonra bu sunucuyu değiştirdiğimde daha önceki sunucunun vermiş olduğu guid numarasını yeni sunucuda verir mi ?

    Teşekkürler şimdiden..


    7 Temmuz 2014 Pazartesi 07:52

Yanıtlar

  • 9223372036854775807  /  200000 ~= 46116860184273

    Yani 46 trilyon defa 200.000 kayıt ekleyerek ancak bigint sınırına ulaşabilirsiniz.

    Fakat bu kadar yoğun insert ve delete çalışan bir sistemde page-lock azaltmak için PK yı auto-increment bigint yapmamak gerekir. guid kullanımı daha mantıklı olacaktır.


    Burak SARICA

    7 Temmuz 2014 Pazartesi 08:51
  • Merhabalar, 


    bigint olarak kalması daha sonraki sorgu performansı ve yönetimi açısından daha iyi olacaktır. Büyümeyi engellemek adına reseed işlemi yapabilirsiniz. 


    Çağlar Özenç www.caglarozenc.com

    7 Temmuz 2014 Pazartesi 08:52
  • Bigint ile, gunde 200,000 silme islemi ve 1,800,000 ekleme olsa, 2 milyon gunluk kullanimla sana milyarlarca yil yeter.

    GUID kullanmayi dusunursen:

    1) Avantajlari int/bigint'e kiyasla daha fazla (ozellikle offline kayit ekleniyorsa).

    2) Performans kaybi yasayacagin bir mit sayilir, cunku kayip denen performans yuzde 10 civarinda. O kadar performansi dert ediyor olsan SQL server yerine NoSQL database kullaniyor olurdun herhalde. GUID kullanmaya karar verirsen COMB GUID'e bak. Hazir C# kodlari da var.

    3) GUID ile SQL serverda varchar degil UniqueIdentifier tipi kullan.

    4) Herhangi bir makinede her hangi bir zamanda uretilen GUID degeri essiz olmamakla birlikte essiz kabul ediliyor. Cakisma sansi var ancak bunu iki kisinin ratgele havaya ates ettiklerinde kursunlarin havada carpismasina benzetebilirsin (kac kere piyango cikti sana? Ustelik bu sadece 6 rakamli da degil).

    7 Temmuz 2014 Pazartesi 09:05

Tüm Yanıtlar

  • Merhaba,

    big int olarak tutmanız daha sonraki sorgu performansınız için daha mantıklı olacaktır. Eğer bigint sınrına ulaşmasından korkuyorsanız ve kayıtlarınız düzenli ise identity kolon üzerinde ressed işlemi yapabilirsiniz. GUID konusunda da guid ister aynı makine ister farklı makine olsun aynısının üretilmesi olanaksız bir değerdir. Bunu da unique kolon olarak kullanabilirsiniz. 



    SQL Server 2012 Kitabımı incelediniz mi?

    7 Temmuz 2014 Pazartesi 08:38
  • Guid tipini MSSQL tarafında uniqueidentifier ile karşılayabilirsiniz.

    csharp ile

       var guid = Guid.NewGuid();

    mssql ile

    DECLARE @guid;
    SET @guid=NEWID();



    Mail Gönder


    • Düzenleyen Soner KOYLU 7 Temmuz 2014 Pazartesi 08:41
    7 Temmuz 2014 Pazartesi 08:39
  • 9223372036854775807  /  200000 ~= 46116860184273

    Yani 46 trilyon defa 200.000 kayıt ekleyerek ancak bigint sınırına ulaşabilirsiniz.

    Fakat bu kadar yoğun insert ve delete çalışan bir sistemde page-lock azaltmak için PK yı auto-increment bigint yapmamak gerekir. guid kullanımı daha mantıklı olacaktır.


    Burak SARICA

    7 Temmuz 2014 Pazartesi 08:51
  • Merhabalar, 


    bigint olarak kalması daha sonraki sorgu performansı ve yönetimi açısından daha iyi olacaktır. Büyümeyi engellemek adına reseed işlemi yapabilirsiniz. 


    Çağlar Özenç www.caglarozenc.com

    7 Temmuz 2014 Pazartesi 08:52
  • Bende aslında bigint durmasından yanayım performans için. Sanırım pek kolay kolay da sınırlarına ulaşamayacağız bigintin. Reseed de yaparsam sorun çıkmayacaktır sanırım. 200.000 kayıt eklemeden önce son kaydın id değerine göre reseed yaparsam sanırım sorun olmayacak..

    Farklı fikirleri olan var ise almak isterim ayrıca..


    7 Temmuz 2014 Pazartesi 08:55
  • RDBC sistemlerde reseed problem oluşturabilir. Process kesilmesi veya çalışma zamanında oluşan bir hata oldu diyelim diğer tabloda 255 numaralı id kaldı. Siz reseed yaptınız. Gider yine 255 i alırsa işiniz kötü.

    Mail Gönder

    7 Temmuz 2014 Pazartesi 09:01
  • Bigint ile, gunde 200,000 silme islemi ve 1,800,000 ekleme olsa, 2 milyon gunluk kullanimla sana milyarlarca yil yeter.

    GUID kullanmayi dusunursen:

    1) Avantajlari int/bigint'e kiyasla daha fazla (ozellikle offline kayit ekleniyorsa).

    2) Performans kaybi yasayacagin bir mit sayilir, cunku kayip denen performans yuzde 10 civarinda. O kadar performansi dert ediyor olsan SQL server yerine NoSQL database kullaniyor olurdun herhalde. GUID kullanmaya karar verirsen COMB GUID'e bak. Hazir C# kodlari da var.

    3) GUID ile SQL serverda varchar degil UniqueIdentifier tipi kullan.

    4) Herhangi bir makinede her hangi bir zamanda uretilen GUID degeri essiz olmamakla birlikte essiz kabul ediliyor. Cakisma sansi var ancak bunu iki kisinin ratgele havaya ates ettiklerinde kursunlarin havada carpismasina benzetebilirsin (kac kere piyango cikti sana? Ustelik bu sadece 6 rakamli da degil).

    7 Temmuz 2014 Pazartesi 09:05
  • Bigint ile, gunde 200,000 silme islemi ve 1,800,000 ekleme olsa, 2 milyon gunluk kullanimla sana milyarlarca yil yeter.

    GUID kullanmayi dusunursen:

    1) Avantajlari int/bigint'e kiyasla daha fazla (ozellikle offline kayit ekleniyorsa).

    2) Performans kaybi yasayacagin bir mit sayilir, cunku kayip denen performans yuzde 10 civarinda. O kadar performansi dert ediyor olsan SQL server yerine NoSQL database kullaniyor olurdun herhalde. GUID kullanmaya karar verirsen COMB GUID'e bak. Hazir C# kodlari da var.

    3) GUID ile SQL serverda varchar degil UniqueIdentifier tipi kullan.

    4) Herhangi bir makinede her hangi bir zamanda uretilen GUID degeri essiz olmamakla birlikte essiz kabul ediliyor. Cakisma sansi var ancak bunu iki kisinin ratgele havaya ates ettiklerinde kursunlarin havada carpismasina benzetebilirsin (kac kere piyango cikti sana? Ustelik bu sadece 6 rakamli da degil).

    Çetin abi teşekkürler cevabın için sanırım bigint ile gitmek yeterli olacak bana. Epey çok bir kayıt gerekiyor bigint in dolması için. Bu kadar kayıt dolanması da çok çok zor ihtimal bizim için. Teşekkürler cevabın için tekrar abi..

    7 Temmuz 2014 Pazartesi 09:43