Tabelle ottimizzate per la memoria: possono davvero essere così difficili da mantenere?


18

Sto studiando i vantaggi dell'aggiornamento da MS SQL 2012 a 2014. Uno dei maggiori punti di forza di SQL 2014 sono le tabelle ottimizzate per la memoria, che apparentemente rendono le query superveloci.

Ho scoperto che ci sono alcune limitazioni sulle tabelle ottimizzate per la memoria, come:

  • Nessun (max)campo di dimensioni
  • Massimo ~ 1 KB per riga
  • Nessun timestampcampo
  • Nessuna colonna calcolata
  • Nessun UNIQUEvincolo

Tutti questi si qualificano come fastidi, ma se voglio davvero aggirarli per ottenere i vantaggi in termini di prestazioni, posso fare un piano.

Il vero kicker è il fatto che non puoi eseguire ALTER TABLEun'istruzione e devi passare attraverso questo rigmarole ogni volta che aggiungi un campo INCLUDEall'elenco di un indice. Inoltre, sembra che sia necessario escludere gli utenti dal sistema per apportare eventuali modifiche allo schema delle tabelle MO sul DB live.

Lo trovo totalmente scandaloso, nella misura in cui non riesco davvero a credere che Microsoft avrebbe potuto investire così tanto capitale di sviluppo in questa funzionalità, lasciandolo così poco pratico da mantenere. Questo mi porta alla conclusione che devo aver ottenuto la parte sbagliata del bastone; Devo aver frainteso qualcosa sulle tabelle ottimizzate per la memoria che mi ha portato a credere che sia molto più difficile mantenerle di quanto non sia in realtà.

Quindi, cosa ho capito male? Hai usato i tavoli MO? Esiste una sorta di interruttore o processo segreto che li rende pratici da usare e mantenere?

Risposte:


18

No, in memoria è davvero questo non lucidato. Se hai familiarità con Agile, conoscerai il concetto di "prodotto shippable minimo"; in memoria è quello. Ho la sensazione che la SM avesse bisogno di una risposta a Hana di SAP e ai suoi simili. Questo è ciò che potrebbero essere sottoposti a debug nel periodo di tempo per una versione del 2014.

Come ogni altra cosa in memoria ha costi e benefici ad essa associati. Il principale vantaggio è il rendimento che può essere raggiunto. Uno dei costi è l'overhead per la gestione delle modifiche, come hai detto. Questo non lo rende un prodotto inutile, a mio avviso, riduce solo il numero di casi in cui fornirà un vantaggio netto. Proprio come gli indici columnstore sono ora aggiornabili e gli indici possono essere filtrati, non ho dubbi che la funzionalità della memoria migliorerà rispetto alle versioni future.


SQL Server 2016 è ora generalmente disponibile. Proprio come immaginavo, OLTP in memoria ha ricevuto numerosi miglioramenti. La maggior parte delle modifiche implementano funzionalità di cui le tabelle tradizionali hanno goduto per un po 'di tempo. La mia ipotesi è che le funzionalità future verranno rilasciate contemporaneamente per tabelle sia in memoria che tradizionali. Le tabelle temporali sono un esempio emblematico. Novità di questa versione, è supportata da tabelle sia in memoria che su disco .


14

Uno dei problemi con la nuova tecnologia - in particolare una versione V1 che è stata divulgata abbastanza rumorosamente come non completo di funzionalità - è che tutti saltano sul carrozzone e presumono che sia perfetto per ogni carico di lavoro. Non è. Il punto debole di Hekaton sono i carichi di lavoro OLTP inferiori a 256 GB con molte ricerche puntuali su 2-4 socket. Questo corrisponde al tuo carico di lavoro?

Molte delle limitazioni riguardano le tabelle in memoria combinate con le procedure compilate in modo nativo. Ovviamente puoi aggirare alcune di queste limitazioni usando le tabelle in memoria ma non usando le procedure compilate in modo nativo, o almeno non esclusivamente.

Ovviamente è necessario verificare se il guadagno in termini di prestazioni è sostanziale nel proprio ambiente e, in caso affermativo, se ne valga la pena. Se stai ottenendo grandi miglioramenti delle prestazioni dalle tabelle in memoria, non sono sicuro del motivo per cui sei preoccupato per quanta manutenzione eseguirai sulle colonne INCLUDE. Gli indici in memoria sono per definizione coprenti. Questi dovrebbero essere davvero utili solo per evitare ricerche sull'intervallo o scansioni complete di indici tradizionali non cluster e queste operazioni non dovrebbero realmente avvenire in tabelle in memoria (di nuovo, dovresti profilare il tuo carico di lavoro e vedere quali operazioni migliorano e che no - non è tutto vincente). Con quale frequenza muck oggi con le colonne INCLUDE sui tuoi indici?

Fondamentalmente, se non ne vale ancora la pena per te nella sua forma V1, non usarlo. Non è una domanda a cui possiamo rispondere per te, se non per dirti che molti clienti sono disposti a convivere con i limiti e stanno usando la funzione per trarne grandi benefici, nonostante ciò.

