it-swarm.asia

SQL Server: tablodaki maksimum satır sayısı

Veritabanı tablolarından birinde (SQL Server sürüm 8, 9 veya 10) çok fazla veri depolayan bir yazılım geliştiriyorum. Diyelim ki, bu tabloya günde yaklaşık 100.000 kayıt ekleniyor. Bu, yılda yaklaşık 36 milyon kayıttır. Performansta kaybedeceğim korkusuyla, her gün kayıt sayısını azaltmak için her gün yeni bir tablo oluşturmaya karar verdim.

Bana bunun iyi bir fikir olup olmadığını söyler misiniz? SQL server tabloları için bir kayıt sınırı var mı? Veya performans önemli ölçüde düşürülmeden önce bir tabloda kaç tane kayıt (az ya da çok) saklayabileceğinizi biliyor musunuz?

66
Mariusz Schimke

Buna genel bir cevap vermek zor. Bu gerçekten faktörlerin sayısına bağlıdır:

  • sıranızın boyutu 
  • ne tür veri depolarsanız (dizeler, satırlar, sayılar)
  • verilerinizle ne yaparsınız (sadece arşiv olarak saklayın, düzenli olarak sorgulayın)
  • masanızda indeks var mı - kaç tane
  • sunucunun özellikleri nedir

vb.

Burada başka yerde cevaplandığı gibi, günde 100.000 ve bu nedenle masa başına fazla overkill. Ne kadar çok masa, o kadar büyük bir bakım/sorgu kabusu olur.

31
Rashack

Bunlar, SQL Server 2008 R2 için Maksimum Kapasite Spesifikasyonlarından bazılarıdır

  • Veritabanı boyutu: 524,272 terabayt
  • SQL Server örneği başına veritabanları: 32,767
  • Veritabanı başına dosya grupları: 32,767
  • Veritabanı başına dosya: 32,767
  • Dosya boyutu (veri): 16 terabayt
  • Dosya boyutu (log): 2 terabayt
  • Tablo başına satır: Kullanılabilir depolamaya göre sınırlı
  • Veri tabanı başına tablo sayısı: Veritabanındaki nesne sayısı ile sınırlıdır
81
Malak Gerges

SQL Server 2008 R2'de 6 Milyardan fazla satır içeren üç sütunlu bir tablom var.

Müşterilerimiz için her dakika dakika sistem analizi çizelgeleri oluşturmak için her gün sorgularız. Herhangi bir veritabanı performansı isabetini fark etmedim (her gün ~ 1 GB büyüdüğü gerçeği, yedeklemeleri yönetmeyi istediğimden biraz daha fazla etkiliyor olsa da).

Temmuz 2016 Güncellemesi

Row count

Yedeklemeleri iki yıldan daha eski kayıtları kısaltmaya karar vermemiz için yeterince büyük hale gelmeden önce ~ 24.5 milyar satır yaptık (pahalı bantlar dahil olmak üzere birden fazla yedeklemede depolanan ~ 700 GB). Performansın bu kararda önemli bir motive edici olmadığına dikkat çekmek önemlidir (yani, hala mükemmel çalışıyordu).

Kendilerini SQL Server'dan 20 milyar satırı silmeye çalışırken bulan herkes için, bu makale i tavsiye ederim. Bağlantının ölmesi durumunda ilgili kod (tam açıklama için makaleyi okuyun):

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

Kasım 2016 Güncellemesi

Bu kadar veriyi tek bir tabloda saklamayı planlıyorsanız: yapma. Tablo bölümlemesini göz önünde bulundurmanızı şiddetle tavsiye ederim (Manuel olarak veya Enterprise sürümünü çalıştırıyorsanız yerleşik özelliklerle). Bu, eski verileri bırakmayı bir çizelgeyi bir kere (hafta/ay/vb.) Kesmek kadar kolaylaştırır. Atılgan'ınız yoksa (bizde olmayan), ayda bir kez çalışan, 2 yıldan eski tabloları bırakan, gelecek ayın masasını oluşturan ve tüm bölüme katılan dinamik bir görünüm yaratan bir senaryo yazabilirsiniz kolay sorgulama için birlikte tablolar. Açıkçası "ayda bir" ve "2 yıldan daha eski", kullanım durumunuz için neyin mantıklı olduğuna bağlı olarak sizin tarafınızdan tanımlanmalıdır. Düzinelerce milyarlarca veri satırı içeren bir tablodan doğrudan silmek a) BÜYÜK bir zaman alır ve b) işlem günlüğünü yüzlerce veya binlerce kez doldurur.

