Quintet, bukan Byte - penyimpanan data dan pendekatan pengambilan

Quintet adalah cara untuk menyajikan potongan atom data yang menunjukkan peran mereka dalam bidang bisnis. Kuintet dapat menggambarkan item apa saja, sementara masing-masing berisi informasi lengkap tentang dirinya dan hubungannya dengan kuintet lain. Deskripsi seperti itu tidak tergantung pada platform yang digunakan. Tujuannya adalah untuk menyederhanakan penyimpanan data dan untuk meningkatkan visibilitas presentasi mereka.



Kami akan membahas pendekatan untuk menyimpan dan memproses informasi dan berbagi pemikiran untuk membuat platform pengembangan dalam paradigma baru ini. Untuk apa Untuk mengembangkan lebih cepat dan dalam iterasi yang lebih pendek: buat sketsa proyek Anda, pastikan itu yang Anda pikirkan, perbaiki, dan terus perbaiki hasilnya.

Kuintet memiliki properti: tipe, nilai, induk, dan urutan di antara rekan-rekan. Dengan demikian, ada 5 komponen termasuk pengidentifikasi. Ini adalah bentuk universal paling sederhana untuk mencatat informasi, standar baru yang berpotensi sesuai dengan tuntutan pemrograman. Kuintet disimpan dalam sistem file dari struktur terpadu, dalam sejumlah besar data yang diindeks secara homogen kontinu. Model data kuintet - model data yang menggambarkan struktur data apa pun sebagai daftar tunggal tipe dan istilah dasar yang saling berhubungan berdasarkan mereka (metadata), serta instance objek yang disimpan menurut metadata (data) ini.

Kenapa Quintet bukannya Byte?

Bukan bit atau impuls elektronik yang mengorientasikan putaran magnet.

Kami terbiasa mengukur data dalam byte, apakah itu ukuran dokumen atau foto, batas lalu lintas internet, atau ruang yang tersedia di perangkat seluler Anda. Kami mengusulkan ukuran lain - Quintet - yang tidak memiliki ukuran tetap seperti Byte, tetapi mewakili jumlah atom data, yang bernilai bagi pengguna.

Misalnya, Anda dapat mengatakan bahwa basis data Anda menempati 119 megabyte penyimpanan atau Anda dapat menyatakan bahwa basis data ini menyimpan 1,37 mega-kuintet. Anda tidak terlalu peduli apa byte dalam konteks ini, tetapi Anda memahami bahwa basis data ini berisi 1,37 juta deskripsi istilah, objek, atribut, tautan, peristiwa, kueri dengan detailnya, dll. Untuk memiliki 1,37 juta keping data berharga terdengar lebih seksi daripada memiliki 119 megabita barang pada Anda.

Dengan demikian, ini bukan untuk menggantikan cara informasi disimpan pada media data, tetapi untuk beralih ke tingkat abstraksi lain.

Struktur kuintet

Ide utama artikel ini adalah mengganti tipe mesin dengan istilah manusia dan mengganti variabel dengan objek. Bukan oleh objek yang memerlukan konstruktor, destruktor, antarmuka, dan pengumpul sampah, tetapi oleh unit informasi sejernih kristal yang ditangani pelanggan. Artinya, jika pelanggan mengatakan "Klien", maka untuk menyimpan esensi pernyataan ini pada medium tidak akan membutuhkan keahlian seorang programmer.



Masuk akal untuk memusatkan perhatian pengguna hanya pada nilai objek, sedangkan jenisnya, induknya, urutan (di antara yang sederajat dalam subordinasi) dan pengidentifikasi harus jelas dari konteks atau hanya disembunyikan. Ini berarti bahwa pengguna sama sekali tidak tahu tentang kuintet, ia hanya memberikan tugas, memastikan bahwa itu diterima dengan benar, dan kemudian memulai pelaksanaannya.

Konsep dasar

Ada serangkaian tipe data yang dipahami semua orang: string, angka, file, teks, tanggal, dan sebagainya. Set sederhana seperti itu cukup untuk membuat sketsa solusi, dan "memprogram" bersama dengan persyaratan yang diperlukan untuk implementasinya. Tipe dasar yang diwakili oleh kuintet mungkin terlihat seperti ini:



Dalam hal ini, beberapa komponen kuintet tidak digunakan, sedangkan kuintet itu sendiri digunakan sebagai tipe dasar. Ini membuat sistem kernel lebih mudah dinavigasi saat mengumpulkan metadata.

Latar belakang

Karena kesenjangan analitik antara pengguna dan pemrogram, deformasi konsep yang signifikan terjadi pada tahap menguraikan proyek. Pernyataan yang meremehkan, tidak dapat dipahami, dan inisiatif yang tidak diminta seringkali mengubah ide pelanggan yang sederhana dan masuk akal menjadi kekacauan yang mustahil secara logis, jika dievaluasi dari sudut pandang pengguna.



