ApsaraDB for SelectDB：Model data

Informasi latar belakang

Dalam ApsaraDB for SelectDB, data dijelaskan secara logis dalam bentuk tabel. Tabel terdiri dari baris dan kolom, di mana baris merepresentasikan satu entri data, dan kolom digunakan untuk menggambarkan bidang dalam setiap baris.

Kolom dapat dibagi menjadi dua jenis: kolom kunci dan kolom nilai. Dari sudut pandang bisnis, kolom kunci sesuai dengan kolom dimensi, sementara kolom nilai sesuai dengan kolom metrik. Kolom kunci dan kolom nilai ditentukan dalam pernyataan CREATE TABLE. Kolom setelah kata kunci DUPLICATE KEY, AGGREGATE KEY, dan UNIQUE KEY dalam pernyataan CREATE TABLE adalah kolom kunci, sedangkan kolom lainnya adalah kolom nilai.

Kata kunci sebelumnya sesuai dengan tiga model data berikut yang didukung oleh ApsaraDB for SelectDB:

• Model kunci agregat

• Model kunci unik

• Model kunci duplikat

Model kunci agregat

ApsaraDB for SelectDB memproses baris yang berisi data yang sama di kolom kunci tabel berdasarkan model data yang dipilih saat membuat tabel. Model Kunci Agregat menggabungkan semua baris yang memiliki data identik di kolom kunci. Data dari baris-baris tersebut di kolom nilai di-aggregasi berdasarkan tipe agregasi yang ditentukan untuk setiap kolom nilai dalam pernyataan CREATE TABLE. Setelah penggabungan, hanya satu baris data yang disimpan.

Dengan cara ini, Model Kunci Agregat mengurangi jumlah data yang harus dipindai dan jumlah sumber daya komputasi yang diperlukan untuk query. Model ini cocok untuk skenario analisis statistik berbasis laporan. Namun, model ini tidak optimal untuk query COUNT(*), yaitu query yang berisi fungsi COUNT(*). Selain itu, tipe agregasi ditentukan untuk setiap kolom nilai. Saat melakukan query agregat dari tipe lain, Anda harus mempertimbangkan kebenaran semantik dari pernyataan query.

Contoh berikut menggambarkan Model Kunci Agregat dan menunjukkan cara menggunakan model kunci agregat.

CREATE TABLE IF NOT EXISTS test.example_tbl1
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `date` DATE NOT NULL COMMENT "Tanggal saat data ditulis ke tabel",
    `city` VARCHAR(20) COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT COMMENT "Usia pengguna",
    `sex` TINYINT COMMENT "Jenis kelamin pengguna",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "Waktu terakhir pengguna berkunjung",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "Jumlah uang yang dibelanjakan oleh pengguna",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "Waktu tinggal maksimum pengguna",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "Waktu tinggal minimum pengguna"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16;

INSERT INTO example_db.example_tbl_agg1 VALUES
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","Beijing",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","Shanghai",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","Guangzhou",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","Shenzhen",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","Shenzhen",35,0,"2017-10-03 10:20:22",11,6,6);

CREATE TABLE IF NOT EXISTS test.example_tbl2
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `date` DATE NOT NULL COMMENT "Tanggal saat data ditulis ke tabel",
    `city` VARCHAR(20) COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT COMMENT "Usia pengguna",
    `sex` TINYINT COMMENT "Jenis kelamin pengguna",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "Waktu terakhir pengguna mengunjungi",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "Jumlah uang yang dibelanjakan oleh pengguna",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "Waktu tinggal maksimum pengguna",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "Waktu tinggal minimum pengguna"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16;

INSERT INTO test.example_tbl2 VALUES
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","Beijing",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","Shanghai",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","Guangzhou",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","Shenzhen",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","Shenzhen",35,0,"2017-10-03 10:20:22",11,6,6);

INSERT INTO test.example_tbl2 VALUES
(10004,"2017-10-03","Shenzhen",35,0,"2017-10-03 11:22:00",44,19,19),
(10005,"2017-10-03","Changsha",29,1,"2017-10-03 18:11:02",3,1,1);

CREATE TABLE IF NOT EXISTS test.example_tbl3
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `date` DATE NOT NULL COMMENT "Tanggal saat data ditulis ke tabel",
    `timestamp` DATETIME NOT NULL COMMENT "Waktu saat data ditulis ke tabel, akurat hingga detik",
    `city` VARCHAR(20) COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT COMMENT "Usia pengguna",
    `sex` TINYINT COMMENT "Jenis kelamin pengguna",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "Terakhir kali pengguna mengunjungi",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "Jumlah uang yang dibelanjakan oleh pengguna",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "Waktu tinggal maksimum pengguna",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "Waktu tinggal minimum pengguna"
)
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16;

