Speicheroptimierte Tabellen - können sie wirklich so schwer zu pflegen sein?

Ich untersuche die Vorteile eines Upgrades von MS SQL 2012 auf 2014. Eines der großen Verkaufsargumente von SQL 2014 sind die speicheroptimierten Tabellen, die Abfragen anscheinend superschnell machen.

Ich habe festgestellt, dass es einige Einschränkungen für speicheroptimierte Tabellen gibt, wie zum Beispiel:

• Keine (max)großen Felder
• Maximal ~ 1 KB pro Zeile
• Keine timestampFelder
• Keine berechneten Spalten
• Keine UNIQUEEinschränkungen

Diese sind alle als Belästigungen zu qualifizieren, aber wenn ich sie wirklich umgehen möchte, um die Leistungsvorteile zu erzielen, kann ich einen Plan erstellen.

Der wahre Kicker ist die Tatsache, dass Sie keine ALTER TABLEAnweisung ausführen können und jedes Mal, wenn Sie der Liste eines Index ein Feld hinzufügen, diese Regel durchlaufen müssen INCLUDE. Außerdem müssen Sie anscheinend Benutzer vom System ausschließen, um Schemaänderungen an MO-Tabellen in der Live-DB vorzunehmen.

Ich finde das total empörend, insofern ich eigentlich nicht glauben kann, dass Microsoft so viel Entwicklungskapital in dieses Feature hätte investieren können, und es so unpraktisch zu warten. Dies führt mich zu dem Schluss, dass ich das falsche Ende des Stocks bekommen haben muss; Ich muss etwas an speicheroptimierten Tabellen falsch verstanden haben, was mich zu der Annahme geführt hat, dass es weitaus schwieriger ist, sie zu verwalten, als es tatsächlich ist.

Also, was habe ich falsch verstanden? Haben Sie MO-Tische verwendet? Gibt es eine Art geheimen Schalter oder Prozess, der es praktisch macht, sie zu verwenden und zu warten?

Nein, In-Memory ist wirklich so unpoliert. Wenn Sie mit Agile vertraut sind, kennen Sie das Konzept des "minimal versendbaren Produkts". In-Memory ist das. Ich habe das Gefühl, dass MS eine Antwort auf SAPs Hana und seine Bedürfnisse brauchte. Dies ist, was sie in der Zeitspanne für eine Veröffentlichung 2014 debuggen könnten.

Wie bei allem anderen hat auch In-Memory Kosten und Nutzen. Der größte Vorteil ist der erzielbare Durchsatz. Eine der Kosten ist, wie Sie bereits erwähnten, der Aufwand für das Änderungsmanagement. Dies macht es meiner Meinung nach nicht zu einem nutzlosen Produkt, sondern reduziert nur die Anzahl der Fälle, in denen es einen Nettonutzen bringt. Gerade als Columnstore-Indizes jetzt aktualisierbar sind und Indizes gefiltert werden können, habe ich keinen Zweifel daran, dass sich die Funktionalität von In-Memory in den kommenden Releases verbessern wird.

SQL Server 2016 ist jetzt allgemein verfügbar. Wie ich vermutet habe, hat In-Memory OLTP eine Reihe von Verbesserungen erhalten. Die meisten Änderungen implementieren Funktionen, über die herkömmliche Tabellen seit einiger Zeit verfügen. Ich vermute, dass zukünftige Funktionen gleichzeitig für In-Memory- und traditionelle Tabellen veröffentlicht werden. Temporale Tabellen sind ein typischer Fall. Neu in dieser Version wird es sowohl von In-Memory- als auch von festplattenbasierten Tabellen unterstützt.

Eines der Probleme bei der neuen Technologie - insbesondere bei einer V1-Version, die lautstark als nicht vollständig eingestuft wurde - ist, dass alle auf den Zug springen und davon ausgehen, dass sie für jede Arbeitsbelastung perfekt geeignet ist. Es ist nicht. Hekatons Sweet Spot sind OLTP-Workloads mit weniger als 256 GB und vielen Point-Lookups auf 2-4 Sockets. Passt dies zu Ihrer Arbeitsbelastung?

Viele der Einschränkungen betreffen In-Memory-Tabellen in Kombination mit nativ kompilierten Prozeduren. Sie können natürlich einige dieser Einschränkungen umgehen, indem Sie In-Memory-Tabellen verwenden keine nativ kompilierten Prozeduren verwenden oder zumindest nicht ausschließlich.