Transfer pengetahuan harus terjadi tanpa kehilangan dan distorsi. Selanjutnya, mengatur penyimpanan pengetahuan ini, Anda sebaiknya menyingkirkan pembatasan yang diberlakukan oleh sistem manajemen data yang dipilih.

Bagaimana kami menyimpan data sekarang

Biasanya, ada banyak database di server; masing-masing berisi deskripsi skema data dengan sekumpulan detail spesifik - data yang saling berhubungan secara logis. Mereka disimpan pada media data dalam urutan tertentu, idealnya - optimal untuk mengurangi upaya pengambilan.
Sistem penyimpanan informasi yang diusulkan adalah kompromi antara berbagai metode terkenal: berorientasi kolom, relasional dan NoSQL. Ini dirancang untuk menyelesaikan tugas-tugas yang biasanya dilakukan oleh salah satu pendekatan ini.

Sebagai contoh, teori DBMS berorientasi kolom terlihat indah: kita hanya membaca kolom yang diinginkan, tetapi tidak semua baris catatan secara keseluruhan. Namun, dalam praktiknya, tidak mungkin bahwa data akan ditempatkan di media sehingga nyaman untuk mengambil puluhan dimensi analitik yang berbeda. Perhatikan bahwa atribut dan metrik analitik dapat ditambahkan dan dihapus, terkadang lebih cepat daripada kita dapat membangun kembali penyimpanan kolom kami. Belum lagi bahwa data dalam database dapat diubah, yang juga akan melanggar keindahan skema penyimpanan karena fragmentasi yang tak terhindarkan.

Metadata

Kami memperkenalkan konsep - istilah - untuk menggambarkan objek yang kami operasikan: entitas, properti, permintaan, file, dll. Kami akan mendefinisikan semua istilah yang kami gunakan di area bisnis kami. Dan dengan bantuan mereka, kami akan menggambarkan semua entitas yang memiliki perincian, termasuk bentuk hubungan antar entitas. Misalnya, atribut - tautan ke entri kamus status. Istilah ini ditulis sebagai kuintet data.

Seperangkat uraian istilah adalah metadata yang sama dengan yang diwakili oleh struktur tabel dan bidang dalam basis data biasa. Misalnya, ada struktur data berikut: permintaan layanan pada tanggal tertentu yang memiliki konten (deskripsi permintaan) dan status, di mana peserta proses produksi menambahkan komentar yang menunjukkan tanggal. Dalam konstruktor database tradisional akan terlihat seperti ini:



Karena kami memutuskan untuk menyembunyikan dari pengguna semua detail yang tidak penting, seperti ID yang mengikat, misalnya, skema akan agak disederhanakan: menyebutkan ID dihapus dan nama entitas dan nilai kuncinya digabungkan.

Pengguna "menggambar" tugas: permintaan dari tanggal hari ini yang memiliki status (nilai referensi) dan Anda dapat menambahkan komentar yang menunjukkan tanggal:



Sekarang kita melihat 6 bidang data yang berbeda, bukan 9, dan keseluruhan skema menawarkan kita untuk membaca dan memahami 7 kata, bukannya 13. Meskipun ini bukan hal utama, tentu saja.

Berikut ini adalah kuintet yang dihasilkan oleh kernel pemrosesan-kuintet untuk menggambarkan struktur ini:



Penjelasan menggantikan nilai kuintet yang disorot dalam warna abu-abu disediakan untuk kejelasan. Bidang-bidang ini tidak diisi, karena semua informasi yang diperlukan ditentukan secara jelas oleh komponen yang tersisa.


Ini mungkin terlihat sedikit rumit bagi manusia, tetapi kabar baiknya adalah - manusia tidak akan pernah melihat ini. Kernel akan merepresentasikan metadata sebagai diagram yang dapat dipahami dan data sebagai tabel datar sederhana.

Data pengguna

Biarkan saya menunjukkan bagaimana kami menyimpan kumpulan data untuk tugas di atas:



Data itu sendiri disimpan dalam kuintet sesuai dengan metadata. Kita dapat memvisualisasikannya seperti yang kita lakukan di atas:



Kita melihat struktur hierarkis yang akrab ditulis menggunakan sesuatu seperti metode Adjacency List.

Penyimpanan fisik

Data ditulis ke memori sebagai urutan item kwintet dalam byte data. Untuk mencari berdasarkan indeks, kernel memperlakukan byte-byte data tersebut sesuai dengan tipe data yang ditentukan oleh tipe-tipe dasar.
Itu dia: daftar besar lima item data.