INSERT INTO test.example_tbl3 VALUES
(10000,"2017-10-01","2017-10-01 08:00:05","Beijing",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","2017-10-01 09:00:05","Beijing",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","2017-10-01 18:12:10","Beijing",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","2017-10-02 13:10:00","Shanghai",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","2017-10-02 13:15:00","Guangzhou",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","2017-10-01 12:12:48","Shenzhen",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","2017-10-03 12:38:20","Shenzhen",35,0,"2017-10-03 10:20:22",11,6,6);

Model kunci unik

Ketika menganalisis berbagai dimensi data, pastikan keunikan kunci, seperti mengonfigurasi batasan keunikan untuk kunci utama. Untuk mengatasi masalah ini, ApsaraDB for SelectDB mendukung model kunci unik. Pada versi sebelumnya, model kunci unik merupakan kasus khusus dari model kunci agregasi dan metode sederhana untuk menyajikan skema tabel. Model kunci agregasi diimplementasikan menggunakan metode Merge on Read (MoR), yang kurang cocok untuk beberapa jenis kueri agregasi. Di ApsaraDB for SelectDB V3.0, model kunci unik menggunakan metode implementasi Merge on Write (MoW) untuk memberikan kinerja kueri optimal dengan menghapus duplikat selama proses penulisan data.

Model kunci unik menimpa beberapa baris yang berisi data yang sama di kolom kunci yang ditentukan, dan hanya menyimpan baris terbaru yang diimpor. Ini memberikan batasan keunikan yang mirip dengan yang ada di database relasional.

Model kunci unik memastikan keunikan kunci utama untuk skenario yang memerlukan batasan keunikan. Model ini dapat digunakan untuk analisis data relasional, seperti pesanan. Jika Anda memiliki persyaratan kinerja tinggi untuk kueri agregasi, kami sarankan Anda menggunakan metode MoW yang disediakan dalam versi terbaru ApsaraDB for SelectDB. Namun, model kunci unik tidak dapat memanfaatkan pra-agregasi seperti ROLLUP dalam kueri.

Contoh berikut menjelaskan dua metode implementasi yang berbeda.

MoW

Metode implementasi MoW dari model kunci unik benar-benar berbeda dari model kunci agregasi. Kinerja kueri metode implementasi MoW lebih dekat dengan model kunci Duplikat yang dijelaskan di bagian berikut. Dalam skenario di mana diperlukan batasan kunci utama, metode implementasi MoW dari model kunci unik memberikan kinerja kueri yang lebih baik daripada model kunci agregasi, terutama dalam kueri agregasi dan kueri yang memerlukan indeks untuk menyaring sejumlah besar data.

Secara default, fitur MoW dinonaktifkan di ApsaraDB for SelectDB V3.0. Anda dapat mengaktifkan fitur MoW dengan mengonfigurasi properti berikut:

"enable_unique_key_merge_on_write" = "true"

Tabel berikut menjelaskan skema tabel example_tbl6.

Kode sampel berikut memberikan contoh cara membuat tabel example_tbl6 dan memodifikasi properti tabel. Informasi partisi dan distribusi dihilangkan.

CREATE TABLE IF NOT EXISTS test.example_tbl6
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `username` VARCHAR(50) NOT NULL COMMENT "Nama panggilan pengguna",
    `city` VARCHAR(20) COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT COMMENT "Usia pengguna",
    `sex` TINYINT COMMENT "Jenis kelamin pengguna",
    `phone` LARGEINT COMMENT "Nomor telepon pengguna",
    `address` VARCHAR(500) COMMENT "Alamat pengguna",
    `register_time` DATETIME COMMENT "Waktu ketika pengguna terdaftar"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16
PROPERTIES (
    "enable_unique_key_merge_on_write" = "true"
);

Skema tabel yang dibuat dengan menggunakan pernyataan CREATE TABLE di atas sepenuhnya berbeda dari yang dibuat dengan menggunakan model kunci agregasi.

Di tabel yang menggunakan model kunci unik dan fitur MoW diaktifkan, data yang akan ditimpa dan diperbarui ditandai untuk dihapus pada tahap impor data, dan data terbaru ditulis. Ketika Anda mengkueri tabel, semua data yang ditandai untuk dihapus difilter dan data terbaru dibaca. Ini menghilangkan proses agregasi data dari metode implementasi MoR dan mendukung berbagai jenis penurunan predikat dalam banyak kasus. Oleh karena itu, ini dapat meningkatkan kinerja dalam berbagai skenario, terutama dalam kueri agregasi.