Offensichtlich müssen Sie testen, ob der Leistungszuwachs erheblich ist Ihrer Umgebung ist und ob sich die Kompromisse lohnen. Wenn Sie bei In-Memory-Tabellen große Leistungsgewinne erzielen, bin ich mir nicht sicher, warum Sie sich Sorgen darüber machen, wie viel Wartung Sie für INCLUDE-Spalten durchführen werden. Ihre speicherinternen Indizes decken per Definition ab. Diese Informationen sollten nur hilfreich sein, um zu vermeiden, dass herkömmliche nicht geclusterte Indizes in Reichweite oder vollständig durchsucht werden, und diese Vorgänge sollten eigentlich nicht in speicherinternen Tabellen ausgeführt werden und was nicht - es ist nicht alles Win-Win). Wie oft misten Sie heute mit INCLUDE-Spalten in Ihren Indizes herum?

Wenn es sich für Sie in der V1-Form noch nicht lohnt, sollten Sie es grundsätzlich nicht verwenden. Das ist keine Frage, die wir für Sie beantworten können, außer Ihnen mitzuteilen, dass es viele Kunden gibt bereit , mit den Einschränkungen zu leben, und werden mit der Funktion zu großem Nutzen trotz sie.

SQL Server 2016

Wenn Sie auf dem Weg zu SQL Server 2016 sind, habe ich über die Verbesserungen in In-Memory OLTP sowie die Beseitigung einiger Einschränkungen gebloggt . Vor allem:

• Erhöhung der maximalen dauerhaften Tabellengröße: 256 GB => 2 TB
• LOB / MAX-Spalten, Indizes für nullfähige Spalten, Entfernen der Anforderungen für die BIN2-Sortierung
• Prozeduren ändern und neu kompilieren
• Einige Unterstützung für ALTER TABLE - es wird offline sein, aber Sie sollten in der Lage sein, Indizes zu ändern und / oder zu löschen / neu zu erstellen (dies scheint jedoch bei aktuellen CTP-Builds nicht unterstützt zu werden, nehmen Sie dies also nicht als Garantie)
• DML-Trigger, FK / Check-Constraints, MARS
• ODER NICHT IN EXISTIERT, UNTERSCHEIDET, UNION, AUSSEN VERBINDET
• Parallelität

Du können in Sql Server Management Studio nicht mit der rechten Maustaste auf eine speicheroptimierte Tabelle klicken, um einen Designer aufzurufen und neue Spalten hinzuzufügen, wie Sie möchten. Sie könnten auch nicht als Mittel im Tabellennamen klicken der Umbenennung der Tabelle. (SQL 2014, als ich das schreibe.)

Stattdessen können Sie mit der rechten Maustaste auf die Tabelle klicken und einen Befehl create für ein neues Abfragefenster ausführen . Dieser Erstellungsbefehl kann durch Hinzufügen neuer Spalten geändert werden.

Um die Tabelle zu ändern, können Sie die Daten in einer neuen Tabelle, temporären Tabelle oder Tabellenvariablen speichern . Dann können Sie die Tabelle mit dem neuen Schema löschen und neu erstellen und schließlich die tatsächlichen Daten zurückkopieren . Dieses 3-Behälter-Schalen-Spiel ist für die meisten Anwendungsfälle nur wenig unbequem.

Sie haben jedoch keinen Grund, sich mit speicheroptimierten Tabellen zu beschäftigen, wenn es kein Leistungsproblem gibt, das Sie lösen möchten.

Dann müssen Sie abwägen, ob sich die Einschränkungen und Umgehungsmöglichkeiten für Ihren Anwendungsfall lohnen. Haben Sie ein Leistungsproblem? Hast du alles andere ausprobiert? Verbessert dies Ihre Leistung um das 10-100-fache? Wenn man es benutzt oder nicht benutzt, wird es wahrscheinlich so oder so ein bisschen hirnlos.

Sie können In-Memory-OLTP ohne größere Probleme auf Operationsservern verwenden. Wir haben diese Technologie in einem Bank- und Zahlungsunternehmen eingesetzt.

Im Allgemeinen können wir speicheroptimierte Tabellen verwenden, wenn die Auslastung zu hoch ist. Mit In-Memory-OLTP können Sie eine bis zu 30-fache Leistung erzielen! Microsoft korrigiert die meisten dieser Einschränkungen in SQL Server 2016 und 2017. Speicheroptimierte Tabellen haben eine völlig andere Architektur als festplattenbasierte Tabellen.

Es gibt zwei Arten von speicheroptimierten Tabellen. langlebige tische und langlebige tische. Dauerhafte und nicht dauerhafte Tabellen behalten Tabellendaten im Speicher. Darüber hinaus werden in dauerhaften Tabellen Daten auf Datenträgern für Wiederherstellungsdaten und -schemata beibehalten. In den meisten Betriebsszenarien sollten dauerhafte Tabellen verwendet werden, da hier Datenverluste von entscheidender Bedeutung sind. In einigen Szenarien, zum Beispiel beim Laden und Zwischenspeichern von ETLs, können wir nicht dauerhafte Tabellen verwenden.

Sie können diese eBooks verwenden und lernen, wie man diese Technologie einsetzt:

Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718