Latar belakang singkat: catatan terakhir saya menggambarkan suatu pendekatan untuk menyimpan dan mengambil data di mana Anda dapat membangun perancang aplikasi - sebuah alternatif untuk platform pengembangan modern, tetapi tanpa perlu pemrograman. Penemuan ini berpotensi mengubah seluruh dunia IT, seperti yang kita ketahui.
Saya melakukan pencarian paten dan mempublikasikan hasilnya untuk memastikan tidak ada rekan arsitektur. Kemudian ia menerima paten dan menerbitkan artikel dengan penjelasan, yang berisi beberapa pernyataan berani tentang volume, skalabilitas, kecepatan, dan hal-hal lainnya.
Tentu saja, artikel itu menimbulkan sejumlah besar pertanyaan yang perlu ditangani secara terpisah: perbedaan dari solusi yang ada dan analisis komparatif kinerja dan rencana untuk membangun permintaan basis data. Dan juga jawab pertanyaannya: ada apa ini dan mengapa?
Karena topik ini menyakitkan bagi banyak orang, dan manfaat yang diklaim sangat ambisius, komentarnya agak kasar. Alasannya bisa dimengerti - dalam artikel setiap orang langsung melihat "EAV", tentang orang-orang serius yang masih menulis penelitian, sementara masalah kinerja umumnya tidak dapat dipecahkan. Seperti yang saya ketahui dalam komentar, EAV memiliki banyak kekurangan, ini dikenal luas, dan siapa pun yang mengklaim solusi akhir untuk masalah EAV harus mendapatkan tendangan karma dalam jumlah besar untuk mendapatkan kesadaran mereka.
Hanya ada satu kehalusan: artikel tidak menyajikan EAV seperti itu
Pertanyaan paling populer adalah: "apa bedanya dengan EAV, KV, Magento ...".
Tampaknya perbedaan terletak pada segala sesuatu yang tidak sesuai dengan properti yang terdaftar:
- Struktur - dalam tabel adalah 5 kolom dan 3 indeks
- Metode pengambilan sampel - satu tabel menggambarkan tipe data dan hubungannya (meta-data) dan data itu sendiri
Tetapi jawaban seperti itu tidak cocok untuk banyak pembaca, jadi saya akan mencoba menjelaskan lebih detail.
Struktur yang dijelaskan menggunakan direktori EAV, ditambah dengan atribut ID, karena atribut apa pun juga merupakan entitas independen yang dapat memiliki atributnya sendiri, serta digunakan sebagai nilai referensi. Artinya, struktur ini dimaksudkan tidak hanya sebagai referensi-EAV, mengapa, pada kenyataannya, saya tidak dapat menyebutnya EAV.
Yang paling penting, EAV tidak bisa menjadi solusi mandiri, itu hanya panduan, salah satu elemen dari sistem. Saya berbicara tentang solusi yang lengkap dan mandiri, yang tidak memerlukan tambahan apa pun untuk membuat struktur, data, dan mengelolanya.
Untuk menjelaskan bagaimana solusinya berbeda dari Datomic, Magento dan puluhan ribu solusi dan produk lainnya, Anda perlu membandingkannya puluhan ribu kali. Oleh karena itu, saya akan berani mengusulkan teknik sederhana yang dengannya dalam beberapa menit Anda dapat membuat perbandingan dengan sistem apa pun dan mengidentifikasi perbedaannya, jika ada.
Penting untuk memverifikasi pemenuhan kondisi berikut untuk sistem yang dibandingkan:
1. Semua data disimpan dalam satu tabel (lihat juga ayat 3.) yang mengandung setidaknya bidang-bidang berikut: ID, ID Induk, ID Jenis, Nilai
2. Untuk tabel, setidaknya indeks berikut dibangun: ID; Jenis ID + Nilai; ID Induk + ID Jenis.
3. Mungkin ada beberapa tabel, tetapi semuanya berisi struktur minimal dari item 1 dan indeks, berbeda dengan jenis bidang Nilai
4. Tabel berisi deskripsi tipe data.
5. Tabel berisi deskripsi detail tipe data (dari set tipe yang dijelaskan di dalamnya)
6. Tabel berisi objek data dengan referensi ke tipenya (dari sekumpulan tipe yang dijelaskan di dalamnya)
7. Tabel berisi detail objek dengan tautan ke induk dan tipe
8. Pemilihan objek dilakukan dengan indikasi wajib dari jenis objek
9. Pemilihan detail objek dilakukan dengan indikasi wajib dari induk dan jenisnya
10. Pemilihan objek dengan perinciannya dibuat dengan indikasi wajib dari jenis perincian
11. (opsional) Objek terhubung melalui detail yang berisi jenis ID dari objek yang ditautkan
Jika semua prasyarat dipenuhi, maka Anda memiliki sistem yang berada di bawah deskripsi catatan yang dibahas di sini.
Masalah yang lebih signifikan meragukan pernyataan kinerja sistem ketika volume tumbuh.
Untuk pengujian komparatif, dua database identik dibuat, salah satunya dibangun dalam tabel biasa dari database relasional, dan yang lainnya menggunakan metodologi yang dinyatakan. Di bawah ini adalah hasil uji dua database dengan teks kueri, pengukuran waktu, dan analisis rencana eksekusi.
Dalam komentar di posting terakhir, struktur sederhana dari data terkait diusulkan , cocok untuk pengujian. Saya menganggapnya sebagai dasar: ini adalah daftar 1.048.552 buku dari 142.654 penulis yang dihasilkan dari data acak.
Strukturnya terlihat seperti ini (klik untuk melihat)CREATE TABLE `author` (
`id` int(11) NOT NULL,
`author` varchar(128) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `books` (
`id` int(8) NOT NULL,
`name` varchar(256) NOT NULL,
`author` int(8) NOT NULL,
`pages` int(4) NOT NULL,
`year` int(4) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `author`
ADD PRIMARY KEY (`id`),
ADD KEY `author` (`author`);
ALTER TABLE `books`
ADD PRIMARY KEY (`id`),
ADD KEY `name` (`name`(255)),
ADD KEY `author` (`author`);
ALTER TABLE `books`
ADD CONSTRAINT `books_ibfk_1` FOREIGN KEY (`author`) REFERENCES `author` (`id`);
:
: 1 @2.4GHz, 1GB RAM, SSD.
207 289 .
, , .
: , . .
:
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE author.author LIKE '%aro%' AND books.author=author.id
LIMIT 1000
( ):
«aro», 465 .
193 :
:
266 :
, 266 6 ( , - , ). 264 .
:
SELECT a225.val v1_225,a217.val v2_217,a223.val v3_217,a219.val v4_217
FROM test a225
LEFT JOIN (test r217 JOIN test a217 USE INDEX (PRIMARY)) ON r217.up=a217.id AND a225.id=r217.t AND a217.t=217
LEFT JOIN test a223 ON a223.up=a217.id AND a223.t=223
LEFT JOIN test a219 ON a219.up=a217.id AND a219.t=219
WHERE a225.up!=0 AND a225.t=225 AND a225.val LIKE '%aro%'
LIMIT 1000
:
, , «», , , .
, , ( ).
, , . .
, :
, . . Magento, , .
,
, , .
:
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE author.author LIKE 'lac%' AND books.author=author.id
LIMIT 1000
3.1 :
8.4 , 6 :
, , .
:
:
, ( ):
, , . , .
—
: . :
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE books.name LIKE '% %' AND books.author=author.id
LIMIT 50
:
: 148 2490 . 17 !
, , , , . :
: 181 25 . , , 7 .
:
SELECT author.author, books.name, books.pages, books.year
FROM books INNER JOIN author ON books.author=author.id
WHERE books.name LIKE '% %'
LIMIT 50
: 62 47 . . , , . , .
, , , .
, , , . , .
: () . :
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE books.pages=150 AND books.year=1972 AND books.author=author.id
LIMIT 50
:
, 30 :
, , . .
, : , .
: DDL DML .