MoR

Tabel berikut menjelaskan skema tabel example_tbl4.

Ini adalah tabel tipikal yang mencatat informasi pengguna dasar. Jenis data ini tidak perlu diagregasi. Anda hanya perlu memastikan keunikan kunci utama. Dalam contoh ini, kolom user_id dan username digunakan sebagai kunci utama.

Kode sampel berikut memberikan contoh cara membuat tabel example_tbl4. Informasi partisi dan distribusi dihilangkan.

CREATE TABLE IF NOT EXISTS test.example_tbl4
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `username` VARCHAR(50) NOT NULL COMMENT "Nama panggilan pengguna",
    `city` VARCHAR(20) COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT COMMENT "Usia pengguna",
    `sex` TINYINT COMMENT "Jenis kelamin pengguna",
    `phone` LARGEINT COMMENT "Nomor telepon pengguna",
    `address` VARCHAR(500) COMMENT "Alamat pengguna",
    `register_time` DATETIME COMMENT "Waktu ketika pengguna terdaftar"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16;

Tabel berikut menjelaskan skema tabel example_tbl5.

Kode sampel berikut memberikan contoh cara membuat tabel example_tbl5. Informasi partisi dan distribusi dihilangkan.

CREATE TABLE IF NOT EXISTS test.example_tbl5
(
    `user_id` LARGEINT NOT NULL COMMENT "ID pengguna",
    `username` VARCHAR(50) NOT NULL COMMENT "Nama panggilan pengguna",
    `city` VARCHAR(20) REPLACE COMMENT "Kota tempat pengguna tinggal",
    `age` SMALLINT REPLACE COMMENT "Usia pengguna",
    `sex` TINYINT REPLACE COMMENT "Jenis kelamin pengguna",
    `phone` LARGEINT REPLACE COMMENT "Nomor telepon pengguna",
    `address` VARCHAR(500) REPLACE COMMENT "Alamat pengguna",
    `register_time` DATETIME REPLACE COMMENT "Waktu ketika pengguna terdaftar"
)
AGGREGATE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16;

Skema tabel example_tbl4 yang disebutkan di atas sama dengan tabel example_tbl5 yang menggunakan model kunci agregasi.

Metode implementasi MoR dari model kunci unik dapat digantikan oleh tipe REPLACE dari model kunci agregasi. Implementasi internal serta metode penyimpanan data mereka identik.

Model kunci duplikat

Ketika Anda menganalisis beberapa dimensi data, Anda mungkin tidak perlu menggunakan kunci utama atau menggabungkan data. Dalam hal ini, Anda dapat menggunakan model kunci duplikat untuk memenuhi kebutuhan bisnis Anda.

Untuk model kunci duplikat, beberapa baris yang berisi data yang sama di kolom kunci yang ditentukan dapat disimpan dalam sistem tanpa memengaruhi satu sama lain. Data dari baris-baris tersebut tidak perlu di-agregasi sebelumnya dan tidak diperlukan batasan unik.

Model kunci duplikat cocok untuk kueri ad hoc berdasarkan dimensi tertentu dan dapat digunakan untuk menganalisis data rinci seperti log. Model kunci duplikat tidak dapat meningkatkan kinerja dengan pra-agregasi data atau mengimplementasikan pembaruan otomatis dengan mengonfigurasi batasan unik.

Contoh berikut menjelaskan metode implementasi dari model kunci duplikat.

Tabel berikut menjelaskan skema tabel example_tbl7.

Kode contoh berikut memberikan contoh tentang cara membuat tabel example_tbl7. Informasi partisi dan distribusi dihilangkan.

CREATE TABLE IF NOT EXISTS test.example_tbl7
(
    `timestamp` DATETIME NOT NULL COMMENT "Waktu ketika log dihasilkan",
    `type` INT NOT NULL COMMENT "Jenis log",
    `error_code` INT COMMENT "Kode kesalahan",
    `error_msg` VARCHAR(1024) COMMENT "Pesan kesalahan",
    `op_id` BIGINT COMMENT "ID pemilik",
    `op_time` DATETIME COMMENT "Waktu ketika kesalahan ditangani"
)
DUPLICATE KEY(`timestamp`, `type`, `error_code`)
DISTRIBUTED BY HASH(`type`) BUCKETS 16;

