Model data jaringan relasional

Model relasional telah kehilangan eksklusivitasnya

Persyaratan untuk fungsionalitas dan struktur basis data (DB), yang paling sepenuhnya diimplementasikan dalam sistem relasional, sekarang berada di bawah tekanan persyaratan baru.

Masalah pertama adalah efisiensi rendah untuk data besar. Sumber data besar adalah jaringan sosial, sistem pengawasan video, sensor spasial, penagihan, dll. Database relasional (RDB) berfungsi dengan baik jika skema data ditentukan secara tepat sebelumnya, sebelum memulai aplikasi. Tetapi big data secara inheren sulit terstruktur pada tahap desain database. Hanya ketika informasi dikumpulkan, secara bertahap, strukturnya lebih jelas.

Yang kedua - pencarian, pertanyaan komputasi dalam RDB dengan tabel besar - ini adalah tugas kompleksitas algoritmik yang tinggi. Penggunaan pengindeksan dan hashing bekerja dengan baik di BDB yang kurang lebih statis, yang sebagian besar diisi sebelum sistem dioperasikan. Dan dalam kondisi kedatangan cepat array data baru secara real time, keuntungan dari metode ini diratakan, karena biaya overhead meningkat tajam.

Kelemahan ketiga RDB mengikuti dari persyaratan ketat untuk sirkuit data dalam kerangka "bentuk normal" kanonik. Kebutuhan akan sejumlah besar variasi aplikasi memerlukan upaya yang signifikan untuk membuat model data, dan tingkat keterampilan programmer dan tenggat waktu yang ketat menyebabkan kesalahan yang memerlukan koreksi dan perubahan. Tetapi setiap perubahan yang sudah "hidup", diisi dengan DBD ("migrasi") adalah tugas yang bahkan lebih rumit dan melelahkan, yang dalam beberapa kasus sama sekali tidak memiliki solusi lain, seperti sepenuhnya mengganti database lama dengan yang baru.

"Keindahan" dan ketelitian model relasional yang diimplementasikan dalam SQL, selama 3 dekade, telah menyenangkan para programmer. Model "lama": jaringan atau hierarkis hampir terlupakan. Ya, hampir tidak ada produk perangkat lunak seperti itu, dengan pengecualian yang mungkin dari IDMS "hampir abadi" [1].

Dalam dekade terakhir, pekerjaan aktif sedang dilakukan untuk menciptakan sistem manajemen basis data alternatif (DBMS), yang begitu sederhana disebut - NoSQL. Di bawah konsep ini sistem yang sangat berbeda sekarang jatuh yang sangat berbeda satu sama lain. Menariknya, jaringan "lama" dan model hierarkis tidak termasuk dalam konsep NoSQL! Ulasan bagus di bidang ini dapat ditemukan di [2,3,4].

Kategori NoSQL termasuk "grafik" database [5], yang secara abstrak dekat dengan model jaringan kanonik CODASYL [6]. Seperti namanya, sistem tersebut adalah dua set - node (simpul) dan tepi (busur) yang tidak terorganisir. Keuntungan utama dari basis data jaringan - navigasi adalah "ditentukan" bukan pada saat memproses permintaan , seperti dalam RDB, tetapi pada saat menambahkan data baru (untuk grafik - simpul dan tepi), itu juga berlaku untuk sistem grafik. Tetapi basis data grafik tidak terstruktur sebelum diisi, tidak seperti basis data CODASYL.

Kelas basis data NoSQL terpopuler lainnya adalah "key-value" (contoh - Redis [7]) dan "penyimpanan dokumen" (contoh - MongoDB [8]). Karena tinjauan terperinci atas sistem tersebut bukan tujuan dari artikel ini, penting untuk dicatat hanya yang berikut ini.

Sistem NoSQL, sebagai suatu peraturan, beroperasi berdasarkan sistem file terdistribusi yang menyediakan skalabilitas dan keandalan [9]. Tetapi masalah yang secara matematis diselesaikan dengan seksama dalam kerangka model relasional adalah integritas dan konsistensi database (asalkan, tentu saja, desain yang kompeten secara profesional dari skema normalisasi) tidak diajukan sama sekali di sebagian besar sistem NoSQL.

Secara total, saat ini situasinya kira-kira sebagai berikut: 75% dari basis data bersifat relasional, NoSQL dalam bentuk murni digunakan dalam sistem yang sangat terspesialisasi, dan kombinasi berbagai model basis data digunakan dalam proyek jaringan global yang sangat padat: Google, Facebook, Instagram, WhatsApp, dan sejenisnya.

Database relasional tanpa SQL

Selain masalah praktis yang dijelaskan di atas, penggunaan RDB baru-baru ini melihat tren penting lainnya.

Selain "kekakuan" model relasional yang terkadang berlebihan, kelemahan praktis (bukan teoretis) utamanya adalah kompleksitas manipulasi data. Opsi pertama adalah menggunakan pipa operasi pada set - penyatuan, persimpangan, penyaringan, dll. dalam praktiknya, hampir tidak pernah digunakan, karena dikaitkan dengan pengeluaran sumber daya kolosal dan dibenarkan hanya dengan pemrosesan "batch" dari set permintaan dari jenis yang sama. Opsi kedua - penerjemah SQL memerlukan profesionalisme tinggi, pengetahuan yang baik tentang teori himpunan, teori basis data, dan pengalaman praktis yang cukup.

