PolarDB：Fungsi yang Didefinisikan Pengguna

Cara kerjanya

UDF disimpan di pusat meta setelah dibuat. Anda dapat memuat UDF ke node komputasi untuk dieksekusi. Logika eksekusi terkait SQL dikirim ke mesin SQL untuk diproses, lalu hasilnya dikembalikan. Logika lain seperti alur kontrol dijalankan di mesin PL.

Sebelum dieksekusi, UDF didaftarkan ke pusat manajemen fungsi waktu proses. Ukuran memori untuk satu kueri dibatasi secara ketat selama eksekusi.

Pendorongan fungsi

PolarDB-X menentukan apakah UDF perlu didaftarkan pada node data dengan memeriksa bidang SQL DATA ACCESS. Jika bidang SQL DATA ACCESS diatur ke no sql, UDF juga didaftarkan pada node data. Setelah pendaftaran, UDF dapat didorong ke bawah.

Untuk menjaga kompatibilitas dengan MySQL, PolarDB-X mendaftarkan UDF menggunakan pustaka MySQL.

Pendorongan fungsi dan penskalaan

Setelah penskalaan, Anda dapat mengeksekusi pernyataan pushdown udf untuk mendaftarkan UDF yang dapat didorong ke bawah dengan DN baru.

Perbedaan dari MySQL

1. Hanya operasi bahasa query data (DQL) yang dapat dilakukan pada UDF, tetapi tidak operasi bahasa manipulasi data (DML) atau bahasa definisi data (DDL).

2. Dalam MySQL, fungsi disimpan di tingkat database. Dalam PolarDB-X, UDF disimpan di tingkat instance.

3. Bidang SQL DATA ACCESS tidak dapat dimodifikasi karena logika pendorongan UDF terlibat.

Peringatan

UDF hanya didukung pada instance PolarDB-X 5.4.16 dan yang lebih baru.

Sintaksis

Buat UDF

CREATE
    [DEFINER = user]
    FUNCTION sp_name ([func_parameter[,...]])
    RETURNS type
    [characteristic ...] routine_body

func_parameter:
    param_name type
 
characteristic:
    COMMENT 'string'
  | LANGUAGE SQL
  | [NOT] DETERMINISTIC
  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
  | SQL SECURITY { DEFINER | INVOKER }
 
routine_body:
　　Valid SQL routine statement

Contoh

CREATE FUNCTION my_mul(x int, y int) 
RETURNS int
LANGUAGE SQL
DETERMINISTIC
COMMENT 'fungsi perkalian saya'
RETURN x*y*31;

Panggil UDF

UDF dipanggil dengan cara yang sama seperti fungsi bawaan umum.

Hapus UDF

DROP FUNCTION [IF EXISTS] FUNCTION_NAME;

Ubah UDF

ALTER FUNCTION func_name [characteristic ...]

characteristic: {
    COMMENT 'string'
  | LANGUAGE SQL
  | SQL SECURITY { DEFINER | INVOKER }
}

Lihat semua UDF

SELECT * FROM information_schema.Routines WHERE ROUTINE_TYPE = 'FUNCTION';

Lihat UDF tertentu

SHOW FUNCTION STATUS [LIKE 'pattern' | WHERE expr]

SHOW CREATE FUNCTION Nama fungsi;

SELECT * FROM information_schema.Routines WHERE ROUTINE_NAME = 'Nama fungsi';

Lihat UDF yang didorong ke bawah

SELECT * FROM information_schema.pushed_function;

Batalkan UDF yang sedang dieksekusi

Anda dapat mengeksekusi pernyataan KILL untuk menghentikan kueri yang sedang dieksekusi.

kill {query | connection} connection_id;

Manajemen cache untuk UDF

Semua metadata fungsi kustom (termasuk keberadaan fungsi kustom) selalu disimpan dalam cache. Namun, tubuh fungsi hanya dimuat saat diperlukan.

Lihat UDF yang di-cache

select * from information_schema.function_cache;

Lihat ukuran cache

select * from information_schema.function_cache_capacity;

Tetapkan ukuran cache

resize function cache num;

Kosongkan cache

clear function cache;

Muat ulang UDF

reload functions;

Contoh

# Buat UDF.
CREATE FUNCTION my_mul(x int, y int)
     RETURNS int
     LANGUAGE SQL
     DETERMINISTIC
     COMMENT 'fungsi perkalian saya'
     RETURN x*y*31;

# UDF belum dipanggil pada saat ini. Namun, fungsi tersebut sudah ada di cache.
# Ukuran cache adalah 0, menunjukkan bahwa UDF belum dimuat.
select * from information_schema.function_cache;
+--------------------+--------------+------+
| ID                 | FUNCTION     | SIZE |
+--------------------+--------------+------+
| xx.xx.xx.xx:3000   | mysql.my_mul |    0 |
| yy.yy.yy.yy:3100   | mysql.my_mul |    0 |
+--------------------+--------------+------+

# Panggil UDF.
select my_mul(2,2);
+--------------+
| my_mul(2, 2) |
+--------------+
|          124 |
+--------------+

# Periksa tampilan terkait, yang menunjukkan bahwa UDF telah dimuat.
select * from information_schema.function_cache;
+--------------------+--------------+------+
| ID                 | FUNCTION     | SIZE |
+--------------------+--------------+------+
| xx.xx.xx.xx:3000   | mysql.my_mul |    0 |
| yy.yy.yy.yy:3100   | mysql.my_mul |   79 |
+--------------------+--------------+------+

select * from information_schema.function_cache_capacity;
+--------------------+-----------+-------------+
| ID                 | USED_SIZE | TOTAL_SIZE  |
+--------------------+-----------+-------------+
| xx.xx.xx.xx:3000   |         0 | 15139759718 |
| yy.yy.yy.yy:3100   |        79 | 15139759718 |
+--------------------+-----------+-------------+

# Setelah Anda memuat ulang UDF, cache diatur ulang.
reload functions;

# Periksa tampilan terkait, yang menunjukkan bahwa cache telah diatur ulang.
select * from information_schema.function_cache;
+--------------------+--------------+------+
| ID                 | FUNCTION     | SIZE |
+--------------------+--------------+------+
| xx.xx.xx.xx:3000   | mysql.my_mul |    0 |
| yy.yy.yy.yy:3100   | mysql.my_mul |    0 |
+--------------------+--------------+------+

Manajemen sumber daya untuk UDF

Kelola memori

Selama eksekusi UDF, memori utamanya digunakan untuk menyimpan kursor. Oleh karena itu, PolarDB-X memungkinkan Anda menggunakan parameter PL_CURSOR_MEMORY_LIMIT dan PL_MEMORY_LIMIT untuk membatasi memori maksimum yang dapat digunakan oleh satu kursor dan memori maksimum yang dapat digunakan oleh UDF. Memori untuk seluruh pernyataan kueri yang memanggil UDF juga dibatasi.

Parameter PL_CURSOR_MEMORY_LIMIT digunakan untuk membatasi memori yang ditempati oleh setiap kursor. Jika batas memori terlampaui, data disimpan di hard disk. Parameter PL_MEMORY_LIMIT digunakan untuk membatasi memori untuk UDF.

Batasi kedalaman panggilan

Anda dapat menggunakan parameter MAX_PL_DEPTH untuk membatasi kedalaman panggilan. Panggilan yang sangat dalam membuat sulit untuk memahami logika eksekusi UDF dan mengonsumsi sumber daya besar.