pengenalan
“Kamu harus berlari secepat yang kamu bisa agar tetap di tempat,
dan untuk mencapai suatu tempat, kamu harus berlari setidaknya dua kali lebih cepat!”
(c) Alice di Negeri Ajaib
Beberapa waktu lalu saya diminta memberi ceramah analis perusahaan kami pada topik merancang model data, karena mengerjakan proyek untuk waktu yang lama (terkadang selama beberapa tahun) kami melupakan apa yang terjadi di sekitar kami dalam dunia teknologi TI. Di perusahaan kami (kebetulan) banyak proyek yang tidak menggunakan database NoSQL (setidaknya untuk saat ini), jadi dalam kuliah saya, saya secara terpisah memperhatikannya menggunakan contoh HBase dan mencoba mengarahkan penyajian materi ke proyek tersebut. yang belum pernah menggunakannya telah berhasil. Secara khusus, saya mengilustrasikan beberapa fitur desain model data menggunakan contoh yang saya baca beberapa tahun lalu . Saat menganalisis contoh, saya membandingkan beberapa opsi untuk memecahkan masalah yang sama agar ide utama dapat tersampaikan dengan lebih baik kepada audiens.
Baru-baru ini, “karena tidak ada hubungannya”, saya bertanya pada diri sendiri (akhir pekan panjang di karantina pada bulan Mei sangat kondusif untuk hal ini), seberapa besar kesesuaian perhitungan teoretis dengan praktik? Sebenarnya dari sinilah ide artikel ini lahir. Pengembang yang telah bekerja dengan NoSQL selama beberapa hari mungkin tidak mempelajari sesuatu yang baru darinya (dan karena itu mungkin langsung melewatkan separuh artikel). Tapi untuk analisBagi mereka yang belum pernah bekerja sama dengan NoSQL, saya rasa ini akan berguna untuk mendapatkan pemahaman dasar tentang fitur mendesain model data untuk HBase.
Contoh analisis
Menurut pendapat saya, sebelum Anda mulai menggunakan database NoSQL, Anda perlu berpikir matang dan mempertimbangkan pro dan kontra. Seringkali masalahnya dapat diselesaikan dengan menggunakan DBMS relasional tradisional. Oleh karena itu, sebaiknya jangan menggunakan NoSQL tanpa alasan yang berarti. Jika Anda masih memutuskan untuk menggunakan database NoSQL, Anda harus mempertimbangkan bahwa pendekatan desain di sini agak berbeda. Terutama beberapa di antaranya mungkin tidak biasa bagi mereka yang sebelumnya hanya berurusan dengan DBMS relasional (menurut pengamatan saya). Jadi, dalam dunia “relasional”, kita biasanya memulai dengan memodelkan domain masalah, dan baru kemudian, jika perlu, melakukan denormalisasi model tersebut. Di NoSQL kita harus segera mempertimbangkan skenario yang diharapkan untuk bekerja dengan data dan awalnya mendenormalisasi data. Selain itu, masih ada beberapa perbedaan lainnya yang akan dibahas di bawah ini.
Mari kita pertimbangkan masalah “sintetis” berikut, yang akan terus kita kerjakan:
Penting untuk merancang struktur penyimpanan untuk daftar teman pengguna beberapa jejaring sosial abstrak. Untuk menyederhanakan, kami berasumsi bahwa semua koneksi kami terarah (seperti di Instagram, bukan Linkedin). Strukturnya harus memungkinkan Anda untuk secara efektif:
- Jawab pertanyaan apakah pengguna A membaca pengguna B (pola membaca)
- Izinkan penambahan/penghapusan koneksi jika berlangganan/berhenti berlangganan pengguna A dari pengguna B (templat perubahan data)
Tentu saja, ada banyak pilihan untuk menyelesaikan masalah tersebut. Dalam database relasional biasa, kemungkinan besar kita hanya akan membuat tabel hubungan (mungkin ditandai jika, misalnya, kita perlu menyimpan grup pengguna: keluarga, pekerjaan, dll., yang mencakup “teman” ini), dan untuk mengoptimalkan kecepatan akses akan menambah indeks/partisi. Kemungkinan besar tabel terakhir akan terlihat seperti ini:
user_id
teman_id
Vasya
Petya
Vasya
Olya
selanjutnya, untuk kejelasan dan pemahaman yang lebih baik, saya akan menunjukkan nama, bukan ID
Dalam kasus HBase, kita mengetahui bahwa:
- pencarian efisien yang tidak menghasilkan pemindaian tabel lengkap dapat dilakukan secara eksklusif dengan kunci
- sebenarnya, itulah mengapa menulis kueri SQL yang familiar bagi banyak orang ke database semacam itu adalah ide yang buruk; secara teknis, tentu saja, Anda dapat mengirim kueri SQL dengan Gabungan dan logika lainnya ke HBase dari Impala yang sama, tetapi seberapa efektifnya...
Oleh karena itu, kami terpaksa menggunakan user ID sebagai kuncinya. Dan pemikiran pertama saya tentang topik “di mana dan bagaimana cara menyimpan ID teman?” mungkin ide untuk menyimpannya dalam kolom. Opsi yang paling jelas dan “naif” ini akan terlihat seperti ini (sebut saja Opsi 1 (standar)untuk referensi lebih lanjut):
Kunci Baris
Pembicara
Vasya
1: Petya
2: Olya
3: Dasha
Petya
1: mas
2: Vasya
Di sini, setiap baris berhubungan dengan satu pengguna jaringan. Kolom tersebut memiliki nama: 1, 2, ... - sesuai dengan jumlah teman, dan ID teman disimpan di kolom tersebut. Penting untuk diperhatikan bahwa setiap baris akan memiliki jumlah kolom yang berbeda. Pada contoh gambar di atas, satu baris memiliki tiga kolom (1, 2 dan 3), dan baris kedua hanya memiliki dua (1 dan 2) - di sini kami sendiri menggunakan dua properti HBase yang tidak dimiliki database relasional:
- kemampuan untuk mengubah komposisi kolom secara dinamis (tambah teman -> tambah kolom, hapus teman -> hapus kolom)
- baris yang berbeda mungkin memiliki komposisi kolom yang berbeda
Mari kita periksa struktur kita untuk memenuhi persyaratan tugas:
- Membaca data: untuk memahami apakah Vasya berlangganan Olya, kita perlu menguranginya seluruh lini dengan kunci RowKey = “Vasya” dan urutkan nilai kolom sampai kita “bertemu” Olya di dalamnya. Atau ulangi nilai semua kolom, “tidak bertemu” Olya dan kembalikan jawabannya Salah;
- Mengedit data: menambah teman: untuk tugas serupa kita juga perlu mengurangi seluruh lini menggunakan kunci RowKey = “Vasya” untuk menghitung jumlah total temannya. Jumlah total teman ini kita perlukan untuk menentukan jumlah kolom yang kita perlukan untuk menuliskan ID teman baru tersebut.
- Mengubah data: menghapus teman:
- Perlu mengurangi seluruh lini dengan kunci RowKey = “Vasya” dan urutkan kolom untuk menemukan kolom di mana teman yang akan dihapus dicatat;
- Selanjutnya setelah menghapus teman, kita perlu “menggeser” semua datanya ke dalam satu kolom agar tidak ada “celah” pada penomorannya.
Sekarang mari kita evaluasi seberapa produktif algoritma ini, yang perlu kita terapkan pada sisi “aplikasi bersyarat”, dengan menggunakan . Mari kita nyatakan ukuran jaringan sosial hipotetis kita sebagai n. Maka jumlah maksimal teman yang dapat dimiliki seorang pengguna adalah (n-1). Kita selanjutnya dapat mengabaikan ini (-1) untuk tujuan kita, karena dalam kerangka penggunaan simbol O, hal ini tidak penting.
- Membaca data: perlu untuk mengurangi seluruh baris dan mengulangi semua kolomnya dalam batas. Ini berarti perkiraan biaya tertinggi adalah sekitar O(n)
- Mengedit data: menambah teman: untuk menentukan jumlah teman, Anda perlu mengulangi semua kolom pada baris, lalu menyisipkan kolom baru => O(n)
- Mengubah data: menghapus teman:
- Mirip dengan menambahkan - Anda harus melewati semua kolom di batas => O(n)
- Setelah menghapus kolom, kita perlu “memindahkannya”. Jika Anda menerapkan "langsung" ini, maka dalam batasnya Anda memerlukan hingga (n-1) operasi. Namun di sini dan selanjutnya di bagian praktis kita akan menggunakan pendekatan yang berbeda, yang akan menerapkan "pergeseran semu" untuk sejumlah operasi tetap - yaitu, waktu yang konstan akan dihabiskan untuk itu, terlepas dari n. Waktu yang konstan ini (tepatnya O(2)) dapat diabaikan dibandingkan dengan O(n). Pendekatannya diilustrasikan pada gambar di bawah ini: kita cukup menyalin data dari kolom “terakhir” ke kolom yang ingin kita hapus datanya, lalu menghapus kolom terakhir:
Secara total, di semua skenario kami menerima kompleksitas komputasi asimtotik sebesar O(n).
Anda mungkin sudah memperhatikan bahwa kita hampir selalu harus membaca seluruh baris dari database, dan dalam dua dari tiga kasus, hanya menelusuri semua kolom dan menghitung jumlah total teman. Oleh karena itu, sebagai upaya optimasi, Anda dapat menambahkan kolom “count”, yang menyimpan jumlah total teman setiap pengguna jaringan. Dalam hal ini, kita tidak dapat membaca seluruh baris untuk menghitung jumlah total teman, tetapi hanya membaca satu kolom “hitungan”. Yang penting jangan lupa update “count” saat memanipulasi data. Itu. kita menjadi lebih baik Opsi 2 (hitungan):
Kunci Baris
Pembicara
Vasya
1: Petya
2: Olya
3: Dasha
hitung: 3
Petya
1: mas
2: Vasya
hitung: 2
Dibandingkan dengan opsi pertama:
- Membaca data: untuk mendapatkan jawaban atas pertanyaan “Apakah Vasya membaca Olya?” tidak ada yang berubah => O(n)
- Mengedit data: menambah teman: Kami telah menyederhanakan penyisipan teman baru, karena sekarang kami tidak perlu membaca seluruh baris dan mengulangi kolomnya, tetapi hanya bisa mendapatkan nilai kolom “hitungan”, dll. segera tentukan nomor kolom untuk memasukkan teman baru. Hal ini menyebabkan pengurangan kompleksitas komputasi menjadi O(1)
- Mengubah data: menghapus teman: Saat menghapus teman, kita juga dapat menggunakan kolom ini untuk mengurangi jumlah operasi I/O saat “menggeser” data satu sel ke kiri. Namun kebutuhan untuk mengulangi kolom untuk menemukan kolom yang perlu dihapus masih tetap ada, jadi => O(n)
- Di sisi lain, saat memperbarui data kita perlu memperbarui kolom “hitungan” setiap saat, namun hal ini membutuhkan waktu yang konstan, yang dapat diabaikan dalam kerangka simbol-O.
Secara umum, opsi 2 tampaknya sedikit lebih optimal, namun lebih seperti “evolusi daripada revolusi.” Untuk membuat “revolusi” kita memerlukannya Opsi 3 (kolom).
Mari kita balikkan semuanya: kita akan menugaskannya nama kolom ID pengguna! Apa yang akan ditulis di kolom itu sendiri sudah tidak penting lagi bagi kita, biarlah yang nomor 1 (umumnya yang berguna bisa disimpan di sana, misalnya grup “keluarga/teman/dll.”). Pendekatan ini mungkin mengejutkan “orang awam” yang tidak siap dan tidak memiliki pengalaman sebelumnya bekerja dengan database NoSQL, namun pendekatan inilah yang memungkinkan Anda menggunakan potensi HBase dalam tugas ini dengan lebih efektif:
Kunci Baris
Pembicara
Vasya
Petya: 1
Olya: 1
Dasha: 1
Petya
masya: 1
Vasya: 1
Disini kita mendapatkan beberapa keuntungan sekaligus. Untuk memahaminya, mari kita analisis struktur baru dan memperkirakan kompleksitas komputasinya:
- Membaca data: untuk menjawab pertanyaan apakah Vasya berlangganan Olya cukup membaca satu kolom “Olya”: jika ada maka jawabannya Benar, jika tidak – Salah => O(1)
- Mengedit data: menambah teman: Menambah teman: tambahkan saja kolom baru “ID Teman” => O(1)
- Mengubah data: menghapus teman: hapus saja kolom ID Teman => O(1)
Seperti yang Anda lihat, keuntungan signifikan dari model penyimpanan ini adalah bahwa dalam semua skenario yang kami perlukan, kami beroperasi hanya dengan satu kolom, menghindari membaca seluruh baris dari database dan, terlebih lagi, menghitung semua kolom pada baris ini. Kita bisa berhenti di situ, tapi...
Anda mungkin bingung dan melangkah lebih jauh dalam mengoptimalkan kinerja dan mengurangi operasi I/O saat mengakses database. Bagaimana jika kita menyimpan informasi hubungan lengkap langsung di kunci baris itu sendiri? Artinya, buat komposit kunci seperti userID.friendID? Dalam hal ini, kita bahkan tidak perlu membaca kolom baris sama sekali (Opsi 4 (baris)):
Kunci Baris
Pembicara
Vasya.Petya
Petya: 1
Vasya.Olya
Olya: 1
Vasya.Dasha
Dasha: 1
Petya.Masha
masya: 1
Petya.Vasya
Vasya: 1
Jelasnya, penilaian semua skenario manipulasi data dalam struktur seperti pada versi sebelumnya adalah O(1). Perbedaannya dengan opsi 3 hanya terletak pada efisiensi operasi I/O dalam database.
Nah, “busur” terakhir. Sangat mudah untuk melihat bahwa dalam opsi 4, kunci baris akan memiliki panjang variabel, yang mungkin mempengaruhi kinerja (di sini kita ingat bahwa HBase menyimpan data sebagai kumpulan byte dan baris dalam tabel diurutkan berdasarkan kunci). Selain itu, kami memiliki pemisah yang mungkin perlu ditangani dalam beberapa skenario. Untuk menghilangkan pengaruh ini, Anda dapat menggunakan hash dari userID dan friendsID, dan karena kedua hash memiliki panjang yang konstan, Anda cukup menggabungkannya, tanpa pemisah. Maka data pada tabel akan terlihat seperti ini (Opsi 5 (hash)):
Kunci Baris
Pembicara
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olya: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
masya: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: 1
Jelasnya, kompleksitas algoritmik bekerja dengan struktur seperti itu dalam skenario yang kami pertimbangkan akan sama dengan opsi 4 - yaitu, O(1).
Secara total, mari kita rangkum semua perkiraan kompleksitas komputasi dalam satu tabel:
Menambahkan teman
Memeriksa teman
Menghapus teman
Opsi 1 (standar)
O (n)
O (n)
O (n)
Opsi 2 (hitungan)
O (1)
O (n)
O (n)
Opsi 3 (kolom)
O (1)
O (1)
O (1)
Opsi 4 (baris)
O (1)
O (1)
O (1)
Opsi 5 (hash)
O (1)
O (1)
O (1)
Seperti yang Anda lihat, opsi 3-5 tampaknya paling disukai dan secara teoritis memastikan pelaksanaan semua skenario manipulasi data yang diperlukan dalam waktu yang konstan. Dalam kondisi tugas kita, tidak ada persyaratan eksplisit untuk mendapatkan daftar semua teman pengguna, namun dalam aktivitas proyek nyata, akan lebih baik bagi kita, sebagai analis yang baik, untuk "mengantisipasi" bahwa tugas seperti itu mungkin muncul dan “sebarkan sedotan.” Oleh karena itu, simpati saya ada pada opsi 3. Tetapi kemungkinan besar dalam proyek nyata permintaan ini dapat diselesaikan dengan cara lain, oleh karena itu, tanpa gambaran umum tentang keseluruhan masalah, lebih baik tidak membuat kesimpulan akhir.
Persiapan percobaan
Saya ingin menguji argumen teoretis di atas dalam praktik - inilah tujuan dari gagasan yang muncul selama akhir pekan panjang. Untuk melakukan ini, perlu untuk mengevaluasi kecepatan operasi "aplikasi bersyarat" kami dalam semua skenario penggunaan database yang dijelaskan, serta peningkatan waktu ini seiring dengan bertambahnya ukuran jaringan sosial (n). Parameter target yang menarik minat kami dan yang akan kami ukur selama percobaan adalah waktu yang dihabiskan oleh “aplikasi bersyarat” untuk melakukan satu “operasi bisnis”. Yang kami maksud dengan “transaksi bisnis” adalah salah satu dari hal berikut:
- Menambahkan satu teman baru
- Memeriksa apakah Pengguna A adalah teman Pengguna B
- Menghapus satu teman
Oleh karena itu, dengan mempertimbangkan persyaratan yang diuraikan dalam pernyataan awal, skenario verifikasi muncul sebagai berikut:
- Perekaman data. Secara acak menghasilkan jaringan awal berukuran n. Untuk lebih dekat dengan “dunia nyata”, jumlah teman yang dimiliki setiap pengguna juga merupakan variabel acak. Ukur waktu selama “aplikasi bersyarat” kami menulis semua data yang dihasilkan ke HBase. Kemudian bagi waktu yang dihasilkan dengan jumlah total teman yang ditambahkan - ini adalah bagaimana kita mendapatkan waktu rata-rata untuk satu “operasi bisnis”
- Membaca data. Untuk setiap pengguna, buatlah daftar "kepribadian" yang Anda perlukan untuk mendapatkan jawabannya apakah pengguna tersebut berlangganan atau tidak. Panjang daftar = kira-kira jumlah teman pengguna, dan untuk separuh teman yang diperiksa jawabannya harus “Ya”, dan untuk separuh lainnya – “Tidak”. Pemeriksaan dilakukan sedemikian rupa sehingga jawaban “Ya” dan “Tidak” bergantian (yaitu, dalam setiap kasus kedua kita harus melewati semua kolom pada baris untuk opsi 1 dan 2). Total waktu penyaringan kemudian dibagi dengan jumlah teman yang diuji untuk mendapatkan rata-rata waktu penyaringan per subjek.
- Penghapusan Data. Hapus semua teman dari pengguna. Selain itu, urutan penghapusannya acak (yaitu, kami “mengacak” daftar asli yang digunakan untuk mencatat data). Total waktu pengecekan kemudian dibagi dengan jumlah teman yang dihapus untuk memperoleh waktu rata-rata per pengecekan.
Skenario perlu dijalankan untuk masing-masing dari 5 opsi model data dan untuk ukuran jaringan sosial yang berbeda untuk melihat bagaimana waktu berubah seiring pertumbuhannya. Dalam satu n, koneksi dalam jaringan dan daftar pengguna yang akan diperiksa, tentu saja, harus sama untuk kelima opsi tersebut.
Untuk pemahaman yang lebih baik, di bawah ini adalah contoh data yang dihasilkan untuk n= 5. “Generator” tertulis menghasilkan tiga kamus ID sebagai keluaran:
- yang pertama adalah untuk dimasukkan
- yang kedua adalah untuk memeriksa
- ketiga – untuk dihapus
{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей
{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов
{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей
Seperti yang Anda lihat, semua ID yang lebih besar dari 10 dalam kamus untuk diperiksa adalah ID yang pasti akan memberikan jawaban Salah. Memasukkan, memeriksa dan menghapus “teman” dilakukan persis dalam urutan yang ditentukan dalam kamus.
Percobaan dilakukan pada laptop yang menjalankan Windows 10, dimana HBase berjalan di satu container Docker, dan Python dengan Jupyter Notebook berjalan di container lainnya. Docker dialokasikan 2 core CPU dan 2 GB RAM. Semua logika, baik emulasi “aplikasi bersyarat” dan “perpipaan” untuk menghasilkan data pengujian dan mengukur waktu, ditulis dengan Python. Perpustakaan digunakan untuk bekerja dengan HBase , untuk menghitung hash (MD5) untuk opsi 5 - hashlib
Dengan mempertimbangkan kekuatan komputasi laptop tertentu, peluncuran untuk n = 10, 30,… dipilih secara eksperimental. 170 – ketika total waktu pengoperasian siklus pengujian penuh (semua skenario untuk semua opsi untuk semua n) bahkan lebih atau kurang masuk akal dan sesuai untuk satu pesta teh (rata-rata 15 menit).
Di sini perlu dicatat bahwa dalam percobaan ini kami tidak mengevaluasi angka kinerja absolut. Bahkan perbandingan relatif antara dua pilihan yang berbeda mungkin tidak sepenuhnya benar. Sekarang kita tertarik pada sifat perubahan waktu yang bergantung pada n, karena dengan mempertimbangkan konfigurasi “tempat uji” di atas, sangat sulit untuk mendapatkan perkiraan waktu yang “dibersihkan” dari pengaruh faktor acak dan faktor lainnya ( dan tugas seperti itu tidak ditetapkan).
Hasil percobaan
Tes pertama adalah bagaimana waktu yang dihabiskan untuk mengisi daftar teman berubah. Hasilnya ada pada grafik di bawah ini.
Opsi 3-5, seperti yang diharapkan, menunjukkan waktu “transaksi bisnis” yang hampir konstan, yang tidak bergantung pada pertumbuhan ukuran jaringan dan perbedaan kinerja yang tidak dapat dibedakan.
Opsi 2 juga menunjukkan kinerja yang konstan, tetapi sedikit lebih buruk, hampir persis 2 kali lipat dibandingkan opsi 3-5. Dan ini merupakan kabar baik, karena berkorelasi dengan teori - dalam versi ini jumlah operasi I/O ke/dari HBase tepat 2 kali lebih besar. Hal ini dapat menjadi bukti tidak langsung bahwa bangku tes kami, pada prinsipnya, memberikan akurasi yang baik.
Opsi 1 juga, seperti yang diharapkan, ternyata menjadi yang paling lambat dan menunjukkan peningkatan linier dalam waktu yang dihabiskan untuk menambahkan satu sama lain ke dalam ukuran jaringan.
Sekarang mari kita lihat hasil tes kedua.
Opsi 3-5 kembali berperilaku seperti yang diharapkan - waktu konstan, tidak bergantung pada ukuran jaringan. Opsi 1 dan 2 menunjukkan peningkatan waktu linier seiring dengan peningkatan ukuran jaringan dan kinerja serupa. Selain itu, opsi 2 ternyata sedikit lebih lambat - tampaknya karena kebutuhan untuk mengoreksi dan memproses kolom "hitungan" tambahan, yang menjadi lebih terlihat seiring bertambahnya n. Namun saya tetap menahan diri untuk tidak menarik kesimpulan apa pun, karena keakuratan perbandingan ini relatif rendah. Selain itu, rasio-rasio ini (pilihan mana, 1 atau 2, yang lebih cepat) berubah dari satu lari ke lari lainnya (sambil mempertahankan sifat ketergantungan dan “berhadap-hadapan”).
Nah, grafik terakhir merupakan hasil pengujian penghapusan.
Sekali lagi, tidak ada kejutan di sini. Opsi 3-5 melakukan penghapusan dalam waktu yang konstan.
Selain itu, menariknya, opsi 4 dan 5, tidak seperti skenario sebelumnya, menunjukkan kinerja yang sedikit lebih buruk daripada opsi 3. Rupanya, operasi penghapusan baris lebih mahal daripada operasi penghapusan kolom, yang umumnya logis.
Opsi 1 dan 2, seperti yang diharapkan, menunjukkan peningkatan waktu secara linier. Pada saat yang sama, opsi 2 secara konsisten lebih lambat dibandingkan opsi 1 - karena operasi I/O tambahan untuk "mempertahankan" kolom penghitungan.
Kesimpulan umum dari percobaan:
- Opsi 3-5 menunjukkan efisiensi yang lebih besar karena memanfaatkan HBase; Selain itu, kinerjanya berbeda satu sama lain secara konstan dan tidak bergantung pada ukuran jaringan.
- Perbedaan antara opsi 4 dan 5 tidak dicatat. Namun bukan berarti opsi 5 tidak boleh digunakan. Kemungkinan besar skenario eksperimental yang digunakan, dengan mempertimbangkan karakteristik kinerja bangku tes, tidak memungkinkan untuk mendeteksinya.
- Sifat peningkatan waktu yang diperlukan untuk melakukan “operasi bisnis” dengan data secara umum menegaskan perhitungan teoretis yang diperoleh sebelumnya untuk semua opsi.
Bagian terakhir dr suatu karya sastra
Eksperimen kasar yang dilakukan tidak boleh dianggap sebagai kebenaran mutlak. Ada banyak faktor yang tidak diperhitungkan dan mengubah hasil (fluktuasi ini terutama terlihat pada grafik dengan ukuran jaringan kecil). Misalnya kecepatan penghematan yang digunakan oleh happybase, volume dan metode implementasi logika yang saya tulis dengan Python (saya tidak dapat mengklaim bahwa kode tersebut ditulis secara optimal dan efektif menggunakan kemampuan semua komponen), mungkin fitur caching HBase, aktivitas latar belakang Windows 10 di laptop saya, dll. Secara umum, kita dapat berasumsi bahwa semua perhitungan teoretis telah menunjukkan validitasnya secara eksperimental. Ya, atau setidaknya tidak mungkin untuk membantahnya dengan “serangan langsung” seperti itu.
Kesimpulannya, rekomendasi untuk semua orang yang baru mulai merancang model data di HBase: abstrak dari pengalaman sebelumnya bekerja dengan database relasional dan ingat “perintah”:
- Saat mendesain, kami melanjutkan dari tugas dan pola manipulasi data, dan bukan dari model domain
- Akses efisien (tanpa pemindaian tabel lengkap) – hanya dengan kunci
- Denormalisasi
- Baris yang berbeda dapat berisi kolom yang berbeda
- Komposisi speaker yang dinamis
Sumber: www.habr.com