Model kunci duplikat berbeda dari model kunci Agregat atau Unik. Data mentah diimpor dan disimpan tanpa di-agregasi. Baris tetap dipertahankan meskipun berisi data yang sama. Kunci duplikat yang ditentukan dalam pernyataan CREATE TABLE menunjukkan kolom berdasarkan mana data diurutkan dalam penyimpanan dasar. Kami merekomendasikan Anda memilih dua hingga empat kolom pertama sebagai kunci duplikat.

Perbedaan di antara model data

Batasan model kunci agregasi

Model kunci agregasi menampilkan data yang sepenuhnya teragregasi. Data yang tidak teragregasi, seperti data yang diimpor dalam dua batch, harus ditampilkan secara konsisten dengan cara tertentu. Contoh berikut menjelaskan bagaimana model kunci agregasi secara konsisten menampilkan data.

Tabel berikut menggambarkan skema dari tabel example_tbl8.

Tuliskan data yang dijelaskan dalam tabel berikut ke tabel example_tbl8 dalam dua batch.

• Tabel berikut menggambarkan data yang diimpor dalam batch pertama.

• Tabel berikut menggambarkan data yang diimpor dalam batch kedua.

Tiga baris diimpor dalam dua batch untuk pengguna dengan ID 10001. Sebelum data di-agregasi secara internal di ApsaraDB for SelectDB, lima baris sebelumnya disimpan di penyimpanan bawah. Untuk memastikan hanya data agregat berikut yang dapat di-query, sistem secara otomatis menambahkan operator agregat ke mesin query. Tabel berikut menggambarkan data agregat yang dapat di-query.

Sebagai contoh, jika Anda menjalankan pernyataan SQL berikut, hasil yang dikembalikan adalah 5 bukan 1:

SELECT MIN(cost) FROM example_tbl8;

Dengan cara ini, data ditampilkan secara konsisten. Namun, efisiensi query berkurang pada beberapa query. Dalam contoh berikut, query COUNT(*) digunakan.

SELECT COUNT(*) FROM example_tbl8;

Di database lain, hasil untuk query semacam itu dikembalikan dengan cepat. Dalam implementasi aktual, sebuah model dapat memperoleh hasil query dengan menghitung baris dan menyimpan nilai hitungan ketika data diimpor, atau dengan memindai hanya satu kolom untuk mendapatkan nilai hitungan ketika data di-query, yang membutuhkan sedikit overhead. Namun, model kunci agregasi memerlukan overhead besar untuk query semacam itu.

Sebagai contoh, Anda meng-query data sebelumnya.

Setelah Anda menjalankan pernyataan SELECT COUNT(*) FROM example_tbl8;, 4 diharapkan dikembalikan. Namun, jika hanya kolom user_id yang dipindai dan data di-agregasi selama query, 3 dikembalikan. Jika data tidak di-agregasi selama query, 5 dikembalikan karena lima baris diimpor dalam dua batch. Kedua hasil tersebut salah.

Ini karena jika data yang akan di-agregasi melibatkan banyak kolom, sejumlah besar data perlu dipindai selama query COUNT(). Untuk mendapatkan hasil yang benar yaitu 4, model Anda harus membaca kolom user_id dan date, serta meng-agregasi data selama query. Secaraspesifik, selama query COUNT(), model harus memindai semua kolom kunci agregat dan meng-agregasi data untuk mendapatkan hasil yang semantiknya benar. Dalam contoh ini, kolom kunci agregat mencakup kolom user_id dan date.

Jika Anda perlu sering melakukan query COUNT(*), kami sarankan Anda menambahkan kolom dengan nilai tetap 1 dan tipe agregasi SUM untuk mensimulasikan fungsi COUNT(*). Sebagai contoh, kolom count ditambahkan ke skema tabel example_tbl8. Tabel berikut menggambarkan skema tabel yang dimodifikasi.

Nilai kolom count tetap 1. Dalam hal ini, pernyataan SELECT COUNT(*) FROM table; setara dengan pernyataan SELECT SUM(COUNT) FROM table;. Efisiensi query yang terakhir jauh lebih tinggi daripada yang pertama. Namun, metode ini memiliki batasan. Anda tidak dapat mengimpor ulang baris yang berisi data yang sama di kolom kunci agregat. Jika tidak, pernyataan SELECT SUM(COUNT) FROM table; hanya dapat meng-query jumlah baris yang diimpor asli. Dalam hal ini, pernyataan tersebut tidak dapat mewakili semantik dari pernyataan SELECT COUNT(*) FROM table;.

Sebagai alternatif, tambahkan kolom count dengan nilai tetap 1 dan tipe agregasi REPLACE. Dalam hal ini, hasil yang sama dikembalikan untuk pernyataan SELECT SUM(COUNT) FROM table; dan SELECT COUNT(*) FROM table;. Selain itu, metode ini memungkinkan Anda mengimpor ulang baris yang berisi data yang sama di kolom kunci agregat.

