Perkenalan
Data datang dalam segala bentuk dan ukuran, dan dapat digunakan untuk berbagai tujuan. Banyak organisasi menggunakan database relasional untuk menyimpan data ini. Namun, model relasional mungkin bukan struktur yang paling tepat. Format data mungkin terlalu bervariasi untuk dengan mudah memodelkan sebagai satu set tabel relasional. Misalnya, data mungkin berisi item seperti video, audio, gambar, informasi temporal, volume besar teks gratis, atau jenis data lain yang tidak relasional secara inheren. Selain itu, persyaratan pemrosesan data mungkin tidak paling cocok dengan mencoba mengubah data ini ke dalam format relasional. Dalam situasi ini, mungkin lebih baik menggunakan repositori non-relasional yang dapat menyimpan data dalam format aslinya, tetapi yang memungkinkan penyimpanan cepat dan akses pengambilan ke data ini.
Misalkan Anda seorang insinyur data yang bekerja di Contoso, sebuah organisasi dengan operasi manufaktur besar. Organisasi harus mengumpulkan dan menyimpan informasi dari berbagai sumber, seperti data real-time yang memantau status mesin lini produksi, data kontrol kualitas produk, log produksi historis, volume produk dalam stok, dan data persediaan bahan baku. Informasi ini sangat penting untuk operasi organisasi. Anda telah diminta untuk menentukan cara terbaik untuk menyimpan informasi ini, sehingga dapat disimpan dengan cepat, dan mudah ditanyakan.
Jelajahi karakteristik data non-relasional
Database relasional adalah alat yang sangat baik untuk menyimpan dan mengambil data yang memiliki struktur terkenal, yang berisi bidang yang dapat Anda tentukan sebelumnya. Dalam beberapa situasi, Anda mungkin tidak memiliki pengetahuan yang diperlukan tentang struktur data Anda, sebelum tiba di database Anda, untuk merekamnya sebagai satu set baris dan kolom yang rapi dalam format tabular. Ini adalah skenario umum dalam sistem yang mengkonsumsi data dari berbagai sumber, seperti pipa konsumsi data. Dalam situasi ini, database non-relasional dapat terbukti sangat berguna.
Dalam unit ini, Anda akan melihat lebih detail pada karakteristik umum database non-relasional. Anda akan belajar bagaimana mereka memungkinkan Anda untuk menangkap data dengan cepat, dan memodelkan data yang dapat bervariasi dalam struktur.
Apa karakteristik data non-relasional?
Anda menggunakan database untuk memodelkan beberapa aspek dunia nyata. Entitas di dunia nyata sering memiliki struktur yang sangat bervariasi. Misalnya, dalam database e-commerce yang menyimpan informasi tentang pelanggan, berapa banyak nomor telepon yang dimiliki pelanggan? Pelanggan mungkin memiliki telepon rumah dan nomor ponsel, tetapi beberapa pelanggan mungkin memiliki nomor bisnis, nomor rumah tambahan, dan mungkin beberapa nomor ponsel. Demikian pula, alamat pelanggan mungkin tidak selalu mengikuti format yang sama; Alamat untuk pelanggan di berbagai negara bagian dan wilayah mungkin berisi elemen yang berbeda, seperti kode pos atau kode pos.
Dalam skenario lain, jika Anda menelan data dengan cepat, Anda ingin menangkap data dan menyimpannya dengan sangat cepat. Memproses data dan memanipulasinya menjadi satu set baris dalam tabel yang berbeda dalam database relasional mungkin tidak sesuai pada saat ini; Anda dapat melakukan tugas-tugas ini di kemudian hari. Pada saat konsumsi, Anda hanya perlu menyimpan data dalam keadaan dan format aslinya.
Aspek kunci dari database non-relasional adalah bahwa mereka memungkinkan Anda untuk menyimpan data dengan cara yang sangat fleksibel. Database non-relasional tidak memaksakan skema pada data. Sebaliknya, mereka fokus pada data itu sendiri daripada bagaimana menyusunnya. Pendekatan ini berarti Bahwa Anda dapat menyimpan informasi dalam format alami, yang mencerminkan cara di mana Anda akan mengkonsumsi, query dan menggunakannya.
Dalam sistem non-relasional, Anda menyimpan informasi untuk entitas dalam koleksi atau wadah daripada tabel relasional. Dua entitas dalam koleksi yang sama dapat memiliki satu set bidang yang berbeda daripada satu set kolom biasa yang ditemukan dalam tabel relasional. Kurangnya skema tetap berarti bahwa setiap entitas harus menggambarkan diri sendiri. Seringkali ini dicapai dengan memberi label setiap bidang dengan nama data yang diwakilinya. Misalnya, kumpulan entitas pelanggan non-relasional mungkin terlihat seperti ini:
## Customer 1
ID: 1
Name: Mark Hanson
Telephone: [ Home: 1-999-9999999, Business: 1-888-8888888, Cell: 1-777-7777777 ]
Address: [ Home: 121 Main Street, Some City, NY, 10110,
Business: 87 Big Building, Some City, NY, 10111 ]
## Customer 2
ID: 2
Title: Mr
Name: Jeff Hay
Telephone: [ Home: 0044-1999-333333, Mobile: 0044-17545-444444 ]
Address: [ UK: 86 High Street, Some Town, A County, GL8888, UK,
US: 777 7th Street, Another City, CA, 90111 ]
Dalam contoh ini, bidang diawali dengan nama. Fields mungkin juga memiliki beberapa subbidang, juga dengan nama. Dalam contoh, beberapa subbidang dilambangkan dengan melampirkan mereka antara tanda kurung siku.
Menambahkan pelanggan baru adalah masalah memasukkan entitas dengan bidangnya diberi label dengan cara yang berarti. Aplikasi yang meminta data ini harus disiapkan untuk mengurai informasi dalam entitas yang diambilnya.
Kemampuan pengambilan data dari database non-relasional dapat bervariasi. Setiap entitas harus memiliki nilai kunci yang unik. Entitas dalam koleksi biasanya disimpan dalam urutan nilai kunci. Pada contoh di atas, kunci uniknya adalah bidang ID. Jenis database non-relasional yang paling sederhana memungkinkan aplikasi untuk menentukan kunci unik, atau berbagai kunci sebagai kriteria kueri. Dalam contoh pelanggan, database akan memungkinkan aplikasi untuk query pelanggan dengan ID saja. Memfilter data pada bidang lain akan memerlukan pemindaian seluruh kumpulan entitas, mengurai setiap entitas secara bergantian, dan kemudian menerapkan kriteria kueri apa pun ke setiap entitas untuk menemukan kecocokan apa pun. Dalam contoh di bawah ini, kueri yang mengambil rincian pelanggan berdasarkan ID dapat dengan cepat mengidentifikasi entitas mana yang akan diambil. Sebuah pertanyaan yang mencoba untuk menemukan semua pelanggan dengan alamat Inggris harus iterasi melalui setiap entitas, dan untuk setiap entitas memeriksa setiap bidang secara bergantian. Jika database berisi jutaan entitas, kueri ini bisa memakan waktu cukup lama untuk dijalankan.
Sistem non-relasional yang lebih maju mendukung pengindeksan, dengan cara yang mirip dengan indeks dalam database relasional. Kueri kemudian dapat menggunakan indeks untuk mengidentifikasi dan mengambil data berdasarkan bidang non-kunci. Sistem non-relasional seperti Azure Cosmos DB (sistem manajemen basis data non-relasional yang tersedia di Azure), pengindeksan dukungan bahkan ketika struktur data yang diindeks dapat bervariasi dari catatan ke catatan. Untuk informasi lebih lanjut, baca Pengindeksan di Azure Cosmos DB - Gambaran Umum.
Ketika Anda merancang database non-relasional, penting untuk memahami kemampuan sistem manajemen database dan jenis kueri yang harus didukungnya.
Mengidentifikasi kasus penggunaan database non-relasional
Database non-relasional sangat cocok untuk skenario berikut:
IoT dan telematika. Sistem ini biasanya menelan sejumlah besar data dalam semburan aktivitas yang sering terjadi. Database non-relasional dapat menyimpan informasi ini dengan sangat cepat. Data kemudian dapat digunakan oleh layanan analitik seperti Azure Machine Learning, Azure HDInsight, dan Microsoft Power BI. Selain itu, Anda dapat memproses data secara real-time menggunakan Azure Functions yang dipicu saat data tiba di database.
Ritel dan pemasaran. Microsoft menggunakan CosmosDB untuk platform e-commerce sendiri yang berjalan sebagai bagian dari Windows Store dan Xbox Live. Ini juga digunakan dalam industri ritel untuk menyimpan data katalog dan untuk sumber acara dalam memproses pipa.
Game. Tingkat database adalah komponen penting dari aplikasi game. Game modern melakukan pemrosesan grafis pada klien seluler / konsol, tetapi mengandalkan cloud untuk memberikan konten yang disesuaikan dan dipersonalisasi seperti statistik dalam game, integrasi media sosial, dan papan peringkat tinggi. Permainan sering membutuhkan latencies satu milidetik untuk dibaca dan ditulis untuk memberikan pengalaman dalam game yang menarik. Database game harus cepat dan dapat menangani lonjakan besar dalam tingkat permintaan selama peluncuran game baru dan pembaruan fitur.
Aplikasi web dan seluler. Database non-relasional seperti Azure Cosmos DB umumnya digunakan dalam aplikasi web dan seluler, dan sangat cocok untuk memodelkan interaksi sosial, berintegrasi dengan layanan pihak ketiga, dan untuk membangun pengalaman pribadi yang kaya. SDK Cosmos DB (perangkat lunak pengembangan kit) dapat digunakan untuk membangun aplikasi iOS dan Android yang kaya menggunakan kerangka kerja Xamarin yang populer.
Database relasional merestrukturisasi data ke dalam format tetap yang dirancang untuk menjawab pertanyaan tertentu. Ketika data perlu dicerna dengan sangat cepat, atau kueri tidak diketahui dan tidak dibatasi, database relasional bisa kurang cocok daripada database non-relasional.
Jelaskan jenis data non-relasional
Data non-relasional umumnya termasuk dalam dua kategori; semi-terstruktur dan tidak terstruktur. Di unit ini, Anda akan belajar tentang apa arti istilah-istilah ini, dan melihat beberapa contoh.
Apa itu data semi-terstruktur?
Data semi-terstruktur adalah data yang berisi bidang. Bidang tidak harus sama di setiap entitas. Anda hanya menentukan bidang yang Anda butuhkan berdasarkan per entitas. Entitas Pelanggan yang ditunjukkan pada unit sebelumnya adalah contoh data semi-terstruktur. Data harus diformat sedemikian rupa sehingga aplikasi dapat mengurai dan memprosesnya. Salah satu cara umum untuk melakukan ini adalah dengan menyimpan data untuk setiap entitas sebagai dokumen JSON. Istilah JSON adalah singkatan dari JavaScript Object Notation; Ini adalah format yang digunakan oleh aplikasi JavaScript untuk menyimpan data dalam memori, tetapi juga dapat digunakan untuk membaca dan menulis dokumen ke dan dari file.
Dokumen JSON dilampirkan dalam tanda kurung keriting ({ dan }). Setiap bidang memiliki nama (label), diikuti oleh titik dua, dan kemudian nilai bidang. Bidang dapat berisi nilai-nilai sederhana, atau subkumenmenial (masing-masing dimulai dan diakhiri dengan tanda kurung keriting). Bidang juga dapat memiliki beberapa nilai, dipegang sebagai array dan dikelilingi dengan tanda kurung siku ([dan]). Literal, atau nilai tetap, dalam bidang dilampirkan dalam tanda kutip, dan bidang dipisahkan dengan koma.
Contoh di bawah ini menunjukkan pelanggan dari unit sebelumnya, diformat sebagai dokumen JSON:
{
"ID": "1",
"Name": "Mark Hanson",
"Telephone": [
{ "Home": "1-999-9999999" },
{ "Business": "1-888-8888888" },
{ "Cell": "1-777-7777777" }
],
"Address": [
{ "Home": [
{ "StreetAddress": "121 Main Street" },
{ "City": "Some City" },
{ "State": "NY" },
{ "Zip": "10110" }
] },
{ "Business": [
{ "StreetAddress": "87 Big Building" },
{ "City": "Some City" },
{ "State": "NY" },
{ "Zip": "10111" }
] }
]
}
{
"ID": "2",
"Title": "Mr",
"Name": "Jeff Hay",
"Telephone": [
{ "Home": "0044-1999-333333" },
{ "Mobile": "0044-17545-444444" }
],
"Address": [
{ "UK": [
{ "StreetAddress": "86 High Street" },
{ "Town": "Some Town" },
{ "County": "A County" },
{ "Postcode": "GL8888" },
{ "Region": "UK" }
] },
{ "US": [
{ "StreetAddress": "777 7th Street" },
{ "City": "Another City" },
{ "State": "CA" },
{ "Zip": "90111" }
] }
]
}
Anda bebas untuk menentukan bidang apa pun yang Anda suka. Poin penting adalah bahwa data mengikuti tata bahasa JSON. Ketika sebuah aplikasi membaca dokumen, ia dapat menggunakan parser JSON untuk memecah dokumen menjadi bidang komponennya dan mengekstrak potongan data individual.
Format lain yang mungkin Anda lihat termasuk Avro, ORC,dan Parquet:
- Avro adalah format berbasis baris. Dibuat oleh Apache. Setiap catatan berisi header yang menggambarkan struktur data dalam catatan. Header ini disimpan sebagai JSON. Data disimpan sebagai informasi biner. Aplikasi menggunakan informasi di header untuk mengurai data biner dan mengekstrak bidang yang dikandungnya. Avro adalah format yang sangat baik untuk mengompresi data dan meminimalkan kebutuhan penyimpanan dan bandwidth jaringan. Contoh ini adalah subset dari informasi header untuk contoh sebelumnya, diformat sebagai Avro:
{
"type": "record",
"name": "contact_schema",
"fields": [
{
"name": "id",
"type": "int",
"doc": "ID of the contact"
},
{
"name": "name",
"type": "string",
"doc": "Name of the contact"
},
{
"name": "telephone",
"type": [
"null",
{
"type": "array",
"items": {
"type": "record",
"name": "contact_schema.telephone",
"fields": [
{
"name": "phoneid",
"type": "int"
},
{
"name": "phonetype",
"type": [ "null", "string" ]
}
]
}
}
]
}
]
}
ORC (format Kolomar Baris Yang Dioptimalkan) mengatur data ke dalam kolom daripada baris. Ini dikembangkan oleh HortonWorks untuk mengoptimalkan operasi baca dan tulis di Apache Hive. Hive adalah sistem gudang data yang mendukung ringkasan data cepat dan query atas dataset yang sangat besar. Hive mendukung kueri seperti SQL atas data yang tidak terstruktur. File ORC berisi garis-garis data. Setiap garis menyimpan data untuk kolom atau kumpulan kolom. Garis berisi indeks ke dalam baris di garis, data untuk setiap baris, dan footer yang menyimpan informasi statistik (hitung, jumlah, maks, min, dan sebagainya) untuk setiap kolom.
Parquet adalah format data kolum lainnya. Ini dibuat oleh Cloudera dan Twitter. File Parket berisi grup baris. Data untuk setiap kolom disimpan bersama dalam grup baris yang sama. Setiap grup baris berisi satu atau lebih potongan data. File Parkquet menyertakan metadata yang menggambarkan kumpulan baris yang ditemukan di setiap bagian. Aplikasi dapat menggunakan metadata ini untuk dengan cepat menemukan potongan yang benar untuk satu set baris tertentu, dan mengambil data dalam kolom yang ditentukan untuk baris ini. Parkquet mengkhususkan diri dalam menyimpan dan memproses jenis data bersarang secara efisien. Ini mendukung skema kompresi dan pengkodean yang sangat efisien.
Apa itu data yang tidak terstruktur?
Data tidak terstruktur adalah data yang secara alami tidak mengandung bidang. Contohnya termasuk video, audio, dan aliran media lainnya. Setiap item adalah gumpalan amorf dari data biner. Anda tidak dapat mencari elemen tertentu dalam data ini.
Anda dapat memilih untuk menyimpan data seperti ini dalam penyimpanan yang dirancang khusus untuk tujuan tersebut. Di Azure, Anda mungkin akan menyimpan data video dan audio sebagai gumpalan blok di akun Azure Storage. (Istilah gumpalan adalah singkatan dari Binary Large Object *). Gumpalan blok hanya mendukung operasi baca dan tulis dasar.
Anda juga dapat mempertimbangkan file sebagai bentuk data yang tidak terstruktur, meskipun dalam beberapa kasus file mungkin menyertakan metadata yang menunjukkan jenis file itu (foto, dokumen Word, spreadsheet Excel, dan sebagainya), pemilik, dan elemen lain yang dapat disimpan sebagai bidang. Namun, konten utama file tidak terstruktur.
Jelaskan jenis database non-relasional dan NoSQL
Data non-relasional adalah istilah yang mencakup semua yang berarti apa pun yang tidak terstruktur sebagai satu set tabel. Ada banyak jenis data non-terstruktur, dan informasi digunakan untuk berbagai tujuan. Akibatnya, ada banyak jenis sistem manajemen database non-relasional, masing-masing berorientasi pada serangkaian skenario tertentu.
Dalam unit ini, Anda akan belajar tentang beberapa jenis database non-relasional yang paling umum.
Apa itu NoSQL?
Anda mungkin melihat istilah NoSQL saat membaca tentang database non-relasional. NoSQL adalah istilah yang agak longgar yang berarti non-relasional. Ada beberapa perdebatan tentang apakah itu dimaksudkan untuk menyiratkan Tidak SQL,atau Tidak Hanya SQL; beberapa database non-relasional mendukung versi SQL disesuaikan untuk dokumen daripada tabel (contoh termasuk Azure Cosmos DB).
Database NoSQL (non-relasional) umumnya termasuk dalam empat kategori: toko nilai kunci, database dokumen, database keluarga kolom, dan database grafik. Bagian berikut membahas jenis database NoSQL ini.
Apa itu toko nilai kunci?
Toko nilai kunci adalah jenis database NoSQL yang paling sederhana (dan sering tercepat) untuk memasukkan dan meminta data. Setiap item data di toko nilai kunci memiliki dua elemen, kunci dan nilai. Kunci secara unik mengidentifikasi item, dan nilai memegang data untuk item. Nilainya buram untuk sistem manajemen database. Item disimpan dalam urutan kunci.
Kueri menentukan kunci untuk mengidentifikasi item yang akan diambil. Anda tidak dapat mencari nilai. Aplikasi yang mengambil data dari toko nilai kunci bertanggung jawab untuk mengurai isi nilai yang dikembalikan.
Operasi tulis dibatasi untuk menyisipkan dan menghapus. Jika Anda perlu memperbarui item, Anda harus mengambil item, memodifikasinya dalam memori (dalam aplikasi), dan kemudian menulisnya kembali ke database, menimpa yang asli (secara efektif menghapus dan menyisipkan).
Fokus dari toko nilai kunci adalah kemampuan untuk membaca dan menulis data dengan sangat cepat. Kemampuan pencarian adalah sekunder. Toko nilai kunci adalah pilihan yang sangat baik untuk konsumsi data, ketika sejumlah besar data tiba sebagai aliran terus-menerus dan harus disimpan segera.
Penyimpanan Azure Table adalah contoh dari toko nilai kunci. Cosmos DB juga mengimplementasikan toko nilai kunci menggunakan API Tabel.
Apa itu database dokumen?
Database dokumen mewakili ujung spektrum NoSQL dari toko nilai kunci. Dalam database dokumen, setiap dokumen memiliki ID yang unik, tetapi bidang dalam dokumen transparan ke sistem manajemen database. Database dokumen biasanya menyimpan data dalam format JSON, seperti yang dijelaskan pada unit sebelumnya, atau mereka dapat dikodekan menggunakan format lain seperti XML, YAML, JSON, BSON. Dokumen bahkan dapat disimpan sebagai teks biasa. Bidang dalam dokumen terkena sistem manajemen penyimpanan, memungkinkan aplikasi untuk query dan menyaring data dengan menggunakan nilai-nilai di bidang ini.
Biasanya, dokumen berisi seluruh data untuk suatu entitas. Item apa yang merupakan entitas yang spesifik aplikasi. Misalnya, entitas dapat berisi rincian pelanggan, pesanan, atau kombinasi keduanya. Satu dokumen mungkin berisi informasi yang akan tersebar di beberapa tabel relasional dalam RDBMS (sistem manajemen database relasional).
Penyimpanan dokumen tidak mengharuskan semua dokumen memiliki struktur yang sama. Pendekatan bentuk bebas ini memberikan banyak fleksibilitas. Aplikasi dapat menyimpan data yang berbeda dalam dokumen saat persyaratan bisnis berubah.
Aplikasi dapat mengambil dokumen dengan menggunakan kunci dokumen. Kuncinya adalah pengenal unik untuk dokumen. Beberapa database dokumen membuat kunci dokumen secara otomatis. Yang lain memungkinkan Anda untuk menentukan atribut dokumen untuk digunakan sebagai kunci. Aplikasi ini juga dapat meminta dokumen berdasarkan nilai satu atau lebih bidang. Beberapa database dokumen mendukung pengindeksan untuk memfasilitasi pencarian dokumen dengan cepat berdasarkan satu atau lebih bidang yang diindeks.
Beberapa sistem manajemen database dokumen mendukung pembaruan di tempat, memungkinkan aplikasi untuk memodifikasi nilai bidang tertentu dalam dokumen tanpa menulis ulang seluruh dokumen. Sistem manajemen basis data dokumen lainnya (seperti Cosmos DB) hanya dapat membaca dan menulis seluruh dokumen. Dalam kasus ini, pembaruan menggantikan seluruh dokumen dengan versi baru. Pendekatan ini membantu mengurangi fragmentasi dalam database, yang pada gilirannya dapat meningkatkan kinerja.
Sebagian besar database dokumen akan menelan volume besar data lebih cepat daripada database relasional, tetapi tidak seoptimal toko nilai kunci untuk jenis pemrosesan ini. Fokus dari database dokumen adalah kemampuan query-nya.
Azure Cosmos DB mengimplementasikan pendekatan database dokumen dalam API Core (SQL).
Apa itu database keluarga kolom?
Database keluarga kolom mengatur data ke dalam baris dan kolom. Contoh struktur ini termasuk file ORC dan Parquet, dijelaskan dalam unit sebelumnya.
Dalam bentuknya yang paling sederhana, database keluarga kolom dapat muncul sangat mirip dengan database relasional, setidaknya secara konseptual. Kekuatan sebenarnya dari database keluarga kolom terletak pada pendekatan denormalisasi untuk penataan data yang jarang.
Misalnya, jika Anda perlu menyimpan informasi tentang pelanggan dan alamat mereka dalam database relasional (mengabaikan kebutuhan untuk mempertahankan data historis seperti yang dijelaskan di bagian sebelumnya), Anda mungkin merancang skema yang mirip dengan yang ditunjukkan di bawah ini. Diagram ini juga menunjukkan beberapa data sampel. Dalam contoh ini, pelanggan 1 dan pelanggan 3 berbagi alamat yang sama, dan skema memastikan bahwa informasi alamat ini tidak diduplikasi. Ini adalah cara standar untuk menerapkan hubungan satu-ke-banyak.
Model relasional mendukung pendekatan yang sangat umum untuk menerapkan jenis hubungan ini, tetapi untuk menemukan alamat pelanggan tertentu, aplikasi perlu menjalankan kueri yang bergabung dengan dua tabel. Jika ini adalah kueri paling umum yang dilakukan oleh aplikasi, maka overhead yang terkait dengan melakukan operasi gabungan ini dapat dengan cepat menjadi signifikan jika ada sejumlah besar permintaan dan tabel itu sendiri besar.
Tujuan dari database keluarga kolom adalah untuk secara efisien menangani situasi seperti ini. Anda dapat menganggap database keluarga kolom sebagai memegang data tabular yang terdiri dari baris dan kolom, tetapi Anda dapat membagi kolom menjadi kelompok yang dikenal sebagai kolom-keluarga. Setiap keluarga kolom memegang satu set kolom yang secara logis terkait bersama-sama. Gambar di bawah ini menunjukkan salah satu cara menyusun informasi yang sama dengan gambar sebelumnya, dengan menggunakan database keluarga kolom untuk mengelompokkan data menjadi dua keluarga kolom yang memegang nama pelanggan dan informasi alamat. Cara lain untuk mengatur kolom dimungkinkan, tetapi Anda harus menerapkan keluarga kolom Anda untuk mengoptimalkan kueri paling umum yang dilakukan aplikasi Anda. Dalam hal ini, kueri yang mengambil alamat pelanggan dapat mengambil data dengan pembacaan lebih sedikit daripada yang diperlukan dalam database relasional yang sesuai; kueri ini dapat mengambil data langsung dari keluarga kolom AddressInfo.
Ilustrasi di atas adalah konseptual daripada fisik, dan dimaksudkan untuk menunjukkan struktur logis dari data daripada bagaimana hal itu dapat diatur secara fisik. Setiap baris dalam database keluarga kolom berisi kunci, dan Anda dapat mengambil data untuk baris dengan menggunakan kunci ini.
Di sebagian besar database keluarga kolom, kolom-keluarga disimpan secara terpisah. Dalam contoh sebelumnya, keluarga kolom CustomerInfo mungkin diadakan di satu area penyimpanan fisik dan keluarga kolom AddressInfo di tempat lain, dalam bentuk partisi vertikal sederhana. Anda harus benar-benar memikirkan struktur dalam hal kolom-keluarga daripada baris. Data untuk entitas tunggal yang mencakup beberapa keluarga kolom akan memiliki kunci baris yang sama di setiap keluarga kolom. Sebagai alternatif dari tata letak konseptual yang ditunjukkan sebelumnya, Anda dapat memvisualisasikan data yang ditampilkan sebagai pasangan struktur fisik berikut.
Sistem manajemen database keluarga kolom yang paling banyak digunakan adalah Apache Cassandra. Azure Cosmos DB mendukung pendekatan column-family melalui Cassandra API.
Apa itu database grafik?
Database grafik memungkinkan Anda untuk menyimpan entitas, tetapi fokus utamanya adalah pada hubungan yang dimiliki entitas ini satu sama lain. Database grafik menyimpan dua jenis informasi: node yang dapat Anda anggap sebagai contoh entitas, dan tepi, yang menentukan hubungan antara node. Node dan tepi keduanya dapat memiliki properti yang memberikan informasi tentang node atau tepi (seperti kolom dalam tabel). Selain itu, tepi dapat memiliki arah yang menunjukkan sifat hubungan.
Tujuan dari database grafik adalah untuk memungkinkan aplikasi untuk secara efisien melakukan query yang melintasi jaringan node dan tepi, dan untuk menganalisis hubungan antara entitas. Gambar di bawah ini menunjukkan database personil organisasi yang terstruktur sebagai grafik. Entitas adalah karyawan dan departemen dalam organisasi, dan tepi menunjukkan garis pelaporan dan departemen di mana karyawan bekerja. Dalam grafik ini, panah di tepi menunjukkan arah hubungan.
Struktur seperti ini membuatnya mudah untuk melakukan pertanyaan seperti "Temukan semua karyawan yang secara langsung atau tidak langsung bekerja untuk Sarah" atau "Siapa yang bekerja di departemen yang sama dengan John?" Untuk grafik besar dengan banyak entitas dan hubungan, Anda dapat melakukan analisis yang sangat kompleks dengan sangat cepat, dan banyak database grafik menyediakan bahasa kueri yang dapat Anda gunakan untuk melintasi jaringan hubungan secara efisien. Anda sering dapat menyimpan informasi yang sama dalam database relasional, tetapi SQL yang diperlukan untuk query informasi ini mungkin memerlukan banyak operasi bergabung rekursif mahal dan subkuel bersarang.
Azure Cosmos DB mendukung database grafik menggunakan Api Gremlin. Gremlin API adalah bahasa standar untuk membuat dan query grafik.
Komentar
Posting Komentar