Pemrograman berorientasi objek (OOP) telah menjadi standar, tetapi SQL adalah bahasa deklaratif yang tata bahasanya tidak sesuai dengan bahasa OOP yang paling umum (C ++, Java, JavaScript, Python). Akibatnya, solusi untuk "menanamkan" RDB (bekerja dengan query SQL) berdasarkan kelas perpustakaan yang disebut ORM (Object-Relational Mapping - Object-Relational Mapping (Transformation) [9]) telah mendapatkan popularitas.

Menggunakan kelas ORM memungkinkan programmer untuk melakukannya tanpa SQL saat menggunakan RDB. ORM secara otomatis menghasilkan query SQL ke RDB untuk membuat tabel dan memanipulasi data. Sebagian besar ORM memiliki antarmuka dengan berbagai DBMS populer - SQLite, MySQL, PostgreSQL dan lainnya, yang memberikan pilihan tanpa mengubah kode program.

Ada banyak implementasi ORM, bahkan beberapa untuk setiap bahasa pemrograman. Semuanya mirip, oleh karena itu, untuk kepastian, di masa depan, oleh ORM yang kami maksud adalah perpustakaan yang sesuai (paket) model kelas Model kerangka Django [10] dengan Python [11].

ORM sangat "nyaman" dan programmer tidak benar-benar berpikir bahwa menggunakan API ini mereka tidak hanya mendapatkan keuntungan dari model relasional, tetapi semua kerugiannya. Misalnya, dalam kode itu sendiri, Anda tidak dapat mengganti model tabel - menambah atau menghapus kolom, menambahkan tabel baru, dll. Untuk melakukan migrasi database, Anda harus menulis ulang kode terlebih dahulu, lalu "naik satu lantai lebih tinggi", dan kemudian restart program. Akibatnya, tidak mungkin untuk membuat aplikasi yang memberikan bahkan perubahan paling sederhana pada skema data selama pengoperasian program tanpa mengubah program itu sendiri.

Pengambilan data dalam ORM diimplementasikan menggunakan rantai metode, misalnya, "objects.all ()", "objects.get (...)", "objects.filter (...)" di Django. Sederhana, indah, dan nyaman, tetapi kompleksitas algoritmik apa yang mengeksekusi query SQL yang dihasilkan oleh ORM akan menyebabkan hal ini tidak terlihat oleh mata telanjang.

Ketika seseorang menulis query SQL, diasumsikan bahwa dia berpikir dan memahami biaya sumber daya komputasi. ORM menyamarkan tugas ini.

Hypertable sebagai basis data generasi baru

Kami telah mengembangkan konsep baru, metode, dan cara praktis untuk menggabungkan model basis data relasional dan jaringan dengan keunggulan gagasan ORM - penolakan penggunaan bahasa permintaan khusus, yang memungkinkan kami membuat model dan teknologi basis data baru.

Konsep kuncinya adalah hypertable (GT) - ini adalah basis data sebagai rangkaian hubungan (tabel) yang digunakan:

1. Atribut "relasional" (domain data), nilainya, seperti dalam RDB, adalah bidang bidang dengan data yang ditentukan sendiri untuk kolom tabel terkait
2. Atribut “Jaringan” (tautan domain). Kami akan memanggil mereka ATS - atribut tipe "tautan"

Nilai-nilai bidang PBX di baris tabel adalah referensi eksplisit untuk setiap baris dalam tabel yang termasuk dalam hipertensi.

Konsep hipertensi yang diperkenalkan oleh kami tidak ada hubungannya dengan proyek [13], yang dibatasi pada tahun 2016.

Ada prototipe yang berfungsi - seperangkat alat dengan Python - Hyper Table Management System (HTMS), yang mencakup level berikut (dari atas ke bawah):

• HTed hypertable editor (klien) adalah layanan dukungan teknologi yang diimplementasikan sebagai situs web pada kerangka Django, yang dapat terhubung ke server mana pun dengan hipertensi terlepas dari aplikasi (secara fungsional dekat dengan utilitas PgAdmin untuk PostgeSQL sampai batas tertentu);
• perpustakaan utilitas dan kelas level logika - API untuk membuat database dan memanipulasi data pada level pemrograman aplikasi (menggantikan ORM);
• perpustakaan utilitas dan kelas tingkat fisik bekerja dengan database, di mana utilitas dan kelas tingkat logis didasarkan (bagaimana API dapat digunakan oleh pemrogram sistem yang berpengalaman);
• Kelas kandang, yang dirancang untuk membuat lapisan "virtual" dari akses jarak jauh yang di-cache ke file basis data di sisi klien (aplikasi);
• Server file CageServer - perangkat lunak yang bekerja dalam mode multi-program dan multi-berulir, mengimplementasikan fungsi untuk akses jarak jauh multi-pengguna ke file di server menggunakan protokol TCP.

Pada prinsipnya, alih-alih Cage, dimungkinkan untuk menggunakan subsistem file lokal OS yang biasa untuk mengelola file, serta menggunakan perangkat lunak Cage API dan CageServer sebagai alat HTMS independen untuk menerapkan akses file yang didistribusikan secara jarak jauh pada sistem apa pun.

Dalam artikel mendatang, direncanakan untuk memperkenalkan pembaca ke sistem HTMS secara lebih rinci.