MoW dari model kunci unik

Metode implementasi MoW dari model kunci unik tidak memiliki batasan yang sama seperti model kunci agregasi. Jika Anda menggunakan MoW, model kunci unik menambahkan bitmap penghapusan untuk setiap batch baris yang diimpor untuk menandai data yang akan ditimpa atau dihapus. Dalam contoh sebelumnya, setelah data dari batch pertama diimpor, data disimpan dengan cara berikut.

• Tabel berikut menggambarkan hasil setelah data dari batch pertama diimpor.

Setelah data dari batch kedua diimpor, baris duplikat dalam data batch pertama ditandai sebagai dihapus. Tabel berikut menggambarkan hasil setelah data dari dua batch diimpor.

• Tabel berikut menggambarkan hasil setelah data yang diimpor dalam batch pertama ditandai.

• Tabel berikut menggambarkan hasil setelah data dari batch kedua diimpor.

Selama query, model tidak membaca data yang ditandai true dalam bitmap penghapusan dan tidak ada data yang di-agregasi. Dalam contoh ini, empat baris valid ada dalam data sebelumnya dan 4 diharapkan dikembalikan. Ini memungkinkan overhead minimal karena hanya satu kolom yang dipindai.

Dalam lingkungan pengujian, query COUNT(*) menggunakan metode implementasi MoW dari model kunci unik memberikan performa 10 kali lebih tinggi daripada menggunakan model kunci agregasi.

Batasan model kunci duplikat

Model kunci duplikat tidak memiliki batasan yang sama seperti model kunci agregasi. Hal ini karena model kunci duplikat tidak melibatkan semantik agregasi. Model ini dapat memindai satu kolom untuk mendapatkan hasil yang semantiknya benar untuk query COUNT(*).

Kolom kunci

Ketika Anda menggunakan model Duplicate, Aggregate, atau Unique key, kolom kunci ditentukan dalam pernyataan CREATE TABLE. Namun, kolom kunci bervariasi berdasarkan model data.

Untuk model Duplicate key, kolom sebuah tabel dapat dianggap sebagai kolom pengurutan, bukan kolom pengidentifikasi unik.

Untuk model Aggregate atau Unique key, kolom sebuah tabel adalah baik kolom pengurutan maupun kolom pengidentifikasi unik.

Saran untuk memilih model data

Model data ditentukan saat tabel dibuat dan tidak dapat diubah. Oleh karena itu, penting untuk memilih model data yang sesuai.

1. Model kunci Agregasi dapat mengurangi jumlah data yang harus dipindai dan jumlah sumber daya komputasi yang diperlukan untuk kueri dengan melakukan pra-agregasi data, yang dapat mempercepat kueri. Oleh karena itu, model kunci Agregasi cocok untuk skenario kueri berbasis laporan dengan pola tetap atau skenario kueri agregat berbasis laporan. Namun, model ini tidak optimal untuk kueri COUNT(*). Selain itu, tipe agregasi ditentukan untuk setiap kolom nilai. Saat Anda melakukan kueri agregat dari jenis lain, Anda harus mempertimbangkan kebenaran semantik dari pernyataan kueri.

2. Model kunci Unik memastikan keunikan kunci utama untuk skenario yang memerlukan batasan keunikan. Model kunci Unik cocok untuk analisis data relasional, seperti pesanan dan data transaksi. Namun, model kunci Unik tidak dapat mengeksploitasi keuntungan yang diberikan oleh pra-agregasi seperti ROLLUP dalam kueri. Jika Anda memiliki persyaratan berkinerja-tinggi untuk kueri agregat, kami sarankan Anda menggunakan metode implementasi MoW yang tersedia di ApsaraDB for SelectDB V3.0 atau lebih baru.

3. Meskipun model kunci Duplikat tidak dapat memanfaatkan pra-agregasi, model ini tidak memiliki batasan model kunci Agregasi. Model ini dapat mengeksploitasi keuntungan penyimpanan berorientasi kolom, yang hanya membaca data dari kolom yang diperlukan tanpa perlu membaca data dari semua kolom kunci. Model kunci Duplikat cocok untuk kueri ad hoc berdasarkan dimensi dan dapat digunakan untuk menganalisis data rinci seperti log.

4. Jika Anda perlu memperbarui kolom parsial, Anda bisa mendapatkan saran terkait. Untuk informasi lebih lanjut, lihat Pembaruan Parsial.