Baru-baru ini, kami menguji pendekatan yang kami sebut QDM ketika bekerja dengan sejumlah besar data - ratusan gigabyte. Sebagai bagian dari tugas, kami memproses 12-24 juta catatan dan membandingkan kinerja solusi kuintet dengan fungsionalitas serupa di tabel biasa.
Kami tidak membuat penemuan baru, tetapi mengkonfirmasi hipotesis yang kami sebutkan sebelumnya: seberapa banyak perancang universal di tangan "teko" bersyarat kehilangan ke database yang dikonfigurasi secara profesional.
Kami juga sekarang tahu apa yang harus dilakukan dalam situasi seperti itu - solusinya cukup sederhana dan dapat diandalkan, dan kami memiliki pengalaman dalam mengatur solusi kompromi untuk data besar yang sewenang-wenang.
Selama pengembangan sistem untuk rekonsiliasi laporan, kami perlu mengunduh data dari salah satu formulir pelaporan, yang berisi hingga 24 juta catatan pada setiap tanggal pelaporan. Seharusnya ada data selama 7 tahun perhitungan harian. Volume, terus terang, bukan untuk perancang universal, tetapi untuk sistem yang sangat khusus, tetapi kami sudah terlibat dalam usaha ini dan kami harus mencari solusi.
Pengguna bekerja dengan kumpulan data besar ini hanya dalam satu tanggal pelaporan, oleh karena itu, dalam sistem referensi, semua ini disimpan dalam tabel yang dipartisi oleh tanggal ini. Indeks untuk 26 bidang data yang tersisa tidak digunakan untuk formulir ini.
Hal pertama yang kami lakukan, tentu saja, adalah membuat struktur data yang diinginkan dalam konstruktor dan memuat beberapa tanggal di sana. Mengunduh salah satu tanggal terkecil membutuhkan waktu sekitar 14 jam, yang terlalu lama: 12,5 juta catatan dengan 27 atribut, dimasukkan ke dalam setengah miliar rekaman dari 5 bidang dengan konstruksi tiga indeks, dua di antaranya adalah komposit.
Jumlah total data ini pada disk sedikit lebih dari 18 GB.
Perlu diperhatikan dua fitur dari formulir ini:
- Hampir tidak cocok dengan normalisasi, sebaliknya, misalnya, dari Formulir 110, dibahas dalam publikasi sebelumnya
- Itu tidak menggunakan indeks pada atribut catatan - itu lebih menguntungkan bagi pengguna untuk menunggu sebentar daripada menghabiskan uang untuk indeks
Ini bisa dikatakan kasus paling radikal yang bisa Anda pilih untuk perbandingan. Dalam kebanyakan kasus, perbedaan volume data QDM dan database biasa tidak begitu dramatis, atau bahkan sangat kecil .
Sebagai perbandingan, data yang sama dimuat ke tabel biasa dalam database relasional membutuhkan 2,3 GB (8 kali lebih sedikit) bersama dengan indeks berdasarkan tanggal, dan pemuatannya berlangsung kurang dari setengah jam (28 kali lebih cepat). Dalam kedua kasus, data dimasukkan langsung dari file dalam porsi 100 ribu catatan, tanpa menonaktifkan indeks.
Mengingat bahwa tidak praktis untuk menggunakan konstruktor untuk volume data seperti itu, kami tetap melakukan tes kinerja: untuk kasus yang berbeda, kami membandingkan pemrosesan catatan secara massal dengan konstruktor dan tabel kami yang tidak diindeks. Kami perlu menentukan batas jumlah data yang akan kami gunakan untuk tabel selanjutnya, dan bukan konstruktor kami.
Seperti yang kami harapkan, bekerja dengan set data kecil, misalnya, pada akun atau klien terpisah, di perancang terlihat cukup nyaman (waktu respons dalam sedetik), berbeda dengan tabel tanpa indeks, di mana Anda harus menunggu beberapa menit untuk merespons. Pada saat yang sama, tugas utama aplikasi - pengambilan sampel massal dan agregasi data di berbagai bagian - dapat memakan waktu beberapa kali lebih lama pada perancang.
Di bawah ini adalah hasil ringkasan dari sampel yang kami buat untuk peningkatan bertahap data agregat:
Di mana dimungkinkan, kami melakukan beberapa pengukuran, setelah memilih statistik dan memilih jumlah catatan dengan mask nomor akun.
Tabel dan grafik di bawah ini menunjukkan bahwa agregasi dari set data yang lengkap dalam sehari membutuhkan waktu yang jauh lebih sedikit daripada mengambil sampel lebih dari 5% dari data menggunakan indeks. Itulah sebabnya pengoptimal permintaan RDBMS mengabaikan indeks dalam situasi seperti itu, sementara mesin layanan kami saat ini kehilangan kesempatan seperti itu.
Tampilan grafis dari hasil yang sama menggunakan skala logaritmik untuk membandingkan jumlah pesanan yang berbeda:
Kecepatan perancang saat memproses kumpulan data lengkap hampir merupakan urutan besarnya lebih rendah dari pada tabel biasa, yang cukup normal untuk perancang - penting untuk menghindari penurunan kinerja seperti longsoran salju, dan tujuan ini telah tercapai.
Studi ini menunjukkan bahwa jumlah catatan dalam database praktis tidak berpengaruh pada kecepatan membangun halaman, navigasi dan sampel kecil dalam model data kuintet. Dengan jumlah data yang diproses hingga 10.000 catatan (dan ini adalah pilihan maksimum dari data terkait untuk sebuah instance dari setiap entitas bisnis dalam sistem informasi), Anda dapat bekerja dengan nyaman dengan database ratusan gigabyte atau lebih.
Selanjutnya, kami mengajarkan plugin tabel kami (dijelaskan di sini ) untuk memanggil konektor ke database arbitrer sehingga bekerja secara transparan dengan model data kuintet dan tabel tradisional.
Dari sudut pandang pengguna, ia tidak peduli sumber data apa yang ia gunakan saat ia dapat melakukan pekerjaan penting untuknya di antarmuka yang sudah dikenalnya, menerima laporannya:
Sekarang kita akan mengambil tabel besar serupa yang tersisa, yang dalam database kami hanya dua lusin dari ratusan, dalam penyimpanan terpisah untuk bekerja dengan nyaman.
Jadi, kita dapat menggunakan konstruktor untuk tabel kecil dan menengah yang memerlukan pencarian intensif dan agregasi dengan atribut arbitrer, dan menyimpan objek non-indeks besar dalam tabel tradisional datar, memanggilnya dari penyimpanan pihak ketiga atau database khusus (Hadoop dan NoSQL lainnya).
Perancang paling cocok untuk sistem CRM dan produk serupa, di mana pengguna bekerja dengan satu klien, akun atau entitas lain, dan fungsi analitis dipindahkan ke penyimpanan khusus yang terpisah.