SQL Server 2016

Se sei sulla buona strada per SQL Server 2016, ho scritto un blog sui miglioramenti che vedrai in OLTP in memoria, nonché sull'eliminazione di alcune limitazioni . Soprattutto:

  • Aumento della dimensione massima del tavolo durevole: 256 GB => 2 TB
  • Colonne LOB / MAX, indici su colonne nullable, rimozione dei requisiti di confronto BIN2
  • Modificare e ricompilare le procedure
  • Qualche supporto per ALTER TABLE - sarà offline ma dovresti essere in grado di alterare e / o rilasciare / ricreare gli indici (questo non sembra essere supportato sulle build CTP correnti, quindi non prenderlo come garanzia)
  • Trigger DML, vincoli FK / check, MARS
  • OPPURE, NON ESISTE, DISTINCT, UNION, OUTER JOINs
  • Parallelismo

Stavo usando le colonne "include" come esempio di una banale modifica che avrei potuto fare, ma ora ho imparato da te che questo non è un buon esempio. Ciò che è più rilevante è, ad esempio, l'aggiunta di nuove colonne nullable, che è un'azione molto non distruttiva in una tabella convenzionale, ma sarà molto onerosa con le tabelle MO. Dal momento che il sistema su cui stiamo lavorando è in continua espansione (le nostre richieste di funzionalità sono in numero in competizione con le segnalazioni di bug), è probabile che questo sia un killer per noi.
Shaul Behr,

3
@shaul ok, quindi non usarlo. Oppure metti solo tabelle stabili in memoria. Oppure considera un design diverso in cui aggiungi costantemente colonne (EAV). Così com'è, penso che tu stia solo rantolando che questa tecnologia non fa per te. Ho figli, quindi non mi lamento che una Porsche Cayman S non è pratica per me - o almeno non come pilota quotidiano. Forse potrei usarlo nei fine settimana (proprio come forse potresti usare OLTP in memoria per parti del tuo schema, ma non tutto). Il fatto che tu abbia requisiti che non sono così comuni e che sono in conflitto con le funzionalità V1, non è colpa di Microsoft.
Aaron Bertrand

Aaron, cos'è l'EAV?
Shaul Behr,


2

Non è possibile fare clic con il pulsante destro del mouse su una tabella ottimizzata per la memoria, richiamare un designer e aggiungere nuove colonne a piacere, da Sql Server Management Studio. Inoltre, non è possibile fare clic all'interno del nome della tabella come mezzo per rinominare la tabella. (SQL 2014 al momento della mia scrittura.)

Al contrario, è possibile fare clic con il pulsante destro del mouse sulla tabella ed eseguire lo script di un comando di creazione in una nuova finestra di query. Questo comando di creazione può essere modificato aggiungendo nuove colonne.

Pertanto, per modificare la tabella, è possibile archiviare i dati in una nuova tabella, tabella temporanea o variabile di tabella. Quindi è possibile eliminare e ricreare la tabella con il nuovo schema e infine copiare nuovamente i dati effettivi . Questo gioco shell a 3 contenitori è solo un po 'meno conveniente per la maggior parte dei casi d'uso.

Tuttavia, non avresti motivo di preoccuparti delle tabelle ottimizzate per la memoria se non ci sono problemi di prestazioni che stai cercando di risolvere.

Quindi, dovrai valutare se le limitazioni e le soluzioni alternative valgono la pena per il tuo caso d'uso. Hai un problema di prestazioni? Hai provato tutto il resto? Ciò migliorerà le tue prestazioni di 10-100x? Usarlo o non usarlo probabilmente finirà per essere un po 'un non-cervello in entrambi i modi.


-2

è possibile utilizzare OLTP in memoria nei server operativi senza grossi problemi. abbiamo utilizzato questa tecnologia in una società bancaria e di pagamento,

In generale, possiamo usare tabelle ottimizzate per la memoria quando il carico di lavoro è troppo elevato. utilizzando OLTP in memoria è possibile raggiungere prestazioni migliori a 30X! Microsoft corregge la maggior parte di queste limitazioni in SQL Server 2016 e 2017. le tabelle ottimizzate per la memoria hanno un'architettura completamente diversa rispetto alle tabelle basate su disco.

le tabelle ottimizzate per la memoria sono di due tipi. tavoli durevoli e tavoli non durevoli. Le tabelle durevoli e non durevoli mantengono in memoria i dati della tabella. Inoltre, le tabelle durevoli persistono nei dati sui dischi per dati e schema di ripristino. la maggior parte dello scenario operativo dovremmo usare tabelle durevoli perché i dati persi sono fondamentali qui. in alcuni scenari, ad esempio caricamento ETL e memorizzazione nella cache, è possibile utilizzare tabelle non durevoli.

puoi usare questi ebook e imparare come usare questa tecnologia:

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

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.