Prinsip-prinsip penyimpanan tidak jauh berbeda dari yang sama di RDBMS, yang memungkinkan kita membangun kueri SQL ke data untuk membuat pengambilan data, BERGABUNG, fungsi agregat dan hal-hal lain yang kita sukai dalam database relasional.

Untuk menguji prototipe platform pengembangan berdasarkan sistem penyimpanan kuintet, kami menggunakan basis data relasional.

Performa

Contoh di atas sangat sederhana, tetapi apa yang akan terjadi ketika strukturnya seribu kali lebih kompleks dan ada gigabytes data?

Apa yang kita butuhkan:

1. Struktur hierarkis yang dibahas - 1 pc.
2. B-tree untuk pencarian berdasarkan ID, induk dan tipe - 3 pcs.

Dengan demikian, semua catatan dalam basis data kami akan diindeks, termasuk data dan metadata. Pengindeksan seperti itu diperlukan untuk mendapatkan manfaat dari database relasional - alat paling sederhana dan paling populer. Indeks induk sebenarnya komposit (ID induk + tipe). Indeks berdasarkan tipe juga komposit (tipe + nilai) untuk pencarian cepat objek dari tipe tertentu.

Metadata memungkinkan kita untuk menyingkirkan rekursi: misalnya, untuk menemukan semua detail objek yang diberikan, kita menggunakan indeks dengan ID induk. Jika Anda perlu mencari objek dari tipe tertentu, maka kami menggunakan indeks dengan tipe ID. Jenis adalah analog dari nama tabel dan bidang dalam DBMS relasional.



Dalam kasus apa pun, kami tidak memindai seluruh kumpulan data, dan bahkan dengan sejumlah besar nilai jenis apa pun, nilai yang diinginkan dapat ditemukan dalam sejumlah kecil langkah.

Dasar untuk platform pengembangan

Dalam dirinya sendiri, basis data semacam itu tidak mencukupi untuk pemrograman aplikasi, dan tidak lengkap, seperti yang mereka katakan, menurut Turing. Namun, kita berbicara di sini tidak hanya tentang database, tetapi mencoba untuk mencakup semua aspek: objek, antara lain, algoritma kontrol sewenang-wenang yang dapat diluncurkan, dan mereka akan bekerja.

Akibatnya, alih-alih struktur basis data yang kompleks dan kode sumber algoritma kontrol yang disimpan secara terpisah, kami mendapatkan bidang informasi yang seragam, dibatasi oleh volume ruang penyimpanan dan diatur dengan metadata. Data itu sendiri disajikan kepada pengguna dalam bentuk yang dapat dimengerti baginya - struktur area subjek dan entri yang sesuai di dalamnya. Pengguna secara sewenang-wenang mengubah struktur dan data, termasuk membuat operasi massal dengannya.

Kami tidak menemukan sesuatu yang baru: semua data sudah disimpan dalam sistem file dan pencarian di dalamnya dilakukan dengan menggunakan B-tree, baik dalam sistem file, atau dalam database. Kami hanya mengatur ulang penyajian data sehingga lebih mudah dan jelas untuk dikerjakan.

Untuk bekerja dengan representasi data ini, Anda akan memerlukan perangkat lunak kernel yang sangat kompak - mesin basis data kami berukuran lebih kecil dari BIOS komputer, dan, oleh karena itu, dapat dibuat jika tidak ada dalam perangkat keras, maka setidaknya secepat dan bug- sebebas mungkin. Untuk alasan keamanan, itu juga bisa menjadi hanya-baca.

Menambahkan kelas baru ke rakitan di .Net favorit saya, kita dapat mengamati hilangnya 200-300 MB RAM hanya pada definisi kelas ini. Megabita ini tidak akan masuk ke cache dari tingkat yang tepat, menyebabkan sistem untuk swap pada disk dengan semua overhead yang diakibatkannya. Situasi serupa terjadi pada Java. Deskripsi kelas yang sama dengan kuintet akan memakan waktu puluhan atau ratusan byte, karena kelas hanya menggunakan operasi primitif untuk bekerja dengan data yang sudah diketahui kernel.

Anda mungkin berpikir bahwa pendekatan ini sudah diterapkan berkali-kali di berbagai aplikasi, tetapi itu tidak benar.

Kami melakukan pencarian mendalam di pangkalan internet dan kekayaan intelektual (paten), dan tidak ada yang mengklaim untuk melakukan solusi yang persis sama untuk menembus batas kinerja konstruktor, solusi satu-tabel , dan sistem berbasis EAV lainnya. Namun demikian, kami menempatkan ratusan gigabytes dalam aplikasi kuintet tersebut dan ternyata berfungsi dengan baik. Jika Anda ingin melihat bukti, buat dan uji contoh Anda sendiri, silakan kunjungi akun github kami.

Prototipe platform yang kami bangun memiliki empat komponen:

