MariaDB
 sql >> Database >  >> RDS >> MariaDB

Analisi con MariaDB AX - tThe Open Source Columnar Datastore

Sono lontani i giorni dell'approccio del database unico adatto a tutti.

Con i crescenti requisiti di velocità, prestazioni e agilità, sono emersi numerosi datastore con lo scopo di risolvere un problema particolare. Disponiamo di database relazionali, archivi di documenti, database di serie temporali, database a colonne, motori di ricerca full-text.

È abbastanza comune vedere più datastore lavorare insieme nello stesso ambiente.

Quindi come si inserisce MariaDB AX nell'immagine? Come si confronta con MariaDB TX e quale problema risolve?

In questo post del blog daremo un'occhiata a MariaDB AX e vedremo perché potresti volerlo usare.

Cos'è MariaDB AX?

Per prima cosa, quindi cos'è MariaDB AX?

È un archivio di colonne e memorizza i suoi dati per ... colonna! È implementato come motore separato nel database MariaDB 10.3.

Come forse saprai, MySQL e MariaDB sono progettati per utilizzare motori di archiviazione collegabili. Ogni motore di archiviazione, sia esso InnoDB, Aria, MyRocks, Spider o qualsiasi altro motore, è un plug-in.

Allo stesso modo, MariaDB AX utilizza il motore ColumnStore:

MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
      Engine: Columnstore
     Support: YES
     Comment: Columnstore storage engine
Transactions: YES
          XA: NO
  Savepoints: NO

Ciò si traduce in una combinazione interessante. L'analisi SQL viene eseguita da MariaDB, quindi puoi aspettarti di lavorare con la sintassi delle query che è molto simile a quella a cui sei abituato in MariaDB. Questo rende anche più facile combinare l'accesso sia a MariaDB AX che a MariaDB TX nella stessa applicazione. Non sono necessari connettori o librerie specifici per la connessione a due datastore. Tutto può essere fatto utilizzando la libreria client MySQL o MariaDB. Puoi anche utilizzare MaxScale per entrambi i datastore, il che può aiutare a creare un'elevata disponibilità per MariaDB AX.

Perché dovremmo utilizzare un datastore a colonne?

Esaminiamo una breve introduzione all'idea alla base dei datastore a colonna.

Cosa rende MariaDB AX diversa da MariaDB TX?

La differenza principale è come sono strutturati i dati. In un database tipico i dati vengono archiviati come righe.

Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2

Come puoi vedere, abbiamo tre righe, ciascuna contenente tutti i dati su una voce di prodotto.

Il problema è che questo modo di archiviare i dati non è molto efficiente quando si desidera ottenere solo un sottoinsieme di questi dati. Diciamo che vuoi ottenere solo le colonne "Prodotto" e "Prezzo" - per farlo devi leggere righe intere, tutti i dati e quindi scartare le colonne non necessarie. È anche complicato ordinare i dati. Se desideri ordinare il set di dati dal prodotto più costoso a quello più economico devi leggere tutto e quindi eseguire l'ordinamento.

Sappiamo tutti che i database utilizzano gli indici per velocizzare l'accesso. Un indice è strutturato in modo da contenere il contenuto della colonna indicizzata e un puntatore alla riga intera (in InnoDB è la chiave primaria). Ad esempio, un indice nella colonna "Prodotto", supponendo che "Id" sia la chiave primaria, potrebbe avere il seguente aspetto:

Product, Id
Door, 1
Window, 2
Glass, 3

Ciò velocizza l'accesso ai dati poiché non è necessario leggere l'intera riga solo per trovare un valore nella colonna "Prodotto". Una volta che il database lo trova, può leggere il resto della riga (se necessario) seguendo il puntatore.

In un negozio di colonne, le cose sono diverse. I dati sono strutturati non come righe ma come colonne. In una certa misura questo è simile all'indice. La nostra tabella nel datastore a colonne potrebbe assomigliare a questa:

Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2

In MariaDB AX, le colonne sono archiviate in file separati, ogni voce per una determinata "riga" inizia con lo stesso offset.

Il vantaggio principale qui è che se vuoi eseguire una query che funzioni solo con un sottoinsieme di dati, devi solo leggere i dati dalle colonne che sono rilevanti per la query.

Nel nostro esempio precedente, invece di leggere l'intero set di dati, possiamo semplicemente caricare i dati per le colonne "Prodotto" e "Prezzo". Riduce i dati necessari per l'accesso su disco e velocizza il processo.

Ciò che è anche importante, la memorizzazione dei dati nelle colonne li rende meno distinti, il che li rende più compressi. Ad esempio, nella nostra colonna "Magazzino" abbiamo solo due tipi di voci. Anche nello scenario reale è molto probabile che ci ritroveremo con un numero di magazzini esiguo rispetto al numero di prodotti. Ciò rende la colonna "Magazzino" un ottimo obiettivo per la compressione.

Come risultato di tutto ciò, i datastore a colonna possono gestire meglio set di dati di grandi dimensioni e possono interrogarli in modo più efficiente rispetto ai database "standard" incentrati su OLTP.

Perché dovrei usare MariaDB AX?

L'accesso al disco è un importante collo di bottiglia nei database. Un datastore a colonne migliora le prestazioni riducendo la quantità di dati che devono essere letti dal disco. Legge solo i dati necessari per rispondere alla domanda.

Naturalmente, MariaDB AX non è l'unico datastore colonnare disponibile. Ce ne sono molti altri come, ad esempio, Clickhouse o Apache HBase.

La verità è che nessuna delle altre opzioni supporta la sintassi SQL completa che MySQL fa. Richiedono connettori diversi, un approccio diverso per interrogare i dati mentre MariaDB AX può essere interrogato proprio come faresti con il "normale" MariaDB.

Ciò che è anche importante, dato che MariaDB AX utilizza il motore ColumnStore, va benissimo mescolarlo con altri motori. Puoi combinare e unire tabelle InnoDB e ColumnStore nella stessa query senza alcun problema.

Inoltre, gli strumenti forniti con MariaDB TX, come MaxScale, funzioneranno perfettamente con MariaDB AX, semplificando la creazione di un ambiente integrato e facile da usare. Quindi, quando esegui ClusterControl con MariaDB 10.3 e MaxScale, puoi facilmente aggiungere MariaDB AX al mix e funzionerà con altre parti della configurazione.

MariaDB AX viene fornito con strumenti che hanno lo scopo di aiutare con il trasferimento dei dati da altre fonti. Se ti capita di utilizzare Kafka o Spark, ci sono connettori da utilizzare durante l'importazione di dati da tali origini in MariaDB AX.

Inoltre, anche se la replica regolare tra MariaDB TX (InnoDB) e MariaDB AX (ColumnStore) non funziona bene a causa delle limitazioni di ColumnStore (è sempre meglio eseguire inserimenti batch nei datastore a colonne piuttosto che singoli inserimenti, come avviene durante la replica), è possibile costruire una pipeline composta da MaxScale configurato come server binlog e router Avro CDC, MaxScale CDC Data Adapter e MariaDB AX, che riceverà i dati dall'adattatore quasi in tempo reale.

Ci auguriamo che questo post del blog ti dia un'idea di cos'è MariaDB AX e di come può essere utilizzato insieme all'ambiente MariaDB TX distribuito e gestito da ClusterControl (scaricalo gratuitamente!).