Selama 16 tahun terakhir, Greenplum, sebuah DBMS paralel yang terbuka dan masif, telah membantu berbagai perusahaan membuat keputusan berdasarkan analisis data.
Selama ini, Greenplum merambah ke berbagai bidang bisnis, termasuk: ritel, fintech, telekomunikasi, industri, e-commerce. Melakukan penskalaan ke ratusan node secara horizontal, toleransi kesalahan, kode sumber terbuka, kompatibilitas penuh dengan PostgreSQL, transaksionalitas, dan ANSI SQL - sulit membayangkan kombinasi properti yang lebih baik untuk DBMS analitik. Mulai dari kelompok besar di perusahaan raksasa dunia, seperti Morgan Stanley (200 node, 25 Pb data) atau Tinkoff (> 70 node), dan berakhir dengan instalasi dua-simpul kecil di startup yang nyaman, semakin banyak perusahaan memilih Greenplum. Sangat menyenangkan untuk mengamati tren ini di Rusia - selama dua tahun terakhir, jumlah perusahaan domestik besar yang menggunakan Greenplum naik tiga kali lipat.
Pada musim gugur 2019, rilis DBMS besar lainnya dirilis. Pada artikel ini, saya akan membahas secara singkat tentang fitur-fitur baru utama dari GP 6.
Rilis besar sebelumnya dari Greenplum versi 5 diterbitkan pada September 2017, rinciannya dapat ditemukan di
artikel ini . Jika Anda masih tidak tahu apa itu Greenplum, pengantar singkat dapat diperoleh dari
artikel ini . Ini sudah tua, tetapi arsitektur DBMS mencerminkan dengan benar.
Rilis saat ini, dengan benar, dapat disebut gagasan bersama: beberapa perusahaan dari seluruh dunia berpartisipasi dalam pengembangan - di antaranya Pivotal, Arenadata (tempat penulis artikel ini bekerja), Alibaba.
Jadi apa yang baru di Greenplum 6?
Tabel direplikasi
Biarkan saya mengingatkan Anda bahwa di Greenplum ada dua jenis distribusi tabel di sebuah cluster:
- Distribusi seragam acak
- Distribusi pada satu atau beberapa bidang
Dalam kebanyakan kasus, bergabung dengan dua tabel (BERGABUNG) dilakukan dengan redistribusi data antara segmen cluster selama eksekusi permintaan, dan hanya jika kedua tabel awalnya didistribusikan oleh kunci bergabung BERGABUNG terjadi secara lokal pada segmen tanpa mentransfer data antar segmen.
GP 6 memberikan arsitek alat optimisasi skema penyimpanan baru - tabel direplikasi. Tabel tersebut diduplikasi secara penuh pada semua segmen cluster. Setiap koneksi ke tabel seperti itu di sisi kanan akan dilakukan secara lokal, tanpa mendistribusikan ulang data. Pada dasarnya, fitur ini dimaksudkan untuk menyimpan banyak direktori.
Contoh kueri dengan tabel yang direplikasiCREATE TABLE expand_replicated … DISTRIBUTED REPLICATED; CREATE TABLE expand_random … DISTRIBUTED RANDOMLY; explain select * from expand_rnd a2 left join expand_replicated a3 on a2.gen = a3.gen
Algoritma Kompresi Zstandard (ZSTD)
Dipersembahkan pada tahun 2016 oleh pengembang Facebook, algoritme kompresi lossless hampir segera menghantam jantung tim Arenadata kami, karena dibandingkan dengan Zlib (digunakan secara default di Greenplum) ia memiliki rasio kompresi yang lebih tinggi dengan lebih sedikit waktu yang diperlukan untuk kompresi dan dekompresi:
Sumber: cnx-software.comEfisiensi kompresi adalah salah satu parameter terpenting dari DBMS analitik modern. Bahkan, ini memungkinkan Anda untuk mengurangi beban pada subsistem disk cluster yang relatif mahal dengan memuat CPU yang relatif murah. Ketika secara berurutan membaca dan menulis data dalam jumlah besar, ini menghasilkan pengurangan yang signifikan dalam TCO sistem.
Pada 2017, tim kami menambahkan dukungan ZSTD untuk tabel kolom di Greenplum, namun, menurut kebijakan rilis, revisi ini tidak masuk ke rilis minor resmi Greenplum. Hingga hari ini, itu hanya tersedia untuk pelanggan komersial Arenadata, dan dengan rilis 6.0, semua orang dapat menggunakannya.
Optimalisasi ekspansi cluster (perluas)
Dalam versi GP sebelumnya, ekspansi klaster horizontal (menambahkan node baru) memiliki beberapa keterbatasan:
- Meskipun redistribusi data terjadi di latar belakang tanpa downtime, sistem restart diperlukan ketika menambahkan node baru
- Algoritme hashing dan distribusi data memerlukan redistribusi lengkap semua tabel selama ekspansi - proses distribusi data latar belakang bisa memakan waktu berjam-jam atau bahkan berhari-hari untuk cluster yang sangat besar
- Selama distribusi latar belakang tabel, semua gabung hanya dibagikan
Greenplum 6 memperkenalkan algoritma perluasan kluster yang sama sekali baru, karena:
- Ekspansi sekarang terjadi tanpa menghidupkan ulang sistem - downtime tidak diperlukan
- Algoritme hashing yang konsisten memungkinkan Anda untuk mendistribusikan ulang hanya sebagian dari blok ketika menambahkan node, yaitu redistribusi latar belakang tabel bekerja berkali-kali lebih cepat
- Logika untuk mengubah direktori sistem telah berubah - sekarang bahkan selama proses ekspansi semua koneksi (BERGABUNG) bekerja seperti biasa - baik secara lokal maupun didistribusikan
Sekarang ekstensi Greenplum hanya dalam hitungan menit, bukan jam, ini akan memungkinkan kluster untuk mengikuti selera unit bisnis yang terus tumbuh.
Keamanan tingkat kolom
Sekarang dimungkinkan untuk mendistribusikan hak ke kolom tertentu dalam tabel (fitur berasal dari PostgreSQL):
grant all (column_name) on public.table_name to gpadmin;
Jsonb
Biner, penyimpanan optimal objek tipe JSON sekarang tersedia di GP. Baca lebih lanjut tentang format di
sini .
Jelaskan Otomatis
Ekstensi hebat lainnya yang datang ke GP dari PostgreSQL. Itu dimodifikasi untuk bekerja dalam mode terdistribusi pada cluster Greenplum oleh tim Arenadata.
Mengizinkan secara otomatis setiap permintaan (atau yang diambil secara terpisah) dalam DBMS untuk menyimpan informasi tentang:
- rencana permintaan;
- sumber daya yang dikonsumsi pada setiap tahap eksekusi permintaan pada setiap segmen (node);
- waktu yang dihabiskan;
- jumlah baris yang diproses pada setiap tahap kueri pada setiap segmen (node).
Diskquota
Ekstensi postgreSQL yang memungkinkan Anda membatasi penyimpanan disk yang tersedia untuk setiap pengguna dan skema:
select diskquota.set_schema_quota('schema_name', '1 MB'); select diskquota.set_role_quota('user_name', '1 MB');
Fitur Distribusi DB Arenadata Baru
Penafian - akan ada beberapa baris iklan berikutnya :)
Biarkan saya mengingatkan Anda, kami, Arenadata, sedang mengembangkan, mengimplementasikan dan mendukung platform penyimpanan data kami berdasarkan pada teknologi open source - Greenplum, Kafka, Hadoop, Clickhouse. Klien kami adalah perusahaan Rusia terbesar di bidang ritel, telekomunikasi, fintech dan lainnya. Di satu sisi, kami sendiri adalah kontributor proyek sumber terbuka (melakukan perubahan pada kernel), di sisi lain, kami sedang mengembangkan fungsionalitas tambahan yang hanya tersedia untuk pelanggan komersial kami. Selanjutnya kita akan berbicara tentang fitur utama.
Tkhemali Connector alias Connector Greenplum -> Clickhouse
Dalam proyek, kami sering menggunakan Greenplum + Clickhouse bunch - di satu sisi, ini memungkinkan kami untuk menggunakan model klasik terbaik dalam membangun gudang data (dari sumber ke data mart) yang membutuhkan banyak koneksi, mengembangkan sintaks ANSI SQL, transaksionalitas dan chip lain yang dimiliki Greenplum, di sisi lain, untuk menyediakan akses ke jendela toko built-in lebar dengan kecepatan maksimum ke sejumlah besar pengguna - dan Clickhouse tidak memiliki pesaing dalam hal ini.
Untuk secara efektif menggunakan bundel seperti itu, kami telah mengembangkan konektor paralel khusus, yang secara transaksi (yaitu, konsisten bahkan dalam kasus transaksi rollback) memungkinkan Anda untuk mentransfer data dari GP ke KH. Secara umum, arsitektur konektor ini layak mendapatkan artikel teknis murni yang terpisah - sebenarnya, di dalam kami harus menerapkan antrian asinkron paralel dengan sistem untuk secara dinamis memilih jumlah utas per sisipan dan aliran data.
Hasilnya adalah kecepatan interaksi yang luar biasa: dalam pengujian kami pada disk SATA biasa, kami mendapatkan hingga 1 Gb / s per sisipan pada satu pasang server Greenplum - Clickhouse. Mengingat bahwa kluster GP rata-rata pelanggan kami terdiri dari 20+ server, kecepatan interaksi lebih dari cukup.
Konektor kafka
Kami melakukan hal yang sama dengan integrasi dengan pialang pesan Kafka - kami sering menghadapi tugas kelebihan data dari Kafka ke Greenplum dalam mode waktu nyata (detik atau puluhan detik). Namun, arsitektur konektor untuk Kafka berbeda. Konektor adalah sekelompok proses terpisah yang disinkronkan (diluncurkan di Docker) dengan penemuan otomatis, yang, di satu sisi, adalah konsumen Kafka, dan di sisi lain, mereka memasukkan data langsung ke segmen Greenplum. Konektor dapat bekerja dengan Kafka Registry dan memastikan konsistensi lengkap dari data yang ditransfer bahkan jika terjadi kegagalan perangkat keras.
Sistem manajemen dan pemantauan
Pengoperasian sistem di tempat produksi menuntut permintaan yang tinggi untuk penyebaran, pembaruan, dan pemantauan cluster. Penting bahwa segala sesuatu yang terjadi dalam DBMS transparan untuk operasi dan spesialis DBA.
Sistem manajemen dan pemantauan Arenadata Cluster Manager (ADCM) kami memberi para profesional operasi semua alat yang mereka butuhkan. Bahkan, menyebarkan dan memperbarui cluster Greenplum dilakukan dengan mengklik tombol pada antarmuka grafis (semua OS, layanan, pemasangan disk, dan pengaturan jaringan dilakukan secara otomatis), selain itu, Anda mendapatkan tumpukan pemantauan yang sepenuhnya dikonfigurasi, siap untuk diintegrasikan dengan sistem perusahaan Anda. Omong-omong, Arenadata Cluster Manager tidak hanya dapat mengelola Greenplum, tetapi juga Hadoop, Kafka, Clickhouse (kumpulan layanan ini diperlukan. Versi gratis mereka, seperti ADCM sendiri, dapat diunduh secara gratis di
situs web kami, hanya dengan mengisi pop-up).
Kesimpulan
Jika Anda menggunakan Greenplum 5.X, saya sarankan Anda mempertimbangkan untuk meningkatkan cluster Anda ke versi saat ini 6.X dalam 2-3 bulan ke depan.
Jika Anda belum menggunakan Greenplum, bergabunglah dengan kami! Kami, Arenadata, selalu siap membantu Anda dengan ini.
Referensi
Greenplum di githubSaluran Greenplum Russia Telegram - ajukan pertanyaan Anda langsung ke pengguna Greenplum
Dokumentasi Greenplum 6