1. Editor Tipe Visual untuk mendefinisikan metadata
2. Alat navigasi data seperti navigator SQL sederhana
3. Desainer Laporan Visual untuk membangun kueri SQL ke data
4. Prosesor Templat untuk menggabungkan templat dengan data yang diambil oleh kueri

Seperti yang dimaksudkan, bekerja dengan prototipe tidak ada pengguna akan berpikir ada kuintet di dalamnya - ini terlihat seperti konstruktor biasa.

Paradigma pemrograman

Pendekatan yang dideskripsikan tidak terbatas hanya pada penggunaan kuintet, tetapi mempromosikan paradigma yang berbeda dari yang digunakan oleh para programmer. Alih-alih bahasa imperatif, deklaratif, atau objek, kami mengusulkan bahasa kueri sebagai lebih akrab bagi manusia dan memungkinkan kami untuk mengatur tugas langsung ke komputer, melewati programmer dan lapisan yang tidak bisa ditembus dari lingkungan pengembangan yang ada.

Tentu saja, penerjemah dari bahasa pengguna awam ke bahasa dengan persyaratan yang jelas masih diperlukan dalam kebanyakan kasus.

Topik ini akan dijelaskan lebih rinci dalam artikel terpisah dengan contoh dan perkembangan yang ada.

Jadi, singkatnya, ini berfungsi sebagai berikut:

1. Kami pernah menggambarkan tipe data primitif menggunakan kuintet: string, angka, file, teks dan lainnya, dan juga melatih kernel untuk bekerja dengannya. Pelatihan berarti penyajian data yang benar dan pelaksanaan operasi sederhana dengan mereka.
2. Sekarang kami menggambarkan istilah pengguna (tipe data) - dalam bentuk metadata. Deskripsi hanya menentukan tipe data primitif untuk setiap tipe pengguna dan menentukan hubungan.
3. Kami memasukkan kuintet data sesuai dengan struktur yang ditentukan oleh metadata. Setiap kwintet data berisi tautan ke jenis dan induknya, yang memungkinkan Anda menemukannya dengan cepat di penyimpanan data.
4. Tugas-tugas kernel turun untuk mengambil data dan melakukan operasi sederhana dengan mereka untuk mengimplementasikan algoritma rumit yang ditentukan oleh pengguna.
5. Pengguna mengelola data dan algoritma menggunakan antarmuka visual yang menyajikan keduanya.

Kelengkapan Turing seluruh sistem dipastikan dengan perwujudan persyaratan dasar: kernel dapat melakukan operasi berurutan, secara kondisional cabang, memproses data dan menghentikan pekerjaan ketika hasil tertentu tercapai.

Bagi seseorang, manfaatnya adalah kesederhanaan persepsi, misalnya, daripada mendeklarasikan siklus yang melibatkan variabel

for (i = 0; i <length (A); i ++) if A [i] meets a condition do something with A [i] 

bentuk yang lebih dimengerti digunakan, seperti

 with every A, that match a condition, do something 

Kami bermimpi mengabstraksi dari seluk-beluk sistem informasi tingkat rendah: loop, konstruktor, fungsi, manifes, perpustakaan - semua ini memakan terlalu banyak ruang di otak seorang programmer, menyisakan sedikit ruang untuk kerja kreatif dan pengembangan.

Skalabilitas

Suatu aplikasi sering kali tidak berguna tanpa alat penskalaan: diperlukan kemampuan yang tidak terbatas untuk memperluas kapasitas pemuatan sistem informasi. Dalam pendekatan yang dijelaskan, dengan mempertimbangkan kesederhanaan ekstrim dari organisasi data, penskalaan ternyata tidak lebih rumit dari pada arsitektur yang ada.

Dalam contoh di atas dengan permintaan layanan, Anda dapat memisahkan mereka, misalnya, dengan ID mereka, membuat pembuatan ID dengan byte TINGGI tetap untuk server yang berbeda. Artinya, ketika menggunakan 32 bit untuk menyimpan ID, kiri dua-tiga-empat bit atau lebih, sesuai kebutuhan, akan menunjukkan server tempat penyimpanan aplikasi ini. Dengan demikian, setiap server akan memiliki kumpulan ID sendiri.

Kernel dari satu server dapat berfungsi secara independen dari server lain, tanpa mengetahui apa-apa tentang mereka. Saat membuat objek, itu akan diberikan prioritas tinggi ke server dengan jumlah ID minimum yang digunakan, untuk memastikan distribusi beban yang merata.

Dengan serangkaian kemungkinan variasi permintaan dan respons yang terbatas dalam organisasi data tersebut, Anda akan memerlukan operator yang cukup kompak yang mendistribusikan permintaan di seluruh server dan mengumpulkan hasilnya.