De typische MySQL DBA kan vertrouwd zijn met het werken en beheren van een OLTP-database (Online Transaction Processing) als onderdeel van hun dagelijkse routine. U bent misschien bekend met hoe het werkt en hoe u complexe operaties kunt beheren. Hoewel de standaard opslagengine die MySQL levert goed genoeg is voor OLAP (Online Analytical Processing), is het behoorlijk simplistisch, vooral voor degenen die kunstmatige intelligentie willen leren of die zich bezighouden met prognoses, datamining en data-analyse.
In deze blog gaan we het hebben over de MariaDB ColumnStore. De inhoud wordt op maat gemaakt ten behoeve van de MySQL DBA, die mogelijk minder begrip heeft van de ColumnStore en hoe deze van toepassing kan zijn op OLAP-toepassingen (Online Analytical Processing).
OLTP versus OLAP
OLTP
Gerelateerde bronnen Analytics met MariaDB AX - de open source kolomvormige datastore Een inleiding tot tijdreeksdatabases Hybride OLTP/Analytics-databaseworkloads in Galera-cluster met behulp van asynchrone slavenDe typische MySQL DBA-activiteit voor het verwerken van dit soort gegevens is het gebruik van OLTP (Online Transaction Processing). OLTP wordt gekenmerkt door grote databasetransacties die invoegingen, updates of verwijderingen uitvoeren. Databases van het OLTP-type zijn gespecialiseerd voor snelle verwerking van query's en het handhaven van de gegevensintegriteit terwijl ze in meerdere omgevingen worden gebruikt. De effectiviteit wordt gemeten aan de hand van het aantal transacties per seconde (tps). Het is vrij gebruikelijk dat de bovenliggende-kindrelatietabellen (na implementatie van het normalisatieformulier) overtollige gegevens in een tabel verminderen.
Records in een tabel worden gewoonlijk sequentieel verwerkt en opgeslagen op een rijgeoriënteerde manier en zijn sterk geïndexeerd met unieke sleutels om het ophalen of schrijven van gegevens te optimaliseren. Dit is ook gebruikelijk voor MySQL, vooral als het gaat om grote invoegingen of hoge gelijktijdige schrijfacties of bulkinvoegingen. De meeste opslagengines die MariaDB ondersteunt, zijn van toepassing op OLTP-toepassingen - InnoDB (de standaard opslagengine sinds 10.2), XtraDB, TokuDB, MyRocks of MyISAM/Aria.
Toepassingen zoals CMS, FinTech en Web Apps hebben vaak te maken met zware schrijf- en leesbewerkingen en vereisen vaak een hoge doorvoer. Om deze applicaties te laten werken, is vaak diepgaande expertise nodig op het gebied van hoge beschikbaarheid, redundantie, veerkracht en herstel.
OLAP
OLAP pakt dezelfde uitdagingen aan als OLTP, maar gebruikt een andere benadering (vooral bij het ophalen van gegevens). OLAP behandelt grotere datasets en is gebruikelijk voor datawarehousing, vaak gebruikt voor toepassingen van het type business intelligence. Het wordt vaak gebruikt voor beheer van bedrijfsprestaties, planning, budgettering, prognoses, financiële rapportage, analyse, simulatiemodellen, kennisontdekking en datawarehouse-rapportage.
Gegevens die in OLAP zijn opgeslagen, zijn doorgaans niet zo kritisch als die in OLTP. Dit komt omdat de meeste gegevens kunnen worden gesimuleerd die afkomstig zijn van OLTP en vervolgens kunnen worden ingevoerd in uw OLAP-database. Deze gegevens worden meestal gebruikt voor bulklading, vaak nodig voor bedrijfsanalyses die uiteindelijk worden weergegeven in visuele grafieken. OLAP voert ook multidimensionale analyses uit van bedrijfsgegevens en levert resultaten die kunnen worden gebruikt voor complexe berekeningen, trendanalyse of geavanceerde gegevensmodellering.
OLAP slaat gegevens meestal permanent op met behulp van een kolomindeling. In MariaDB ColumnStore worden de records echter uitgesplitst op basis van de kolommen en afzonderlijk in een bestand opgeslagen. Op deze manier is het ophalen van gegevens zeer efficiënt, omdat het alleen de relevante kolom scant waarnaar wordt verwezen in uw SELECT-opdrachtquery.
Zie het als volgt:OLTP-verwerking verwerkt uw dagelijkse en cruciale gegevenstransacties die uw bedrijfstoepassing uitvoeren, terwijl OLAP u helpt bij het beheren, voorspellen, analyseren en beter op de markt brengen van uw product - de bouwstenen van het hebben van een bedrijfstoepassing.
Wat is MariaDB ColumnStore?
MariaDB ColumnStore is een pluggable zuilvormige opslag-engine die draait op MariaDB Server. Het maakt gebruik van een parallelle gedistribueerde gegevensarchitectuur met behoud van dezelfde ANSI SQL-interface die wordt gebruikt in het MariaDB-serverportfolio. Deze opslagengine bestaat al een tijdje, omdat het oorspronkelijk was geporteerd vanuit InfiniDB (een inmiddels ter ziele gegane code die nog steeds beschikbaar is op github.) Het is ontworpen voor big data-schaling (om petabytes aan gegevens te verwerken), lineaire schaalbaarheid en echte -tijdige reactie op analytics-query's. Het maakt gebruik van de I/O-voordelen van zuilvormige opslag; compressie, just-in-time projectie en horizontale en verticale partitionering om geweldige prestaties te leveren bij het analyseren van grote datasets.
Ten slotte is MariaDB ColumnStore de ruggengraat van hun MariaDB AX-product als de belangrijkste opslagengine die door deze technologie wordt gebruikt.
Hoe verschilt MariaDB ColumnStore van InnoDB?
InnoDB is toepasbaar voor OLTP-verwerking waarbij uw applicatie zo snel mogelijk moet reageren. Het is handig als uw toepassing met die aard te maken heeft. Aan de andere kant is MariaDB ColumnStore een geschikte keuze voor het beheren van big data-transacties of grote datasets met complexe joins, aggregatie op verschillende niveaus van dimensiehiërarchie, projecteren van een financieel totaal voor een breed scala van jaren, of het gebruik van gelijkheid en bereikselecties . Deze benaderingen die ColumnStore gebruiken, vereisen niet dat u deze velden indexeert, omdat het voldoende sneller kan werken. InnoDB kan dit soort prestaties niet echt aan, hoewel er geen belemmering is om dat te proberen, zoals mogelijk is met InnoDB, maar tegen een prijs. Hiervoor moet u indexen toevoegen, waardoor grote hoeveelheden gegevens aan uw schijfopslag worden toegevoegd. Dit betekent dat het meer tijd kan kosten om uw zoekopdracht af te ronden, en het kan zijn dat deze helemaal niet wordt voltooid als deze vastzit in een tijdlus.
MariaDB ColumnStore-architectuur
Laten we eens kijken naar de MariaDB ColumStore-architectuur hieronder:
Afbeelding met dank aan MariaDB ColumnStore-presentatie In tegenstelling tot de InnoDB-architectuur bevat de ColumnStore twee modules die aangeven dat het de bedoeling is om efficiënt te werken in een gedistribueerde architecturale omgeving. InnoDB is bedoeld om op een server te schalen, maar strekt zich uit over meerdere onderling verbonden knooppunten, afhankelijk van een clusterconfiguratie. Daarom heeft ColumnStore componenten op meerdere niveaus die zorgen voor de processen die zijn aangevraagd bij de MariaDB Server. Laten we graven op deze componenten hieronder:
- Gebruikersmodule (UM):De UM is verantwoordelijk voor het ontleden van de SQL-verzoeken in een geoptimaliseerde set primitieve taakstappen die worden uitgevoerd door een of meer PM-servers. De UM is dus verantwoordelijk voor query-optimalisatie en orkestratie van de query-uitvoering door de PM-servers. Hoewel meerdere UM-instanties kunnen worden geïmplementeerd in een implementatie met meerdere servers, is één enkele UM verantwoordelijk voor elke afzonderlijke query. Een database load balancer, zoals MariaDB MaxScale, kan worden ingezet om externe verzoeken op de juiste manier af te stemmen op individuele UM-servers.
- Performance Module (PM):De PM voert gedetailleerde taakstappen uit die zijn ontvangen van een UM op een multi-threaded manier. ColumnStore maakt distributie van werk over veel prestatiemodules mogelijk. De UM bestaat uit het MariaDB mysqld-proces en het ExeMgr-proces.
- Extent Maps:ColumnStore bewaart metadata over elke kolom in een gedeeld gedistribueerd object dat bekend staat als de Extent Map. De UM-server verwijst naar de Extent Map om te helpen bij het genereren van de juiste primitieve taakstappen. De PM-server verwijst naar de Extent Map om de juiste schijfblokken te identificeren die moeten worden gelezen. Elke kolom bestaat uit een of meer bestanden en elk bestand kan meerdere extensies bevatten. Het systeem probeert zoveel mogelijk aaneengesloten fysieke opslag toe te wijzen om de leesprestaties te verbeteren.
- Opslag:ColumnStore kan lokale opslag of gedeelde opslag (bijv. SAN of EBS) gebruiken om gegevens op te slaan. Door gedeelde opslag te gebruiken, kan de gegevensverwerking automatisch overgaan naar een ander knooppunt in het geval dat een PM-server uitvalt.
Hieronder ziet u hoe MariaDB ColumnStore de query verwerkt,
- Klanten sturen een query naar de MariaDB-server die op de gebruikersmodule draait. De server voert een tabelbewerking uit voor alle tabellen die nodig zijn om aan het verzoek te voldoen en verkrijgt het initiële plan voor het uitvoeren van de query.
- Met behulp van de MariaDB-opslagengine-interface converteert ColumnStore het servertabelobject naar ColumnStore-objecten. Deze objecten worden vervolgens verzonden naar de processen van de gebruikersmodule.
- De gebruikersmodule converteert het MariaDB-uitvoeringsplan en optimaliseert de gegeven objecten in een ColumnStore-uitvoeringsplan. Het bepaalt vervolgens de stappen die nodig zijn om de query uit te voeren en de volgorde waarin ze moeten worden uitgevoerd.
- De gebruikersmodule raadpleegt vervolgens de omvangkaart om te bepalen welke prestatiemodules moeten worden geraadpleegd voor de gegevens die hij nodig heeft, en voert vervolgens de omvangeliminatie uit, waarbij alle prestatiemodules uit de lijst worden verwijderd die alleen gegevens bevatten buiten het bereik van wat de query vereist.
- De gebruikersmodule stuurt vervolgens opdrachten naar een of meer prestatiemodules om blok-I/O-bewerkingen uit te voeren.
- De prestatiemodule of -modules voeren predikaatfiltering, join-verwerking, initiële aggregatie van gegevens uit lokale of externe opslag uit en sturen de gegevens vervolgens terug naar de gebruikersmodule.
- De gebruikersmodule voert de uiteindelijke aggregatie van de resultatenset uit en stelt de resultatenset voor de zoekopdracht samen.
- De gebruikersmodule / ExeMgr implementeert alle vensterfunctieberekeningen, evenals elke noodzakelijke sortering op de resultatenset. Het retourneert vervolgens de resultatenset naar de server.
- De MariaDB-server voert alle geselecteerde lijstfuncties, ORDER BY- en LIMIT-bewerkingen uit op de resultatenset.
- De MariaDB-server stuurt de resultatenset terug naar de client.
Paradigma's voor het uitvoeren van query's
Laten we wat meer graven hoe ColumnStore de query uitvoert en wanneer deze van invloed is.
ColumnStore verschilt met de standaard MySQL/MariaDB-opslagengines zoals InnoDB, omdat ColumnStore beter presteert door alleen de noodzakelijke kolommen te scannen, door het systeem onderhouden partitionering te gebruiken en meerdere threads en servers te gebruiken om de reactietijd van de query te schalen. De prestaties komen ten goede wanneer u alleen kolommen opneemt die nodig zijn voor het ophalen van gegevens. Dit betekent dat de gulzige asterisk (*) in uw geselecteerde zoekopdracht een aanzienlijke impact heeft in vergelijking met een SELECT
Net als bij InnoDB en andere opslagengines, is het gegevenstype ook van belang voor de prestaties van wat u hebt gebruikt. Als je zegt dat je een kolom hebt die alleen de waarden 0 tot en met 100 kan hebben, declareer dit dan als een tinyint, omdat dit wordt weergegeven met 1 byte in plaats van 4 bytes voor int. Dit verlaagt de I/O-kosten met 4 keer. Voor stringtypes is een belangrijke drempelwaarde char(9) en varchar(8) of hoger. Elk kolomopslagbestand gebruikt een vast aantal bytes per waarde. Dit maakt een snelle positionele opzoeking van andere kolommen mogelijk om de rij te vormen. Momenteel is de bovengrens voor gegevensopslag in kolommen 8 bytes. Dus voor strings langer dan dit handhaaft het systeem een extra 'woordenboek'-bereik waar de waarden worden opgeslagen. Het kolom-extensiebestand slaat vervolgens een aanwijzer op in het woordenboek. Het is dus duurder om een varchar(8)-kolom te lezen en te verwerken dan bijvoorbeeld een char(8)-kolom. Dus waar mogelijk krijgt u betere prestaties als u kortere tekenreeksen kunt gebruiken, vooral als u het opzoeken in het woordenboek vermijdt. Alle TEXT/BLOB-gegevenstypen vanaf 1.1 gebruiken een woordenboek en zoeken indien nodig meerdere blokken van 8 KB om die gegevens op te halen. Hoe langer de gegevens, hoe meer blokken worden opgehaald en hoe groter de potentiële impact op de prestaties.
In een op rijen gebaseerd systeem verhoogt het toevoegen van redundante kolommen de totale querykosten, maar in een kolomsysteem worden alleen kosten gemaakt als naar de kolom wordt verwezen. Daarom moeten er extra kolommen worden gemaakt om verschillende toegangspaden te ondersteunen. Sla bijvoorbeeld een leidend gedeelte van een veld op in één kolom om snellere zoekopdrachten mogelijk te maken, maar sla ook de lange vormwaarde op als een andere kolom. Scans op een kortere code of voorlopende kolom gaan sneller.
Query-joins zijn geoptimaliseerd voor grootschalige joins en voorkomen de noodzaak van indexen en de overhead van geneste lusverwerking. ColumnStore houdt tabelstatistieken bij om de optimale joinvolgorde te bepalen. Soortgelijke benaderingen worden gedeeld met InnoDB, bijvoorbeeld als de join te groot is voor het UM-geheugen, het gebruikt op disk gebaseerde join om de query te voltooien.
Voor aggregaties distribueert ColumnStore zoveel mogelijk geaggregeerde evaluaties. Dit betekent dat het wordt gedeeld door de UM en PM om met name query's of een zeer groot aantal waarden in de geaggregeerde kolom(men) af te handelen. Select count(*) is intern geoptimaliseerd om het minste aantal bytes-opslag in een tabel te kiezen. Dit betekent dat het de CHAR(1)-kolom zou kiezen (gebruikt 1 byte) over de INT-kolom die 4 bytes in beslag neemt. De implementatie respecteert nog steeds de ANSI-semantiek in die zin dat select count(*) nulls in de totale count zal opnemen in plaats van een expliciete select (COL-N) die nulls uitsluit in de count.
Volgorde op en limiet worden momenteel helemaal aan het einde geïmplementeerd door het mariadb-serverproces in de tabel met tijdelijke resultaten. Dit is vermeld in stap #9 over hoe ColumnStore de query verwerkt. Dus technisch gezien worden de resultaten doorgegeven aan MariaDB Server voor het sorteren van de gegevens.
Voor complexe query's die subquery's gebruiken, is het in principe dezelfde aanpak die in volgorde wordt uitgevoerd en wordt beheerd door UM, hetzelfde als bij Window-functies die worden afgehandeld door UM, maar het gebruikt een speciaal sneller sorteerproces, dus het is in principe sneller.
Het partitioneren van uw gegevens wordt verzorgd door ColumnStore, dat gebruikmaakt van Extent Maps die de min/max-waarden van kolomgegevens handhaaft en een logisch bereik biedt voor partitionering en indexering overbodig maakt. Extent Maps biedt ook handmatige tabelpartitionering, gematerialiseerde weergaven, overzichtstabellen en andere structuren en objecten die op rijen gebaseerde databases moeten implementeren voor het uitvoeren van query's. Er zijn bepaalde voordelen voor waarden in kolommen wanneer ze in volgorde of semi-volgorde zijn, omdat dit een zeer effectieve gegevenspartitionering mogelijk maakt. Met min- en max-waarden worden volledige bereikkaarten na het filter en de uitsluiting geëlimineerd. Zie deze pagina in hun handleiding over mate van eliminatie. Dit werkt over het algemeen bijzonder goed voor tijdreeksgegevens of vergelijkbare waarden die in de loop van de tijd toenemen.
De MariaDB ColumnStore installeren
Het installeren van de MariaDB ColumnStore kan eenvoudig en duidelijk zijn. MariaDB heeft hier een reeks aantekeningen waarnaar u kunt verwijzen. Voor deze blog is onze installatiedoelomgeving CentOS 7. U kunt naar deze link https://downloads.mariadb.com/ColumnStore/1.2.4/ gaan en de pakketten bekijken op basis van uw OS-omgeving. Bekijk de gedetailleerde stappen hieronder om u te helpen versnellen:
### Note: The installation details is ideal for root user installation
cd /root/
wget https://downloads.mariadb.com/ColumnStore/1.2.4/centos/x86_64/7/mariadb-columnstore-1.2.4-1-centos7.x86_64.rpm.tar.gz
tar xzf mariadb-columnstore-1.0.7-1-centos7.x86_64.rpm.tar.gz
sudo yum -y install boost expect perl perl-DBI openssl zlib snappy libaio perl-DBD-MySQL net-tools wget jemalloc
sudo rpm -ivh mariadb-columnstore*.rpm
Als u klaar bent, moet u postConfigure . uitvoeren commando om eindelijk uw MariaDB ColumnStore te installeren en in te stellen. In deze voorbeeldinstallatie zijn er twee knooppunten die ik heb ingesteld op een zwervende machine:
csnode1:192.168.2.10
csnode2:192.168.2.20
Beide knooppunten zijn gedefinieerd in hun respectievelijke /etc/hosts en beide knooppunten zijn zo ingesteld dat de gebruikers- en prestatiemodules in beide hosts worden gecombineerd. De installatie is in het begin een beetje triviaal. Daarom delen we hoe u het kunt configureren, zodat u een basis kunt hebben. Zie de details hieronder voor het voorbeeldinstallatieproces:
[[email protected] ~]# /usr/local/mariadb/columnstore/bin/postConfigure -d
This is the MariaDB ColumnStore System Configuration and Installation tool.
It will Configure the MariaDB ColumnStore System and will perform a Package
Installation of all of the Servers within the System that is being configured.
IMPORTANT: This tool requires to run on the Performance Module #1
Prompting instructions:
Press 'enter' to accept a value in (), if available or
Enter one of the options within [], if available, or
Enter a new value
===== Setup System Server Type Configuration =====
There are 2 options when configuring the System Server Type: single and multi
'single' - Single-Server install is used when there will only be 1 server configured
on the system. It can also be used for production systems, if the plan is
to stay single-server.
'multi' - Multi-Server install is used when you want to configure multiple servers now or
in the future. With Multi-Server install, you can still configure just 1 server
now and add on addition servers/modules in the future.
Select the type of System Server install [1=single, 2=multi] (2) >
===== Setup System Module Type Configuration =====
There are 2 options when configuring the System Module Type: separate and combined
'separate' - User and Performance functionality on separate servers.
'combined' - User and Performance functionality on the same server
Select the type of System Module Install [1=separate, 2=combined] (1) > 2
Combined Server Installation will be performed.
The Server will be configured as a Performance Module.
All MariaDB ColumnStore Processes will run on the Performance Modules.
NOTE: The MariaDB ColumnStore Schema Sync feature will replicate all of the
schemas and InnoDB tables across the User Module nodes. This feature can be enabled
or disabled, for example, if you wish to configure your own replication post installation.
MariaDB ColumnStore Schema Sync feature, do you want to enable? [y,n] (y) >
NOTE: MariaDB ColumnStore Replication Feature is enabled
Enter System Name (columnstore-1) >
===== Setup Storage Configuration =====
----- Setup Performance Module DBRoot Data Storage Mount Configuration -----
There are 2 options when configuring the storage: internal or external
'internal' - This is specified when a local disk is used for the DBRoot storage.
High Availability Server Failover is not Supported in this mode
'external' - This is specified when the DBRoot directories are mounted.
High Availability Server Failover is Supported in this mode.
Select the type of Data Storage [1=internal, 2=external] (1) >
===== Setup Memory Configuration =====
NOTE: Setting 'NumBlocksPct' to 50%
Setting 'TotalUmMemory' to 25%
===== Setup the Module Configuration =====
----- Performance Module Configuration -----
Enter number of Performance Modules [1,1024] (1) > 2
*** Parent OAM Module Performance Module #1 Configuration ***
Enter Nic Interface #1 Host Name (csnode1) >
Enter Nic Interface #1 IP Address or hostname of csnode1 (unassigned) > 192.168.2.10
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm1' (1) >
*** Performance Module #2 Configuration ***
Enter Nic Interface #1 Host Name (unassigned) > csnode2
Enter Nic Interface #1 IP Address or hostname of csnode2 (192.168.2.20) >
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () > 2
===== Running the MariaDB ColumnStore MariaDB Server setup scripts =====
post-mysqld-install Successfully Completed
post-mysql-install Successfully Completed
Next step is to enter the password to access the other Servers.
This is either user password or you can default to using a ssh key
If using a user password, the password needs to be the same on all Servers.
Enter password, hit 'enter' to default to using a ssh key, or 'exit' >
===== System Installation =====
System Configuration is complete.
Performing System Installation.
Performing a MariaDB ColumnStore System install using RPM packages
located in the /root directory.
----- Performing Install on 'pm2 / csnode2' -----
Install log file is located here: /tmp/columnstore_tmp_files/pm2_rpm_install.log
MariaDB ColumnStore Package being installed, please wait ... DONE
===== Checking MariaDB ColumnStore System Logging Functionality =====
The MariaDB ColumnStore system logging is setup and working on local server
===== MariaDB ColumnStore System Startup =====
System Configuration is complete.
Performing System Installation.
----- Starting MariaDB ColumnStore on local server -----
MariaDB ColumnStore successfully started
MariaDB ColumnStore Database Platform Starting, please wait .......... DONE
System Catalog Successfully Created
Run MariaDB ColumnStore Replication Setup.. DONE
MariaDB ColumnStore Install Successfully Completed, System is Active
Enter the following command to define MariaDB ColumnStore Alias Commands
. /etc/profile.d/columnstoreAlias.sh
Enter 'mcsmysql' to access the MariaDB ColumnStore SQL console
Enter 'mcsadmin' to access the MariaDB ColumnStore Admin console
NOTE: The MariaDB ColumnStore Alias Commands are in /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]# . /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]#Zodra de installatie en configuratie is voltooid, zal MariaDB hiervoor een master/slave-configuratie maken, dus wat we ook van csnode1 hebben geladen, het zal worden gerepliceerd naar csnode2.
Uw big data dumpen
Na uw installatie heeft u mogelijk geen voorbeeldgegevens om te proberen. IMDB heeft voorbeeldgegevens gedeeld die u kunt downloaden op hun site https://www.imdb.com/interfaces/. Voor deze blog heb ik een script gemaakt dat alles voor je doet. Bekijk het hier https://github.com/paulnamuag/columnstore-imdb-data-load. Maak het gewoon uitvoerbaar en voer het script uit. Het zal alles voor u doen door de bestanden te downloaden, het schema te maken en vervolgens de gegevens in de database te laden. Zo simpel is het.
Uw voorbeeldquery's uitvoeren
Laten we nu eens wat voorbeeldquery's uitvoeren.
MariaDB [imdb]> select count(1), 'title_akas' table_name from title_akas union all select count(1), 'name_basics' as table_name from name_basics union all select count(1), 'title_crew' as table_name from title_crew union all select count(1), 'title_episode' as table_name from title_episode union all select count(1), 'title_ratings' as table_name from title_ratings order by 1 asc;
+----------+---------------+
| count(1) | table_name |
+----------+---------------+
| 945057 | title_ratings |
| 3797618 | title_akas |
| 4136880 | title_episode |
| 5953930 | title_crew |
| 9403540 | name_basics |
+----------+---------------+
5 rows in set (0.162 sec)MariaDB [imdb]> select count(*), 'title_akas' table_name from title_akas union all select count(*), 'name_basics' as table_name from name_basics union all select count(*), 'title_crew' as table_name from title_crew union all select count(*), 'title_episode' as table_name from title_episode union all select count(*), 'title_ratings' as table_name from title_ratings order by 2;
+----------+---------------+
| count(*) | table_name |
+----------+---------------+
| 9405192 | name_basics |
| 3797618 | title_akas |
| 5953930 | title_crew |
| 4136880 | title_episode |
| 945057 | title_ratings |
+----------+---------------+
5 rows in set (0.371 sec)Kortom, het is sneller en sneller. Er zijn query's die u niet op dezelfde manier kunt verwerken als bij andere storage-engines, zoals InnoDB. Ik heb bijvoorbeeld geprobeerd wat te spelen en een paar dwaze vragen te stellen en te kijken hoe het reageert en het resulteert in:
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select a.titleId from title_akas) limit 25;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'title_akas' are not joined.Daarom vond ik MCOL-1620 en MCOL-131 en dit wijst op het instellen van de variabele infinidb_vtable_mode. Zie hieronder:
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'b, sub-query' are not joined.Maar het instellen van infinidb_vtable_mode=0 , wat betekent dat het de query behandelt als een generieke en zeer compatibele rij-voor-rij verwerkingsmodus. Sommige componenten van de WHERE-component kunnen worden verwerkt door ColumnStore, maar joins worden volledig verwerkt door mysqld met behulp van een geneste-lus-joinmechanisme. Zie hieronder:
MariaDB [imdb]> set infinidb_vtable_mode=0;
Query OK, 0 rows affected (0.000 sec)MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
+-----------+---------------+--------+-----------+-------------+---------------+
| titleId | title | region | id | primaryName | profession |
+-----------+---------------+--------+-----------+-------------+---------------+
| tt0082880 | Vaticano Show | ES | nm0594213 | Velda Mitzi | miscellaneous |
| tt0082880 | Il pap'occhio | IT | nm0594213 | Velda Mitzi | miscellaneous |
+-----------+---------------+--------+-----------+-------------+---------------+
2 rows in set (13.789 sec)Het duurde echter enige tijd omdat het uitlegt dat het volledig door mysqld is verwerkt. Toch blijft het optimaliseren en schrijven van goede queries de beste aanpak en niet alles delegeren aan ColumnStore.
Daarnaast heb je wat hulp bij het analyseren van je zoekopdrachten door commando's uit te voeren zoals SELECT calSetTrace(1); of SELECTEER calGetStats(); . U kunt deze reeks opdrachten gebruiken om bijvoorbeeld de lage en slechte query's te optimaliseren of het queryplan te bekijken. Bekijk het hier voor meer details over het analyseren van de zoekopdrachten.
ColumnStore beheren
Zodra u MariaDB ColumnStore volledig hebt ingesteld, wordt het geleverd met het hulpprogramma mcsadmin, waarvoor u enkele administratieve taken kunt uitvoeren. Je kunt deze tool ook gebruiken om een andere module toe te voegen, toe te wijzen of te verplaatsen naar DBroots van PM naar PM, enz. Bekijk hun handleiding over deze tool.
In principe kunt u het volgende doen, bijvoorbeeld de systeeminformatie controleren:
mcsadmin> getSystemi
getsysteminfo Mon Jun 24 12:55:25 2019
System columnstore-1
System and Module statuses
Component Status Last Status Change
------------ -------------------------- ------------------------
System ACTIVE Fri Jun 21 21:40:56 2019
Module pm1 ACTIVE Fri Jun 21 21:40:54 2019
Module pm2 ACTIVE Fri Jun 21 21:40:50 2019
Active Parent OAM Performance Module is 'pm1'
Primary Front-End MariaDB ColumnStore Module is 'pm1'
MariaDB ColumnStore Replication Feature is enabled
MariaDB ColumnStore set for Distributed Install
MariaDB ColumnStore Process statuses
Process Module Status Last Status Change Process ID
------------------ ------ --------------- ------------------------ ----------
ProcessMonitor pm1 ACTIVE Thu Jun 20 17:36:27 2019 6026
ProcessManager pm1 ACTIVE Thu Jun 20 17:36:33 2019 6165
DBRMControllerNode pm1 ACTIVE Fri Jun 21 21:40:31 2019 19890
ServerMonitor pm1 ACTIVE Fri Jun 21 21:40:33 2019 19955
DBRMWorkerNode pm1 ACTIVE Fri Jun 21 21:40:33 2019 20003
PrimProc pm1 ACTIVE Fri Jun 21 21:40:37 2019 20137
ExeMgr pm1 ACTIVE Fri Jun 21 21:40:42 2019 20541
WriteEngineServer pm1 ACTIVE Fri Jun 21 21:40:47 2019 20660
DDLProc pm1 ACTIVE Fri Jun 21 21:40:51 2019 20810
DMLProc pm1 ACTIVE Fri Jun 21 21:40:55 2019 20956
mysqld pm1 ACTIVE Fri Jun 21 21:40:41 2019 19778
ProcessMonitor pm2 ACTIVE Thu Jun 20 17:37:16 2019 9728
ProcessManager pm2 HOT_STANDBY Fri Jun 21 21:40:26 2019 25211
DBRMControllerNode pm2 COLD_STANDBY Fri Jun 21 21:40:32 2019
ServerMonitor pm2 ACTIVE Fri Jun 21 21:40:35 2019 25560
DBRMWorkerNode pm2 ACTIVE Fri Jun 21 21:40:36 2019 25593
PrimProc pm2 ACTIVE Fri Jun 21 21:40:40 2019 25642
ExeMgr pm2 ACTIVE Fri Jun 21 21:40:44 2019 25715
WriteEngineServer pm2 ACTIVE Fri Jun 21 21:40:48 2019 25768
DDLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
DMLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
mysqld pm2 ACTIVE Fri Jun 21 21:40:32 2019 25467
Active Alarm Counts: Critical = 1, Major = 0, Minor = 0, Warning = 0, Info = 0Conclusie
MariaDB ColumnStore is een zeer krachtige opslagengine voor uw OLAP- en big data-verwerking. Dit is volledig open source, wat zeer voordelig is om te gebruiken dan het gebruik van propriëtaire en dure OLAP-databases die op de markt verkrijgbaar zijn. Toch zijn er andere alternatieven om te proberen, zoals ClickHouse, Apache HBase of cstore_fdw van Citus Data. Geen van beide gebruikt echter MySQL/MariaDB, dus het is misschien niet uw haalbare optie als u ervoor kiest om de MySQL/MariaDB-varianten te behouden.