DBA MySQL yang khas mungkin sudah familiar bekerja dan mengelola database OLTP (Online Transaction Processing) sebagai bagian dari rutinitas harian mereka. Anda mungkin akrab dengan cara kerjanya dan cara mengelola operasi yang kompleks. Meskipun mesin penyimpanan default yang dikirimkan MySQL cukup baik untuk OLAP (Online Analytical Processing), ini cukup sederhana, terutama bagi mereka yang ingin mempelajari kecerdasan buatan atau yang berurusan dengan peramalan, penambangan data, analitik data.
Di blog ini, kita akan membahas MariaDB ColumnStore. Konten akan disesuaikan untuk kepentingan DBA MySQL yang mungkin kurang memahami ColumnStore dan bagaimana hal itu dapat diterapkan untuk aplikasi OLAP (Online Analytical Processing).
OLTP vs OLAP
OLTP
Resource terkait Analytics dengan MariaDB AX - Open Source Columnar Datastore Pengantar Time Series Databases Hibrid OLTP/Analytics Database Beban Kerja di Galera Cluster Menggunakan Asynchronous SlaveAktivitas DBA MySQL yang khas untuk menangani jenis data ini adalah dengan menggunakan OLTP (Pemrosesan Transaksi Online). OLTP dicirikan oleh transaksi basis data besar yang melakukan penyisipan, pembaruan, atau penghapusan. Basis data tipe OLTP dikhususkan untuk pemrosesan kueri yang cepat dan menjaga integritas data saat diakses di berbagai lingkungan. Efektivitasnya diukur dengan jumlah transaksi per detik (tps). Cukup umum untuk tabel hubungan induk-anak (setelah implementasi bentuk normalisasi) untuk mengurangi data yang berlebihan dalam sebuah tabel.
Catatan dalam tabel biasanya diproses dan disimpan secara berurutan dengan cara berorientasi baris dan sangat diindeks dengan kunci unik untuk mengoptimalkan pengambilan atau penulisan data. Ini juga umum untuk MySQL, terutama ketika berhadapan dengan sisipan besar atau penulisan bersamaan yang tinggi atau sisipan massal. Sebagian besar mesin penyimpanan yang didukung MariaDB berlaku untuk aplikasi OLTP - InnoDB (mesin penyimpanan default sejak 10.2), XtraDB, TokuDB, MyRocks, atau MyISAM/Aria.
Aplikasi seperti CMS, FinTech, Web Apps sering berurusan dengan penulisan dan pembacaan yang berat dan seringkali membutuhkan throughput yang tinggi. Untuk membuat aplikasi ini berfungsi, seringkali dibutuhkan keahlian mendalam dalam ketersediaan tinggi, redundansi, ketahanan, dan pemulihan.
OLAP
OLAP menangani tantangan yang sama seperti OLTP, tetapi menggunakan pendekatan yang berbeda (terutama ketika berhadapan dengan pengambilan data.) OLAP menangani kumpulan data yang lebih besar dan umum untuk penyimpanan data, sering digunakan untuk jenis aplikasi intelijen bisnis. Ini biasanya digunakan untuk Manajemen Kinerja Bisnis, Perencanaan, Penganggaran, Peramalan, Pelaporan Keuangan, Analisis, Model Simulasi, Penemuan Pengetahuan, dan Pelaporan Gudang Data.
Data yang disimpan di OLAP biasanya tidak sepenting yang disimpan di OLTP. Ini karena sebagian besar data yang dapat disimulasikan berasal dari OLTP dan kemudian dapat diumpankan ke database OLAP Anda. Data ini biasanya digunakan untuk pemuatan massal, sering kali diperlukan untuk analitik bisnis yang akhirnya dirender menjadi grafik visual. OLAP juga melakukan analisis multidimensi data bisnis dan memberikan hasil yang dapat digunakan untuk perhitungan kompleks, analisis tren, atau pemodelan data yang canggih.
OLAP biasanya menyimpan data secara persisten menggunakan format kolom. Namun, di MariaDB ColumnStore, catatan dipecah berdasarkan kolomnya dan disimpan secara terpisah ke dalam file. Dengan cara ini pengambilan data sangat efisien, karena hanya memindai kolom yang relevan yang dirujuk dalam kueri pernyataan SELECT Anda.
Anggap saja seperti ini, pemrosesan OLTP menangani transaksi data harian dan penting Anda yang menjalankan aplikasi bisnis Anda, sementara OLAP membantu Anda mengelola, memprediksi, menganalisis, dan memasarkan produk Anda dengan lebih baik - dasar dari memiliki aplikasi bisnis.
Apa itu MariaDB ColumnStore?
MariaDB ColumnStore adalah mesin penyimpanan kolumnar pluggable yang berjalan di MariaDB Server. Ini menggunakan arsitektur data terdistribusi paralel sambil menjaga antarmuka ANSI SQL yang sama yang digunakan di seluruh portofolio server MariaDB. Mesin penyimpanan ini telah ada untuk sementara waktu, karena awalnya di-porting dari InfiniDB (Kode yang sekarang tidak berfungsi yang masih tersedia di github.) Ini dirancang untuk penskalaan data besar (untuk memproses petabyte data), skalabilitas linier, dan real -waktu respons terhadap kueri analitik. Ini memanfaatkan manfaat I/O dari penyimpanan kolom; kompresi, proyeksi tepat waktu, dan partisi horizontal &vertikal untuk menghadirkan kinerja luar biasa saat menganalisis kumpulan data besar.
Terakhir, MariaDB ColumnStore adalah tulang punggung produk MariaDB AX mereka sebagai mesin penyimpanan utama yang digunakan oleh teknologi ini.
Bagaimana MariaDB ColumnStore Berbeda Dari InnoDB?
InnoDB berlaku untuk pemrosesan OLTP yang mengharuskan aplikasi Anda merespons secepat mungkin. Ini berguna jika aplikasi Anda berurusan dengan sifat itu. Di sisi lain, MariaDB ColumnStore adalah pilihan yang cocok untuk mengelola transaksi data besar atau kumpulan data besar yang melibatkan penggabungan kompleks, agregasi pada tingkat hierarki dimensi yang berbeda, memproyeksikan total keuangan untuk berbagai tahun, atau menggunakan kesetaraan dan pilihan rentang . Pendekatan ini menggunakan ColumnStore tidak mengharuskan Anda untuk mengindeks bidang ini, karena dapat bekerja lebih cepat. InnoDB tidak dapat benar-benar menangani jenis kinerja ini, meskipun tidak ada yang menghentikan Anda untuk mencobanya seperti yang dapat dilakukan dengan InnoDB, tetapi dengan biaya. Ini mengharuskan Anda untuk menambahkan indeks, yang menambahkan sejumlah besar data ke penyimpanan disk Anda. Ini berarti diperlukan lebih banyak waktu untuk menyelesaikan kueri Anda, dan mungkin tidak akan selesai sama sekali jika terjebak dalam loop waktu.
Arsitektur MariaDB ColumnStore
Mari kita lihat arsitektur MariaDB ColumStore di bawah ini:
Gambar Atas perkenan MariaDB ColumnStore presentasi Berbeda dengan arsitektur InnoDB, ColumnStore berisi dua modul yang menunjukkan tujuannya adalah untuk bekerja secara efisien pada lingkungan arsitektur terdistribusi. InnoDB dimaksudkan untuk skala pada server, tetapi mencakup beberapa node yang saling terhubung tergantung pada pengaturan cluster. Oleh karena itu, ColumnStore memiliki beberapa level komponen yang menangani proses yang diminta ke Server MariaDB. Mari kita gali komponen ini di bawah ini:
- Modul Pengguna (UM):UM bertanggung jawab untuk menguraikan permintaan SQL ke dalam serangkaian langkah tugas primitif yang dioptimalkan yang dijalankan oleh satu atau beberapa server PM. UM dengan demikian bertanggung jawab untuk optimasi query dan orkestrasi eksekusi query oleh server PM. Sementara beberapa instans UM dapat digunakan dalam penerapan multi-server, satu UM bertanggung jawab untuk setiap kueri individu. Load balancer database, seperti MariaDB MaxScale, dapat diterapkan untuk menyeimbangkan permintaan eksternal dengan server UM individual dengan tepat.
- Modul Kinerja (PM):PM menjalankan langkah-langkah pekerjaan granular yang diterima dari UM dengan cara multi-utas. ColumnStore memungkinkan distribusi pekerjaan di banyak Modul Kinerja. UM terdiri dari proses mysqld MariaDB dan proses ExeMgr.
- Peta Luas:ColumnStore memelihara metadata tentang setiap kolom dalam objek terdistribusi bersama yang dikenal sebagai Peta Luas Server UM merujuk Peta Luas untuk membantu membantu menghasilkan langkah-langkah pekerjaan primitif yang benar. Server PM mereferensikan Peta Luas untuk mengidentifikasi blok disk yang benar untuk dibaca. Setiap kolom terdiri dari satu atau lebih file dan setiap file dapat berisi beberapa ekstensi. Sebisa mungkin sistem mencoba mengalokasikan penyimpanan fisik yang berdekatan untuk meningkatkan kinerja membaca.
- Penyimpanan:ColumnStore dapat menggunakan penyimpanan lokal atau penyimpanan bersama (misalnya SAN atau EBS) untuk menyimpan data. Menggunakan penyimpanan bersama memungkinkan pemrosesan data gagal ke node lain secara otomatis jika server PM gagal.
Di bawah ini adalah cara MariaDB ColumnStore memproses kueri,
- Klien mengeluarkan kueri ke Server MariaDB yang berjalan di Modul Pengguna. Server melakukan operasi tabel untuk semua tabel yang diperlukan untuk memenuhi permintaan dan memperoleh rencana eksekusi kueri awal.
- Menggunakan antarmuka mesin penyimpanan MariaDB, ColumnStore mengonversi objek tabel server menjadi objek ColumnStore. Objek ini kemudian dikirim ke proses Modul Pengguna.
- Modul Pengguna mengonversi rencana eksekusi MariaDB dan mengoptimalkan objek yang diberikan menjadi rencana eksekusi ColumnStore. Kemudian menentukan langkah-langkah yang diperlukan untuk menjalankan kueri dan urutan yang harus dijalankan.
- Modul Pengguna kemudian berkonsultasi dengan Peta Luas untuk menentukan Modul Kinerja mana yang akan dikonsultasikan untuk data yang dibutuhkan, kemudian melakukan Penghapusan Luas, menghilangkan Modul Kinerja apa pun dari daftar yang hanya berisi data di luar rentang yang diperlukan kueri.
- Modul Pengguna kemudian mengirimkan perintah ke satu atau lebih Modul Kinerja untuk melakukan operasi blok I/O.
- Modul atau Modul Kinerja melakukan penyaringan predikat, pemrosesan gabungan, agregasi awal data dari penyimpanan lokal atau eksternal, kemudian mengirim data kembali ke Modul Pengguna.
- Modul Pengguna melakukan agregasi kumpulan hasil akhir dan menyusun kumpulan hasil untuk kueri.
- Modul Pengguna / ExeMgr mengimplementasikan perhitungan fungsi jendela apa pun, serta pengurutan yang diperlukan pada kumpulan hasil. Kemudian mengembalikan hasil-set ke server.
- Server MariaDB melakukan fungsi daftar pilihan, ORDER BY dan operasi LIMIT pada kumpulan hasil.
- Server MariaDB mengembalikan kumpulan hasil ke klien.
Paradigma Eksekusi Kueri
Mari kita gali lebih jauh bagaimana ColumnStore mengeksekusi kueri dan kapan dampaknya.
ColumnStore berbeda dengan mesin penyimpanan MySQL/MariaDB standar seperti InnoDB karena ColumnStore memperoleh kinerja dengan hanya memindai kolom yang diperlukan, memanfaatkan partisi yang dipelihara sistem, dan memanfaatkan beberapa utas dan server untuk menskalakan waktu respons kueri. Kinerja diuntungkan bila Anda hanya menyertakan kolom yang diperlukan untuk pengambilan data Anda. Ini berarti bahwa tanda bintang serakah (*) dalam kueri pemilihan Anda memiliki dampak yang signifikan dibandingkan dengan SELECT
Sama seperti InnoDB dan mesin penyimpanan lainnya, tipe data juga memiliki arti penting dalam kinerja pada apa yang Anda gunakan. Jika Anda memiliki kolom yang hanya dapat memiliki nilai 0 hingga 100 maka nyatakan ini sebagai tinyint karena ini akan diwakili dengan 1 byte daripada 4 byte untuk int. Ini akan mengurangi biaya I/O sebanyak 4 kali. Untuk tipe string, ambang batas yang penting adalah char(9) dan varchar(8) atau lebih besar. Setiap file penyimpanan kolom menggunakan jumlah byte tetap per nilai. Ini memungkinkan pencarian posisi cepat dari kolom lain untuk membentuk baris. Saat ini batas atas untuk penyimpanan data kolom adalah 8 byte. Jadi untuk string yang lebih panjang dari ini, sistem mempertahankan tingkat 'kamus' tambahan tempat nilai disimpan. File tingkat kolumnar kemudian menyimpan pointer ke dalam kamus. Jadi lebih mahal untuk membaca dan memproses kolom varchar(8) daripada kolom char(8) misalnya. Jadi jika memungkinkan Anda akan mendapatkan kinerja yang lebih baik jika Anda dapat menggunakan string yang lebih pendek terutama jika Anda menghindari pencarian kamus. Semua tipe data TEXT/BLOB di 1.1 dan seterusnya menggunakan kamus dan melakukan pencarian beberapa blok 8 KB untuk mengambil data tersebut jika diperlukan, semakin lama data semakin banyak blok yang diambil dan semakin besar potensi dampak kinerja.
Dalam sistem berbasis baris menambahkan kolom yang berlebihan menambah biaya kueri keseluruhan tetapi dalam sistem kolom biaya hanya terjadi jika kolom direferensikan. Oleh karena itu kolom tambahan harus dibuat untuk mendukung jalur akses yang berbeda. Misalnya, simpan bagian utama bidang dalam satu kolom untuk memungkinkan pencarian yang lebih cepat tetapi juga menyimpan nilai formulir panjang sebagai kolom lain. Pemindaian pada kode yang lebih pendek atau kolom bagian depan akan lebih cepat.
Penggabungan kueri dioptimalkan-siap untuk penggabungan skala besar dan menghindari kebutuhan akan indeks dan overhead pemrosesan loop bersarang. ColumnStore memelihara statistik tabel untuk menentukan urutan bergabung yang optimal. Pendekatan serupa berbagi dengan InnoDB seperti jika gabungan terlalu besar untuk memori UM, ia menggunakan gabungan berbasis disk untuk menyelesaikan kueri.
Untuk agregasi, ColumnStore mendistribusikan evaluasi agregat sebanyak mungkin. Ini berarti bahwa ia berbagi di seluruh UM dan PM untuk menangani kueri terutama atau sejumlah besar nilai dalam kolom agregat. Select count(*) dioptimalkan secara internal untuk memilih penyimpanan byte paling sedikit dalam sebuah tabel. Ini berarti bahwa ia akan memilih kolom CHAR(1) (menggunakan 1 byte) di atasnya kolom INT yang membutuhkan 4 byte. Implementasinya masih menghormati semantik ANSI dalam jumlah yang dipilih (*) akan menyertakan nol dalam jumlah total sebagai lawan dari pilih yang eksplisit (COL-N) yang mengecualikan nol dalam hitungan.
Order by dan limit saat ini diimplementasikan di bagian paling akhir oleh proses server mariadb pada tabel hasil sementara. Ini telah disebutkan di langkah #9 tentang bagaimana ColumnStore memproses kueri. Jadi secara teknis, hasilnya diteruskan ke Server MariaDB untuk menyortir data.
Untuk kueri kompleks yang menggunakan subkueri, pada dasarnya pendekatan yang sama dijalankan secara berurutan dan dikelola oleh UM, sama seperti fungsi Window ditangani oleh UM tetapi menggunakan proses pengurutan khusus yang lebih cepat, jadi pada dasarnya lebih cepat.
Mempartisi data Anda disediakan oleh ColumnStore yang menggunakan Peta Luas yang mempertahankan nilai min/maks data kolom dan menyediakan rentang logis untuk mempartisi dan menghapus kebutuhan pengindeksan. Peta Luas juga menyediakan partisi tabel manual, tampilan terwujud, tabel ringkasan, dan struktur serta objek lain yang harus diterapkan oleh database berbasis baris untuk kinerja kueri. Ada manfaat tertentu untuk nilai-nilai kolom ketika mereka dalam urutan atau semi-urutan karena ini memungkinkan untuk partisi data yang sangat efektif. Dengan nilai min dan max, seluruh peta tingkat setelah filter dan pengecualian akan dihilangkan. Lihat halaman ini di manual mereka tentang Extent Elimination. Ini umumnya bekerja sangat baik untuk data deret waktu atau nilai serupa yang meningkat seiring waktu.
Menginstal MariaDB ColumnStore
Menginstal MariaDB ColumnStore bisa sederhana dan mudah. MariaDB memiliki serangkaian catatan di sini yang dapat Anda rujuk. Untuk blog ini, lingkungan target instalasi kami adalah CentOS 7. Anda dapat membuka tautan ini https://downloads.mariadb.com/ColumnStore/1.2.4/ dan memeriksa paket berdasarkan lingkungan OS Anda. Lihat langkah-langkah terperinci di bawah ini untuk membantu Anda mempercepat:
### 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
Setelah selesai, Anda perlu menjalankan postConfigure perintah untuk akhirnya menginstal dan mengatur MariaDB ColumnStore Anda. Dalam contoh instalasi ini, ada dua node yang saya siapkan berjalan di mesin gelandangan:
csnode1:192.168.2.10
csnode2:192.168.2.20
Kedua node ini didefinisikan di masing-masing /etc/hosts dan kedua node yang ditargetkan diatur agar Modul Pengguna dan Kinerjanya digabungkan di kedua host. Instalasi sedikit sepele pada awalnya. Oleh karena itu, kami membagikan bagaimana Anda dapat mengonfigurasinya sehingga Anda dapat memiliki dasar. Lihat detail di bawah untuk contoh proses instalasi:
[[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] ~]#Setelah instalasi dan pengaturan selesai, MariaDB akan membuat pengaturan master/slave untuk ini sehingga apa pun yang telah kita muat dari csnode1, itu akan direplikasi ke csnode2.
Membuang Data Besar Anda
Setelah penginstalan, Anda mungkin tidak memiliki data sampel untuk dicoba. IMDB telah membagikan contoh data yang dapat Anda unduh di situs mereka https://www.imdb.com/interfaces/. Untuk blog ini, saya membuat skrip yang melakukan segalanya untuk Anda. Lihat di sini https://github.com/paulnamuag/columnstore-imdb-data-load. Buat saja itu bisa dieksekusi, lalu jalankan skripnya. Ini akan melakukan segalanya untuk Anda dengan mengunduh file, membuat skema, lalu memuat data ke database. Sesederhana itu.
Menjalankan Kueri Sampel Anda
Sekarang, mari kita coba menjalankan beberapa contoh kueri.
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)Pada dasarnya, ini lebih cepat dan cepat. Ada kueri yang tidak dapat Anda proses sama seperti yang Anda jalankan dengan mesin penyimpanan lain, seperti InnoDB. Misalnya, saya mencoba bermain-main dan melakukan beberapa pertanyaan bodoh dan melihat bagaimana reaksinya dan hasilnya adalah:
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.Oleh karena itu, saya menemukan MCOL-1620 dan MCOL-131 dan itu menunjuk ke pengaturan variabel infinidb_vtable_mode. Lihat di bawah:
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.Tetapi menyetel infinidb_vtable_mode=0 , yang berarti ia memperlakukan kueri sebagai mode pemrosesan baris demi baris yang umum dan sangat kompatibel. Beberapa komponen klausa WHERE dapat diproses oleh ColumnStore, tetapi gabungan diproses seluruhnya oleh mysqld menggunakan mekanisme gabungan loop bersarang. Lihat di bawah:
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)Butuh beberapa saat karena menjelaskan bahwa itu diproses sepenuhnya oleh mysqld. Namun, mengoptimalkan dan menulis kueri yang baik masih merupakan pendekatan terbaik dan tidak mendelegasikan semuanya ke ColumnStore.
Selain itu, Anda memiliki bantuan untuk menganalisis kueri Anda dengan menjalankan perintah seperti SELECT calSetTrace(1); atau PILIH calGetStats(); . Anda dapat menggunakan kumpulan perintah ini, misalnya, mengoptimalkan kueri rendah dan buruk atau melihat rencana kuerinya. Lihat di sini untuk detail selengkapnya tentang menganalisis kueri.
Mengatur ColumnStore
Setelah Anda sepenuhnya mengatur MariaDB ColumnStore, ia dikirimkan dengan alatnya bernama mcsadmin yang dapat Anda gunakan untuk melakukan beberapa tugas administratif. Anda juga dapat menggunakan alat ini untuk menambahkan modul lain, menetapkan atau memindahkan ke DBroots dari PM ke PM, dll. Lihat manual mereka tentang alat ini.
Pada dasarnya, Anda dapat melakukan hal berikut, misalnya, memeriksa informasi sistem:
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 = 0Kesimpulan
MariaDB ColumnStore adalah mesin penyimpanan yang sangat kuat untuk OLAP dan pemrosesan data besar Anda. Ini sepenuhnya open source yang sangat menguntungkan untuk digunakan daripada menggunakan database OLAP eksklusif dan mahal yang tersedia di pasar. Namun, ada alternatif lain untuk dicoba seperti ClickHouse, Apache HBase, atau cstore_fdw dari Citus Data. Namun, keduanya tidak menggunakan MySQL/MariaDB sehingga mungkin bukan pilihan yang tepat jika Anda memilih untuk tetap menggunakan varian MySQL/MariaDB.
