Типичният MySQL DBA може да е запознат с работата и управлението на OLTP (онлайн обработка на транзакции) база данни като част от ежедневната им рутина. Може да сте запознати с това как работи и как да управлявате сложни операции. Макар че механизмът за съхранение по подразбиране, който MySQL доставя, е достатъчно добър за OLAP (онлайн аналитична обработка), той е доста опростен, особено тези, които искат да научат изкуствен интелект или които се занимават с прогнозиране, извличане на данни, анализ на данни.
В този блог ще обсъдим MariaDB ColumnStore. Съдържанието ще бъде пригодено в полза на MySQL DBA, който може да има по-малко разбиране за ColumnStore и как то може да бъде приложимо за OLAP (онлайн аналитична обработка) приложения.
OLTP срещу OLAP
OLTP
Свързани ресурси Аналитика с MariaDB AX – колонното хранилище с отворен код Въведение в базите данни от времеви серии Хибридни работни натоварвания на OLTP/база данни за анализ в клъстер Galera с помощта на асинхронни подчинени устройстваТипичната MySQL DBA дейност за работа с този тип данни е чрез използване на OLTP (Онлайн обработка на транзакции). OLTP се характеризира с големи транзакции на база данни, извършващи вмъквания, актуализации или изтривания. Базите данни от типа OLTP са специализирани за бърза обработка на заявки и поддържане на целостта на данните, докато са достъпни в множество среди. Ефективността му се измерва с броя на транзакциите в секунда (tps). Доста обичайно е таблиците за връзки родител-подчинение (след прилагане на формуляра за нормализиране) да намаляват излишните данни в таблица.
Записите в таблица обикновено се обработват и съхраняват последователно по редово ориентиран начин и са силно индексирани с уникални ключове за оптимизиране на извличането или записването на данни. Това също е обичайно за MySQL, особено когато се работи с големи вмъквания или много едновременни записи или групови вмъквания. Повечето от механизмите за съхранение, които MariaDB поддържа, са приложими за OLTP приложения - InnoDB (машина за съхранение по подразбиране от 10.2), XtraDB, TokuDB, MyRocks или MyISAM/Aria.
Приложения като CMS, FinTech, уеб приложения често се справят с тежки записи и четения и често изискват висока пропускателна способност. За да накарате тези приложения да работят, често е необходим дълбок опит в областта на високата наличност, резервирането, устойчивостта и възстановяването.
OLAP
OLAP се справя със същите предизвикателства като OLTP, но използва различен подход (особено когато се занимава с извличане на данни). OLAP се занимава с по-големи набори от данни и е често срещан за съхранение на данни, често използван за приложения от типа на бизнес разузнаването. Обикновено се използва за управление на бизнес ефективността, планиране, бюджетиране, прогнозиране, финансово отчитане, анализ, симулационни модели, откриване на знания и отчитане в хранилището на данни.
Данните, които се съхраняват в OLAP, обикновено не са толкова критични, колкото тези, съхранявани в OLTP. Това е така, защото повечето от данните могат да бъдат симулирани, идващи от OLTP и след това могат да се подават към вашата OLAP база данни. Тези данни обикновено се използват за групово зареждане, често необходими за бизнес анализи, които в крайна сметка се изобразяват във визуални графики. OLAP също така извършва многоизмерен анализ на бизнес данни и предоставя резултати, които могат да се използват за сложни изчисления, анализ на тенденциите или сложно моделиране на данни.
OLAP обикновено съхранява данни постоянно, използвайки колонен формат. В MariaDB ColumnStore обаче записите са разбити въз основа на неговите колони и се съхраняват отделно във файл. По този начин извличането на данни е много ефективно, тъй като сканира само съответната колона, посочена във вашата заявка за SELECT.
Мислете за това така, OLTP обработката обработва вашите ежедневни и важни транзакции с данни, които изпълняват вашето бизнес приложение, докато OLAP ви помага да управлявате, прогнозирате, анализирате и по-добре предлагате на пазара вашия продукт – градивните елементи за наличието на бизнес приложение.
Какво е MariaDB ColumnStore?
MariaDB ColumnStore е плъзгаща се колонна машина за съхранение, която работи на MariaDB Server. Той използва паралелно разпределена архитектура на данни, като същевременно запазва същия ANSI SQL интерфейс, който се използва в портфолиото на сървърите на MariaDB. Този двигател за съхранение съществува от известно време, тъй като първоначално беше пренесен от InfiniDB (Вече несъществуващ код, който все още е наличен в github.) Той е предназначен за мащабиране на големи данни (за обработка на петабайти данни), линейна мащабируемост и реални -време за отговор на аналитични запитвания. Той използва I/O предимствата на колонното съхранение; компресия, прожекция точно навреме и хоризонтално и вертикално разделяне за осигуряване на огромна производителност при анализиране на големи набори от данни.
И накрая, MariaDB ColumnStore е гръбнакът на техния продукт MariaDB AX като основен двигател за съхранение, използван от тази технология.
По какво се различава MariaDB ColumnStore от InnoDB?
InnoDB е приложим за OLTP обработка, която изисква вашето приложение да реагира по възможно най-бързия начин. Полезно е, ако приложението ви се занимава с това естество. От друга страна, MariaDB ColumnStore е подходящ избор за управление на транзакции с големи данни или големи набори от данни, което включва сложни обединявания, агрегиране на различни нива на йерархия на измерения, прогнозиране на финансова сума за широк диапазон от години или използване на избор на равенство и диапазон . Тези подходи, използващи ColumnStore, не изискват от вас да индексирате тези полета, тъй като може да работи достатъчно по-бързо. InnoDB наистина не може да се справи с този тип производителност, въпреки че не ви пречи да опитате това, както е възможно с InnoDB, но на цена. Това изисква от вас да добавите индекси, което добавя големи количества данни към вашето дисково хранилище. Това означава, че може да отнеме повече време, за да завърши заявката ви, и може изобщо да не завърши, ако е уловена във времеви цикъл.
Архитектура на MariaDB ColumnStore
Нека разгледаме архитектурата на MariaDB ColumStore по-долу:
Изображение с любезното съдействие на презентацията на MariaDB ColumnStore За разлика от архитектурата InnoDB, ColumnStore съдържа два модула, което означава, че намерението му е да работи ефективно в разпределена архитектурна среда. InnoDB е предназначен за мащабиране на сървър, но обхваща множество взаимосвързани възли в зависимост от настройката на клъстера. Следователно ColumnStore има множество нива на компоненти, които се грижат за процесите, заявени към сървъра MariaDB. Нека разгледаме тези компоненти по-долу:
- Потребителски модул (UM):UM е отговорен за анализирането на SQL заявките в оптимизиран набор от примитивни стъпки на заданието, изпълнявани от един или повече PM сървъри. По този начин UM отговаря за оптимизирането на заявките и оркестрирането на изпълнението на заявки от PM сървърите. Докато множество екземпляри на UM могат да бъдат разгърнати при внедряване на няколко сървъра, една UM отговаря за всяка отделна заявка. Балансьор на натоварване на базата данни, като MariaDB MaxScale, може да бъде разгърнат за подходящо балансиране на външни заявки спрямо отделни UM сървъри.
- Модул за производителност (PM):PM изпълнява детайлни стъпки на заданието, получени от UM по многонишков начин. ColumnStore позволява разпределение на работата между много модули за производителност. UM се състои от процеса MariaDB mysqld и процеса ExeMgr.
- Карти на обхвата:ColumnStore поддържа метаданни за всяка колона в споделен разпределен обект, известен като карта на обхвата. Сървърът на UM препраща към картата на обхвата, за да помогне при генерирането на правилните примитивни стъпки на заданието. PM сървърът препраща към картата на обхвата, за да идентифицира правилните дискови блокове за четене. Всяка колона е съставена от един или повече файлове и всеки файл може да съдържа множество екстенти. Доколкото е възможно, системата се опитва да разпредели непрекъснато физическо съхранение, за да подобри производителността на четене.
- Съхранение:ColumnStore може да използва локално хранилище или споделено хранилище (напр. SAN или EBS) за съхраняване на данни. Използването на споделено съхранение позволява обработката на данни да се прехвърля автоматично към друг възел в случай на повреда на PM сървър.
По-долу е показано как MariaDB ColumnStore обработва заявката,
- Клиентите изпращат заявка към сървъра на MariaDB, работещ на потребителския модул. Сървърът изпълнява таблична операция за всички таблици, необходими за изпълнение на заявката, и получава първоначалния план за изпълнение на заявката.
- Използвайки интерфейса на механизма за съхранение на MariaDB, ColumnStore преобразува обекта на таблица на сървъра в обекти на ColumnStore. След това тези обекти се изпращат до процесите на потребителския модул.
- Потребителският модул преобразува плана за изпълнение на MariaDB и оптимизира дадените обекти в план за изпълнение на ColumnStore. След това определя стъпките, необходими за изпълнение на заявката и реда, в който те трябва да бъдат изпълнени.
- След това потребителският модул се консултира с картата на обхвата, за да определи кои модули на производителността да се консултира за данните, от които се нуждае, след това извършва елиминиране на обхвата, елиминирайки всички модули за производителност от списъка, които съдържат само данни извън обхвата на това, което изисква заявката.
- След това потребителският модул изпраща команди до един или повече модули за производителност за извършване на блокови I/O операции.
- Модулът за производителност или модулите извършват филтриране на предикати, обработка на присъединяване, първоначално агрегиране на данни от локално или външно хранилище, след което изпращат данните обратно към потребителския модул.
- Потребителският модул извършва окончателното агрегиране на набора от резултати и съставя набора от резултати за заявката.
- Потребителският модул / ExeMgr изпълнява всички изчисления на функцията на прозореца, както и всяко необходимо сортиране на набора от резултати. След това връща набора от резултати на сървъра.
- Сървърът MariaDB изпълнява всякакви функции за избор на списък, операции ORDER BY и LIMIT върху набора от резултати.
- Сървърът MariaDB връща набора от резултати на клиента.
Парадигми за изпълнение на заявка
Нека разгледаме малко повече как ColumnStore изпълнява заявката и кога оказва влияние.
ColumnStore се различава от стандартните системи за съхранение на MySQL/MariaDB като InnoDB, тъй като ColumnStore печели производителност само чрез сканиране на необходимите колони, използване на поддържано от системата разделяне и използване на множество нишки и сървъри за мащабиране на времето за отговор на заявката. Производителността е от полза, когато включвате само колони, които са необходими за извличането на данни. Това означава, че алчната звездичка (*) във вашата заявка за избор има значително влияние в сравнение с SELECT
Както при InnoDB и други машини за съхранение, типът на данните също има значение за производителността на това, което сте използвали. Ако кажем, че имате колона, която може да има само стойности от 0 до 100, тогава декларирайте това като tinyint, тъй като това ще бъде представено с 1 байт, а не с 4 байта за int. Това ще намали разходите за I/O с 4 пъти. За типовете низ важен праг е char(9) и varchar(8) или по-висок. Всеки файл за съхранение на колона използва фиксиран брой байтове на стойност. Това позволява бързо позиционно търсене на други колони за формиране на реда. В момента горната граница за колонно съхранение на данни е 8 байта. Така че за низове, по-дълги от това, системата поддържа допълнителен 'речник' степен, където се съхраняват стойностите. След това колонният файл за екстент съхранява указател в речника. Така че е по-скъпо да се чете и обработва колона varchar(8) отколкото колона char(8) например. Така че, където е възможно, ще получите по-добра производителност, ако можете да използвате по-къси низове, особено ако избягвате търсенето в речника. Всички типове данни TEXT/BLOB в 1.1 по-нататък използват речник и извършват търсене на множество блокове от 8KB, за да извлекат тези данни, ако е необходимо, колкото по-дълго са данните, толкова повече блокове се извличат и толкова по-голямо е потенциалното въздействие върху производителността.
В система, базирана на редове, добавянето на излишни колони добавя към общата цена на заявката, но в колонна система разходът се появява само ако колоната е препратка. Следователно трябва да се създадат допълнителни колони, които да поддържат различни пътища за достъп. Например съхранявайте водеща част от поле в една колона, за да позволите по-бързо търсене, но допълнително съхранявайте стойността на дългия формуляр като друга колона. Сканирането на по-кратък код или колона с водеща част ще бъде по-бързо.
Съединяванията на заявки са оптимизирани и са готови за обединения в голям мащаб и избягват нуждата от индекси и режийните разходи за обработка на вложен цикъл. ColumnStore поддържа статистика на таблицата, за да определи оптималния ред на присъединяване. Подобни подходи се споделят с InnoDB, например, ако присъединяването е твърде голямо за UM паметта, то използва базирано на диск присъединяване, за да завърши заявката.
За агрегирания ColumnStore разпределя обобщената оценка колкото е възможно повече. Това означава, че споделя в UM и PM, за да обработва заявки, особено или много голям брой стойности в обобщената колона(и). Избор на брой (*) е вътрешно оптимизиран за избор на най-малък брой байтове за съхранение в таблица. Това означава, че ще избере колона CHAR(1) (използва 1 байт) над колоната INT, която отнема 4 байта. Реализацията все още спазва семантиката на ANSI, тъй като избраният брой(*) ще включва нулеви стойности в общия брой, за разлика от изричния избор (COL-N), който изключва нулеви стойности в броя.
Ред по и ограничение в момента се изпълняват в самия край от процеса на сървъра mariadb на таблицата с временни резултати. Това беше споменато в стъпка #9 за това как ColumnStore обработва заявката. Така че технически резултатите се предават на MariaDB Server за сортиране на данните.
За сложни заявки, които използват подзаявки, това е основно същият подход, при който се изпълняват последователно и се управляват от UM, както и с функциите на прозореца, които се обработват от UM, но използва специален по-бърз процес на сортиране, така че е основно по-бърз.
Разделянето на вашите данни се осигурява от ColumnStore, който използва карти на обхвата, които поддържат мин./максималните стойности на данните в колоните и осигуряват логически диапазон за разделяне и премахват необходимостта от индексиране. Extent Maps също така предоставя ръчно разделяне на таблици, материализирани изгледи, обобщени таблици и други структури и обекти, които базираните на редове бази данни трябва да прилагат за изпълнение на заявката. Има определени предимства за стойностите с колони, когато са в ред или полу-ред, тъй като това позволява много ефективно разделяне на данни. С минимални и максимални стойности, целите карти на екстент след филтъра и изключването ще бъдат елиминирани. Вижте тази страница в тяхното ръководство за елиминиране на обхват. Това обикновено работи особено добре за данни от времеви серии или подобни стойности, които се увеличават с времето.
Инсталиране на MariaDB ColumnStore
Инсталирането на MariaDB ColumnStore може да бъде просто и лесно. MariaDB има серия от бележки тук, на които можете да се обърнете. За този блог нашата целева среда за инсталиране е CentOS 7. Можете да отидете на тази връзка https://downloads.mariadb.com/ColumnStore/1.2.4/ и да разгледате пакетите, базирани на вашата ОС среда. Вижте подробните стъпки по-долу, за да ви помогнат да ускорите:
### 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
След като приключите, трябва да стартирате postConfigure команда, за да инсталирате и настроите най-накрая вашия MariaDB ColumnStore. В тази примерна инсталация има два възела, които имам настройка, работещи на скитни машини:
csnode1:192.168.2.10
csnode2:192.168.2.20
И двата възела са дефинирани в съответните им /etc/hosts и двата възела са насочени да имат своите потребителски и производителни модули, комбинирани в двата хоста. Инсталацията в началото е малко тривиална. Следователно ние споделяме как можете да го конфигурирате, така че да имате основа. Вижте подробностите по-долу за примерния процес на инсталиране:
[[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] ~]#След като инсталацията и настройката бъдат извършени, MariaDB ще създаде главна/подчинена настройка за това, така че каквото и да сме заредили от csnode1, то ще бъде репликирано в csnode2.
Изхвърляне на вашите големи данни
След инсталацията може да нямате примерни данни, които да опитате. IMDB сподели примерни данни, които можете да изтеглите на техния сайт https://www.imdb.com/interfaces/. За този блог създадох скрипт, който прави всичко вместо вас. Вижте го тук https://github.com/paulnamuag/columnstore-imdb-data-load. Просто го направете изпълним, след което стартирайте скрипта. Той ще направи всичко вместо вас, като изтегли файловете, създаде схемата и след това зареди данни в базата данни. Това е просто.
Изпълнение на вашите примерни заявки
Сега нека опитаме да изпълним някои примерни заявки.
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)По принцип става по-бързо и бързо. Има заявки, които не можете да обработите, както изпълнявате с други машини за съхранение, като InnoDB. Например, опитах се да си поиграя и да направя някои глупави запитвания и да видя как реагира и това води до:
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.Следователно открих MCOL-1620 и MCOL-131 и сочи към настройка на променлива infinidb_vtable_mode. Вижте по-долу:
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.Но настройка infinidb_vtable_mode=0 , което означава, че третира заявката като общ и много съвместим режим на обработка ред по ред. Някои компоненти на клаузата WHERE могат да бъдат обработени от ColumnStore, но присъединяванията се обработват изцяло от mysqld, използвайки механизъм за присъединяване с вложен цикъл. Вижте по-долу:
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)Отне известно време обаче, тъй като обяснява, че е обработен изцяло от mysqld. Все пак оптимизирането и писането на добри заявки все още е най-добрият подход и не делегирайте всичко на ColumnStore.
Освен това имате някаква помощ за анализиране на вашите заявки, като изпълните команди като SELECT calSetTrace(1); или SELECT calGetStats(); . Можете да използвате този набор от команди, например, да оптимизирате ниските и лошите заявки или да видите неговия план за заявки. Вижте го тук за повече подробности относно анализирането на заявките.
Администриране на ColumnStore
След като сте настроили напълно MariaDB ColumnStore, той се доставя с неговия инструмент на име mcsadmin, за който можете да използвате, за да изпълнявате някои административни задачи. Можете също да използвате този инструмент, за да добавите друг модул, да присвоите или преместите в DBroots от PM до PM и т.н. Вижте ръководството им за този инструмент.
По принцип можете да направите следното, например, като проверите системната информация:
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 = 0Заключение
MariaDB ColumnStore е много мощен двигател за съхранение за вашия OLAP и обработка на големи данни. Това е изцяло отворен код, който е много изгоден за използване от използването на собствени и скъпи OLAP бази данни, налични на пазара. И все пак има други алтернативи, които да опитате, като ClickHouse, Apache HBase или cstore_fdw на Citus Data. Нито едно от тях обаче не използва MySQL/MariaDB, така че може да не е вашата жизнеспособна опция, ако решите да се придържате към вариантите на MySQL/MariaDB.
