none
OLTP InMemory Optimized Table, performance slow RRS feed

  • Frage

  • Hallo,

    habe ein table die täglich mit bis zu 1.000.000 rows temporär befüllt wird.
    In der Nacht werden die rows wieder alle gelöscht.

    Alle 15min läuft ein Update-Befehl:

    update dbo.EEL_TODAY set 
    	 etd_ErstZutrittGast = isnull(sub.EG,0)	
    from dbo.EEL_TODAY e left join
    	(select e.etd_dazt, e.etd_eipo, e.etd_psnr
    		,ROW_NUMBER () OVER(PARTITION BY Cast(e.etd_dazt as Date), e.etd_psnr ORDER BY e.etd_dazt, e.etd_psnr) as EG
    	from dbo.EEL_TODAY e) sub on e.etd_dazt=sub.etd_dazt and e.etd_eipo=sub.etd_eipo and e.etd_psnr=sub.etd_psnr

    In der normalen disk-based EEL_TODAY benötigt der Update ca. 10sec je nach Auslastung.
    In der Memory optimized tabele EEL_TODAY_INMEM benötigt der Update ca. 20sec je nach Auslastung.
    Die Performance ist ca. um das Doppelte schlechter.

    Ziel wäre die Optimierung auf ca. 5sec.
    Wo liegt das Problem an der schlechten Performance bei Verwendung der InMemory table?

    Verwendete Indexe:

    Indexe

    Danke
    Chris



    • Bearbeitet woch Montag, 19. August 2019 11:36
    Montag, 19. August 2019 11:34

Alle Antworten

  • Hallo Chris,

    Der Grund für die schlechte Leistung bei der Verwendung von einer InMemory-OLTP-Datenbank kann ein sehr niedriger Hashbucket-Wert in Deiner InMemory-Tabellendefinition sein. Weitere Informationen findest Du in folgendem Blog-Artikel:
    SQL Server – InMemory OLTP Hash Collisions Performance Overhead

    Gruß,

    Ivan Dragov


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Dienstag, 20. August 2019 10:59
    Moderator
  • Hallo Ivan,

    vielen Dank für den Tipp.

    Ich verwende derzeit bei ca. 1.000.00 rows einen Bucket_SIZE von 2.097.152.
    Der HASH Index mit den columns etd_dazt,etd_psnr ist soweit eindeutig,
    der Bucket_SIZE damit ca. doppelt so hoch.
    Ich werde mal mit verschiedenen sizes testen und mich wieder melden.
    Danke Chris
    Bucket_SIZE

    Mittwoch, 21. August 2019 11:30
  • Hallo,

    1. InMemory table
    WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY, SYSTEM_VERSIONING = OFF)
    ich habe nun einige Update Tests mit unterschiedlichen BUCKET_SIZES gemacht.
    Es macht fast keinen Unterschied, welche Größe der BUCKET_SIZE hat.
       524.288 -> 6,133 sec
    1.048.576 -> 5,891 sec
    2.097.152 -> 5,790 sec
    4.194.304 -> 5,975 sec
    8.388.608 -> 5,831 sec

    2. Standard disk based table-> 3.456 sec

    So wie es aussieht liegt es nicht am BUCKET_SIZE.
    Was kann ich noch tun (Index-Tuning)?

    Danke

    Chris


    • Bearbeitet woch Mittwoch, 21. August 2019 16:28
    Mittwoch, 21. August 2019 12:43
  • Hallo

    ich bin mir nicht sicher ob Dein Scenario fuer memory-optimized tables ideal ist.

    Reine Memory optimized tables sind nicht fuer Massen-Operationen gedacht. Speziell Datenaenderungen sind in grossen Bereichen weniger effizient. Die Staerke von In-Memory OLTP liegt in singleton-Abfragen (daher "OLTP" im Namen)

    Moeglicherweise ist eine Kombination aus Columstore Indexen und memory-optimized index auf den heissen Daten hier die bessere Wahl. Wie das aussehen kann sieht man hier: https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/03/07/real-time-operational-analytics-memory-optimized-table-and-columnstore-index/

    Andreas


    Andreas Wolter (Blog | Twitter)
    Senior Program Manager SQL Server & Azure Security

    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012

    Freitag, 23. August 2019 12:10
  • Hallo,

    hier noch ein ganzer Artikel von Andreas:

    http://andreas-wolter.com/en/optimizing-workflows-with-in-memory-and-natively-compiled-objects/

    Das sollte, aus meiner Sicht, einen Versuch Wert sein: Beim Aktualisieren in Paketen arbeiten. Deine Pakete sollten in der Row_number stecken.
    HTH
    Grüße 

    Freitag, 23. August 2019 13:12
  • Hallo,

    ein Columnstore Index hat nichts gebracht, die Update-Leistung ist gesunken.
    Weiters funktioniert dieser index nur mit der Option Durability = SCHEMA_AND_DATA.
    Dazu braucht man wiederum einen Primary-Key.

    ALTER TABLE [dbo].[EEL_TODAY_INMEM21]
     ADD INDEX idx_columnstore_01 CLUSTERED COLUMNSTORE 

    Die Stärke die ich feststellen konnte ist das Inserten.
    Für 1.000.000 DS braucht das System nur 1,2sec.

    Es sieht so aus, als ob es für nested Updates nicht geeignet ist.

    Danke

    Donnerstag, 29. August 2019 15:13