Saya sedang mengerjakan proyek di mana saya mencoba untuk memutuskan antara menggunakan database relasional SQL standar atau objek JSON untuk menyimpan data tentang suatu peristiwa atau kegiatan.
Proyek ini akan menyimpan data pada beberapa jenis acara jadi saya telah memutuskan untuk hanya menggambarkan satu jenis acara untuk pertanyaan ini.
Acara musik langsung (dijelaskan secara lengkap menggunakan skema JSON di bagian bawah pertanyaan ini) adalah objek yang menyimpan data seperti di mana acara akan berlangsung, waktu / tanggal acara dan biaya acara. Objek acara musik langsung memiliki satu-ke-satu (acara -> nama, acara -> deskripsi) dan satu-ke-banyak (acara -> tempat, acara -> tanggal, acara -> jenis tiket ) hubungan. Selanjutnya, objek acara dapat berisi satu atau lebih ID pemain, yang menautkan ke objek pemain. Objek pemain menyimpan data musisi yang tampil di acara musik live.
Data akan ditanyakan oleh pengguna yang menggunakan sederhana ("Temukan saya acara dengan nama 'x'") dan kompleks ("Temukan saya acara dengan genre musik 'x' dan biaya 'y' dalam radius 'z' dari saat ini saya kueri lokasi "). Data akan dikirimkan oleh pengguna menggunakan formulir web.
Seperti yang mungkin Anda ketahui dari skema JSON yang ditentukan, saya awalnya akan menggunakan objek JSON untuk menyimpan data ini, tetapi saya telah mendengar dari beberapa orang yang mengatakan bahwa karena data saya murni relasional, saya harus tetap menggunakan metode yang lebih lama.
Saya akan menghargai setiap pemikiran tentang pro dan kontra dari setiap pendekatan yang diberikan kebutuhan saya. Jika Anda perlu sesuatu yang diklarifikasi, silakan bertanya.
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
Jawaban:
Saya pikir pertanyaan Anda benar-benar bermuara pada: Kapan saya harus menggunakan pendekatan NoSQL vs RDBMS? Anda memilih JSON lebih awal (keputusan NoSQL-ish), mungkin karena Anda memiliki konsumen Ajax.
Jawabannya tentu saja kapan harus menggunakan pendekatan NoSQL vs RDBMS pada dasarnya adalah tentang tipe data apa yang Anda gunakan dan apa yang Anda harapkan dari pelanggan. Jika data Anda pada dasarnya relasional (hierarki yang cukup datar, tidak ada tipe data aneh seperti gambar atau audio, hubungan yang dapat diprediksi antara skema yang dapat dengan mudah dijelaskan dalam kunci), dan konsumen Anda pada akhirnya diharapkan untuk menyertakan orang-orang yang ingin melakukan kueri Intelijen Bisnis (permintaan ad hoc), maka RDBMS adalah cara untuk pergi. Ini cukup mudah untuk mengubah kueri menjadi representasi JSON, sehingga tidak secara signifikan membebani konsumen Ajax Anda - itu hanya menambahkan sedikit kode transformasi ke titik akhir Anda (REST / SOAP / apa pun). sebaliknya, jika data Anda sangat hierarkis (skema dalam), berisi tipe data aneh seperti gambar, audio, video, dll., ada beberapa hubungan antara entitas, dan Anda tahu bahwa pengguna akhir Anda tidak akan melakukan BI, maka NoSQL / menyimpan JSON mungkin sesuai.
Tentu saja, bahkan pedoman umum ini tidak solid. Alasan Google mengembangkan Sistem File Google, MapReduce (pekerjaan yang digunakan oleh Doug Cutting untuk membangun Hadoop di Yahoo) dan kemudian BigQuery (cara schemaless berorientasi [NoSQL] mengelola data skala besar) justru karena mereka memiliki banyak ad hoc BI meminta, dan mereka tidak bisa mendapatkan pendekatan relasional untuk meningkatkan skala tera / peta / exa / zetta / yotta yang mereka coba kelola. Satu-satunya pendekatan praktis adalah meningkatkan skala, mengorbankan beberapa keramahan pengguna ad-hoc-query yang disediakan RDBMS, dan mengganti algoritma sederhana (MapReduce) yang dapat dikodekan dengan cukup mudah untuk setiap permintaan yang diberikan.
Dengan skema Anda di atas, pertanyaan saya pada dasarnya adalah: Mengapa Anda tidak menggunakan RDBMS? Saya tidak melihat banyak alasan untuk tidak melakukannya. Profesi kita seharusnya berorientasi pada teknik, tidak berorientasi pada fashion, jadi insting kita seharusnya memilih solusi termudah yang bekerja, bukan? Maksud saya, titik akhir Anda mungkin harus melakukan sedikit terjemahan jika konsumen Anda adalah Ajaxy, tetapi data Anda terlihat sangat datar dan sepertinya pengguna bisnis akan ingin melakukan semua jenis pencarian ad hoc pada hal-hal seperti acara musik (Yang acara itu paling banyak dihadiri dalam jarak 50 mil dari ibukota kami tahun lalu?)
"Jangan pergi ke peri untuk meminta nasihat, karena mereka akan mengatakan tidak dan ya." - Frodo
sumber
Saya percaya ada lebih banyak pertimbangan di sini yang mungkin tidak Anda cari. Ada dua keprihatinan luas di sini:
Penyimpanan
Ada banyak pendapat tentang mengapa menggunakan toko no-sql atau RDBMS untuk data Anda. Salah satu item paling penting yang kami pikir berguna adalah bahwa kita dapat dengan mudah mendefinisikan dan menyimpan objek json dalam penyimpanan tanpa harus khawatir tentang mendefinisikan struktur penuh atau hubungan antara berbagai jenis objek. Beberapa alasan lain untuk menggunakan NoSql db adalah kemampuan untuk mengirim data secara otomatis, pencarian berbasis lokasi, dan perawatan yang mudah. Ada banyak basis data NoSql yang bagus di luar sana, preferensi pribadi saya adalah MongoDB. Namun, jika Anda belum pernah menggunakan database NoSql sebelumnya, ada kurva belajar yang pasti saat Anda belajar untuk menyambungkan kembali pikiran Anda. Sebagian besar dari kita telah menggunakan RDBMS untuk sementara waktu sekarang dan perlu upaya sadar untuk keluar dari kebiasaan itu. Plus Anda akan menemukan diri Anda ingin mengulang model data Anda saat Anda melanjutkan bersama dengan upaya Anda dan memiliki pemahaman konsep yang lebih baik. Jika kemampuan untuk memperbaiki atau merombak bukanlah pilihan untuk proyek Anda, saya akan menyarankan untuk tetap dengan apa yang sudah Anda ketahui.
Pencarian
Jika Anda bermaksud menyediakan segala jenis pencarian yang dapat digunakan, saya sangat menyarankan Anda menggunakan mesin pencarian teks khusus seperti SOLR untuk melakukan pencarian Anda. Pencarian teks lambat dan jika Anda memiliki banyak pecahan maka lebih lambat lagi. SOLR mendukung pencarian teks cepat termasuk params pencarian tertimbang, pencarian berbasis lokasi dan banyak lagi. Namun SOLR tidak cocok sebagai penyimpan utama data Anda. Ini berarti bahwa Anda harus membuat mekanisme untuk memasukkan ganda dan memperbarui ke basis data primer dan lapisan SOLR Anda saat menambah atau memperbarui acara. Plus Anda harus menjaga SOLR nanti diperbarui dengan menghapus acara yang sudah usang / berakhir.
Meskipun ini sepertinya banyak pekerjaan tambahan, Anda akan berterima kasih pada diri sendiri karena melihat ke depan menggunakan mesin pencarian teks lengkap nanti. Tidak ada satu pun dari database NoSql atau RDBMS yang mendekati kinerja dan ketangkasan SOLR / Lucene.
sumber
Pertama, jika Anda mencoba untuk Menyimpan data JSON di penyimpanan apa pun tetapi tidak di basis data NoSQL , saya pasti akan mencegah Anda menggunakan JSON. Alasannya adalah bahwa jika Anda menyimpan data Anda sebagai file JSON, misalnya, maka akan sangat lambat untuk membukanya, menguraikannya, mengulanginya, dll.
Itu mulai berkata, saya bisa mempersempit pertanyaan Anda ke: Apa pro dan kontra dari NoSQL dan RDBMS ? Dan sudah dijawab ribuan kali di internet.
Mendaftarkan proyek Anda, tentu saja Anda dapat menggunakan NoSQL atau RDBMS ; Namun apa yang saya umumnya dapat merekomendasikan kepada Anda adalah untuk berpikir di luar kotak dan mencari faktor-faktor lain yang kurang terlihat yang mungkin membantu Anda memutuskan di antara dua opsi. Coba lihat opsi mana yang bisa mempercepat pengembangan? Mana yang lebih cocok untuk anggota tim lainnya - jika Anda bukan pengembang tunggal. Jika Anda menjual ini, mana yang lebih murah, lebih mudah dan umumnya lebih cocok untuk pelanggan non-pengembang Anda?
Dengan cara ini Anda akhirnya dapat memutuskan ke mana harus pergi, jika tidak, akan sangat sulit untuk memutuskan berdasarkan informasi yang diberikan karena kedua opsi tersebut dapat cocok dengan cukup baik.
sumber
Dalam sebagian besar aplikasi ada persyaratan untuk
Untuk mencapai persyaratan untuk Item 1 diperlukan metode data yang bertahan lama. Biasanya jika volume data sangat kecil dan jenis data sederhana dan tidak memerlukan kemampuan pencarian yang luas maka struktur file sederhana dapat digunakan. Ketika data menjadi lebih kompleks, struktur XML (atau bahkan JSON) dapat digunakan dengan data yang masih disimpan dalam file. Pencarian menjadi lebih bermasalah. Ketika volume data meningkat dan kompleksitas pencarian meningkat, sebuah basis data biasanya dipilih yang menyediakan metode standar industri untuk persistensi data, permintaan, dll. Basis data dapat dirancang untuk menangani volume data yang besar dan menyimpan, mengambil dan mencari data dengan cepat dan efisien .
Untuk mencapai persyaratan untuk Item 2 ada berbagai metode berbeda untuk memungkinkan pertukaran data antara sistem termasuk XML, JSON dll.
Metode-metode ini memungkinkan struktur data untuk didefinisikan oleh pengguna dan bahasa independen yang memungkinkan sistem berbeda untuk bertukar data.
Dalam kasus khusus Anda, Anda benar menggunakan JSON menggambarkan serangkaian acara musik. Meskipun Anda bisa menyimpan data dalam format JSON mencari data ini karena jumlah acara musik tumbuh akan lambat dan tidak efisien.
Menggunakan pendekatan pemisahan kekhawatiran maka pendekatan yang lebih baik adalah mengumpulkan data, menyimpan dalam database, melakukan kueri Anda berdasarkan input pengguna dalam database dan kemudian mengembalikan hasilnya dalam format JSON ke sisi Klien untuk menampilkan data.
Masalah tambahan dengan pendekatan JSON adalah perubahan struktur data. Saat ini struktur Anda relatif sederhana. Anda dapat menggunakan struktur ini selama beberapa bulan dan kemudian bidang tambahan diidentifikasi. Apa yang kemudian Anda lakukan dengan semua objek JSON yang ada? Memperbarui ini akan bermasalah.
Jika Anda menggunakan database maka menambahkan bidang tambahan relatif sederhana dan hanya kode Anda untuk menghasilkan JSON yang perlu dimodifikasi di satu tempat sehingga memberi Anda semua JSON baru dengan bidang baru.
Singkatnya, gunakan setiap teknologi untuk apa yang dirancang untuk JSON untuk pertukaran data dan Database untuk kegigihan data.
sumber
Saya pikir Anda akan memiliki kesuksesan yang lebih baik dengan menggunakan NoSQL daripada SQL untuk menyimpan data ini, karena pertanyaan yang perlu Anda lakukan.
Juga hanya karena beberapa data murni relasional tidak berarti, lagi, itu harus dipertahankan menjadi beberapa RDBMS (SQL). Data relasional IMO akan menerjemahkan lebih baik ke dalam basis data grafik.
Tentu saja Anda juga dapat menulis kueri dalam SQL tetapi kinerjanya akan mengerikan karena jumlah gabungan yang perlu Anda miliki (mengingat data Anda akan agak dinormalisasi dan tidak semuanya menjadi satu tabel Acara).
Tetapi sebagai kesimpulan Anda akan memiliki lebih banyak kebebasan dengan menggunakan NoSQL (dengan demikian JSON atau format lain yang didukung oleh basis data) mengingat Anda dapat memodifikasi skema Anda di masa mendatang tanpa memperhitungkan data yang sudah ada.
Mempertimbangkan NoSQL Anda juga bisa melihat ke dalam basis data grafik jika Anda berencana untuk menggunakan kueri yang sangat kompleks, karena ini akan memberi Anda keuntungan dalam membuatnya dengan mudah, dan juga menjalankannya dengan sangat cepat.
sumber
Saya pikir Anda harus menggunakan keduanya dan saya tidak melihatnya sebagai keputusan 'lawan'.
Database relasional masuk akal untuk penyimpanan yang cepat dan efisien dan pengambilan data yang memiliki sifat relasional.
JSON adalah format data yang hebat karena sederhana, ringan dan ideal untuk menyalurkan data mentah dalam format yang sangat mendasar dengan sintaksis yang cocok untuk menyimpan dan bertukar informasi teks. Ini bagus untuk melewatkan sejumlah kecil data antara browser dan server. Ini tidak dalam format yang mudah untuk mulai digunakan untuk kueri tipe data relasional.
Jadi saya akan merekomendasikan SQL untuk penyimpanan data dan JSON untuk format transportasi data.
Memang benar bahwa tidak ada opsi nilai kunci noSQL seperti Mongo, Redis, dll. Ini akan memiliki keuntungan dari pemetaan yang mungkin lebih sederhana ke format JSON tetapi umumnya sedikit lebih sulit digunakan untuk permintaan. Rintangan utama dengan mereka adalah tidak terbiasa dengan komunitas TI umum terutama bila dibandingkan dengan SQL yang sangat terkenal dan memiliki beragam sumber daya dan pengetahuan yang tersedia untuk hampir setiap situasi yang dapat dibayangkan.
sumber