33
Dan Bechard

Bir satır sınırı bilmiyorum, ancak 170 milyondan fazla satır içeren tabloları biliyorum. Bölümlenmiş tabloları (2005+) veya birden fazla tabloyu bağlayan görünümleri kullanarak hızlandırabilirsiniz.

19
Sascha

MSSQL'i özellikle bilmiyorum, ama 36 milyon satır kurumsal bir veritabanına göre büyük değil - ana bilgisayar veritabanları ile çalışıyor, 100.000 satır bana bir yapılandırma tablosu gibi geliyor :-).

Microsoft'un yazılımlarının bazılarının //hayranlarının büyük bir hayranı olmasam da, burada bahsettiğimiz Erişim bu değil: Kurumsal DBMS'leri ile oldukça büyük veritabanı boyutlarını kaldırabileceklerini düşünüyorum.

Günler, ayrılmaya ihtiyaç duyuyorsa, bunu bölmek için çok iyi bir çözüm olabileceğinden şüpheleniyorum.

18
paxdiablo

SQL Server 2005 ve 2008'de 1 Milyarın üzerinde satır bulunan tablolarımız var (günlük 30 milyon kişi eklendi). Her gün yeni bir masaya bölmek farelerin yuvalarına girmeyi hayal edemiyorum.

Uygun disk alanı (yine de ihtiyacınız olan) ve RAM eklemek için çok daha ucuz.

5
NotMe

Bağlıdır, ama basitlik uğruna her şeyi bir masada tutmanın daha iyi olacağını söyleyebilirim.

Günde 100.000 satır gerçekten çok büyük bir miktarda değil. (Sunucu donanımınıza bağlı olarak). Kişisel olarak MSSQL'in tek bir masada 100M satıra kadar herhangi bir problem yaşamadığını gördüm. Dizinlerinizi sırayla tuttuğunuz sürece her şey yolunda olmalı. Anahtar, yığın belleğe sahip olmaktır, böylece indekslerin diske aktarılması gerekmez.

Öte yandan, çok fazla sorgu yapmanız gerekiyorsa, verileri nasıl kullandığınıza bağlıdır ve birden fazla güne yayılan (bu nedenle tablolara katılmanıza gerek kalmayacak) olası verilere ihtiyaç olacaktır Birden fazla tabloya ayırmak için daha hızlı. Bu genellikle, her 10 saniyede 50.000 cihazdaki değeri okuyabileceğiniz endüstriyel proses kontrolü gibi uygulamalarda kullanılır. Bu durumda hız son derece önemlidir, ancak basitlik değildir.

4
Nathan

Bir masaya bir tamsayı ana anahtarını (~ 2,4 milyar satır) taşarız. Bir satır sınırı varsa, yılda yalnızca 36 milyon satıra çarpma ihtimaliniz yoktur.

3
Mark

Yeterli disk alanı olana kadar tabloyu doldurabilirsiniz .Daha iyi performans için SQL Server 2005'e geçmeyi deneyebilir ve daha sonra tabloyu bölümlere ayırabilir ve farklı disklere parçalar yerleştirebilirsiniz (gerçekten size yardımcı olabilecek RAID yapılandırmanız varsa). Bölümleme, yalnızca SQL Server 2005'in kurumsal sürümünde mümkündür. Bu bağlantıda bölümlendirme örneğine bakabilirsiniz: http://technet.Microsoft.com/en-us/magazine/cc162478.aspx

Ayrıca çoğu kullanılan veri bölümü için görünümler oluşturmayı deneyebilirsiniz, bu da çözümlerden biridir.

Umarım bu yardımcı oldu ...

2
branisha

Windows2003'te SQL Server 8'de karşılaştığım en büyük tablo 5 sütunlu 799 milyondu. Ancak bunun iyi bir irade olup olmadığına SLA ve kullanım durumuna karşı ölçülmek istenir. 50-100,000,000 kayıt yükleyin ve hala çalışıp çalışmadığını kontrol edin.

0
jpj