Panduan NoSQL untuk Pembangun

Jika anda telah mengikuti arah aliran dalam pembangunan bahagian belakang dan Data Besar, anda mungkin telah melihat buzz di sekitar pangkalan data NoSQL dalam beberapa tahun kebelakangan ini. Sesetengah orang diilhamkan oleh pendekatan ini kepada pangkalan data, manakala yang lain berpendapat bahawa terdapat beberapa jenis helah tersembunyi di dalamnya: model data di dalamnya tidak sama seperti dalam pangkalan data hubungan biasa, antara muka pengaturcaraan aplikasi adalah luar biasa, dan aplikasi sering tidak dapat difahami. Dalam artikel ini saya akan memberitahu anda mengapa ia dicipta pada mulanya, pangkalan data NoSQL ini, apakah masalah yang mereka selesaikan dan mengapa begitu banyak pangkalan data yang berbeza tiba-tiba diperlukan. Jika anda baru menggunakan NoSQL, anda mungkin amat berminat dengan bahagian terakhir artikel, yang menyenaraikan jenis pangkalan data NoSQL yang saya fikir patut diterokai terlebih dahulu untuk mendapatkan pemahaman yang menyeluruh tentang bidang tersebut.

Mengapa kita tiba-tiba memerlukan pangkalan data baharu?

Anda mungkin hairan untuk bertanya: apa yang salah dengan pangkalan data hubungan? Intinya ialah mereka bekerja dengan sangat baik selama bertahun-tahun, tetapi kini terdapat masalah yang tidak dapat mereka tangani lagi. Menurut beberapa ramalan, pada 2018 manusia akan menjana 50,000 gigabait data sesaat. Ini adalah jumlah data yang besar! Penyimpanan dan pengendaliannya menimbulkan cabaran kejuruteraan yang serius. Apa yang lebih teruk ialah jumlah ini sentiasa berkembang. Ternyata, pangkalan data hubungan kurang sesuai untuk bekerja dengan jumlah data yang sangat besar. Ia direka untuk dijalankan pada satu mesin, dan jika anda ingin mengendalikan lebih banyak permintaan, maka satu-satunya pilihan ialah membeli komputer dengan lebih banyak RAM dan pemproses yang lebih berkuasa. Malangnya, bilangan pertanyaan yang boleh dikendalikan oleh satu mesin adalah terhad, dan untuk kerja teragih merentas berbilang mesin kami memerlukan teknologi pangkalan data yang berbeza. Sudah tentu, sesetengah pembaca akan ketawa pada ketika ini dan mengatakan bahawa terdapat dua kaedah yang digunakan secara meluas untuk menggunakan berbilang mesin dalam kes pangkalan data hubungan: replikasi dan sharding. Itu benar, tetapi kaedah ini tidak mencukupi untuk menangani tugas kita. Replikasi baca ialah teknik di mana setiap kemas kini pangkalan data disebarkan ke mesin lain yang hanya boleh mengendalikan permintaan baca. Dalam kes ini, semua perubahan dilakukan oleh satu pelayan, dipanggil nod induk, manakala pelayan lain, dipanggil replika baca, hanya mengekalkan salinan data. Pengguna boleh membaca dari mana-mana mesin, tetapi menukar data hanya melalui nod induk. Ini adalah kaedah yang mudah dan sangat popular, tetapi ia hanya membolehkan anda memproses lebih banyak permintaan baca dan tidak dalam apa-apa cara menyelesaikan masalah memproses volum data yang diperlukan. Sharding ialah satu lagi pendekatan popular yang menggunakan berbilang contoh pangkalan data hubungan. Setiap daripada mereka mengendalikan operasi tulis dan baca untuk sebahagian daripada data. Jika pangkalan data menyimpan maklumat tentang pelanggan, contohnya, menggunakan sharding, satu mesin boleh mengendalikan semua permintaan untuk pelanggan yang namanya bermula dengan A, mesin lain boleh menyimpan semua data untuk pelanggan yang namanya bermula dengan B, dan seterusnya. Walaupun sharding membolehkan anda merekodkan lebih banyak data, mengurus pangkalan data sedemikian adalah mimpi ngeri sebenar: anda perlu menyelaraskan data merentas mesin dan menskalakan kluster dalam kedua-dua arah mengikut keperluan. Walaupun ia kelihatan mudah secara teori, membetulkannya agak mencabar.

Bolehkah pangkalan data hubungan dipertingkatkan?

Saya rasa anda sudah mula percaya bahawa pangkalan data hubungan bukanlah yang paling sesuai untuk jumlah data yang dijana dalam dunia moden. Walaupun, anda mungkin masih tertanya-tanya mengapa belum ada sesiapa yang mencipta pangkalan data hubungan "lebih baik" yang boleh berjalan dengan cekap merentas berbilang mesin. Nampaknya teknologi ini masih belum dibangunkan, dan pangkalan data hubungan yang diedarkan akan muncul tidak lama lagi. Malangnya, ini tidak akan berlaku. Ini adalah mustahil secara matematik, dan tiada apa yang boleh dilakukan mengenainya. Untuk memahami mengapa ini berlaku, anda perlu melihat apa yang dipanggil teorem CAP (aka teorem Brewer). Ia telah dibuktikan pada tahun 1999, dan ia menyatakan bahawa pangkalan data teragih yang berjalan pada berbilang mesin boleh mempunyai tiga sifat berikut: Ketekalan - sebarang operasi baca mengembalikan hasil operasi tulis terakhir yang sepadan. Sekiranya sistem itu konsisten, selepas menulis data baharu, adalah mustahil untuk membaca data lama yang sudah ditimpa. Ketersediaan ( Ketersediaan ) - sistem yang diedarkan boleh menyediakan permintaan yang masuk pada bila-bila masa dan mengembalikan respons tanpa ralat. Toleransi partition - pangkalan data terus bertindak balas untuk membaca dan menulis permintaan walaupun beberapa pelayannya tidak dapat berkomunikasi antara satu sama lain buat sementara waktu. Kegagalan sementara ini dipanggil kegagalan sambungan rangkaian dan boleh disebabkan oleh pelbagai faktor, daripada masalah rangkaian fizikal akibat pelayan yang perlahan kepada kerosakan fizikal pada peralatan rangkaian. Semua sifat ini sememangnya berguna, dan kami sangat menginginkan pangkalan data untuk menggabungkan kesemuanya. Tiada pembangun yang waras mahu berputus asa, katakan, kebolehaksesan tanpa mendapat apa-apa sebagai balasan. Malangnya, teorem CAP juga menyatakan bahawa adalah mustahil bagi ketiga-tiga sifat untuk dipegang secara serentak. Menyedari ini mungkin tidak mudah, tetapi mungkin. Pertama, jika kita memerlukan pangkalan data yang diedarkan, ia mestilah "toleransi pemutusan." Ini tidak dibincangkan pun. Pemutusan sambungan berlaku sepanjang masa dan pangkalan data kami mesti berfungsi walaupun ini. Sekarang mari kita fahami mengapa kita tidak boleh mencapai kedua-dua konsistensi dan ketersediaan. Bayangkan kita mempunyai pangkalan data ringkas yang dijalankan pada dua mesin: A dan B. Mana-mana pengguna boleh menulis ke mana-mana mesin, selepas itu data disalin ke mesin yang lain. Sekarang bayangkan bahawa mesin ini tidak dapat berkomunikasi antara satu sama lain buat sementara waktu, dan mesin B tidak dapat menghantar data kepada atau menerima data daripada mesin A. Jika dalam tempoh masa ini mesin B menerima permintaan baca daripada pelanggan, ia mempunyai dua pilihan:

1. Dapatkan kembali data setempat anda, walaupun ia bukan yang terkini. Dalam kes ini, keutamaan diberikan kepada ketersediaan (untuk mengembalikan sekurang-kurangnya beberapa data, walaupun data yang sudah lapuk).
2. Ralat kembali. Dalam kes ini, konsistensi diutamakan: pelanggan tidak akan menerima data lapuk, tetapi ia tidak akan menerima sebarang data sama sekali.

Pangkalan data perhubungan berusaha untuk menjelmakan sifat "ketekalan" dan "ketersediaan" serentak, dan oleh itu tidak boleh beroperasi dalam persekitaran teragih. Cuba untuk melaksanakan semua keupayaan pangkalan data hubungan dalam sistem yang diedarkan akan menjadi sama ada tidak realistik atau tidak boleh dilaksanakan . Sebaliknya, pangkalan data NoSQL meletakkan premium pada kebolehskalaan dan prestasi. Mereka biasanya tidak mempunyai keupayaan "asas" seperti sambungan dan transaksi, dan model data ternyata berbeza sama sekali, mungkin juga mengehadkan dalam beberapa cara. Semua ini memungkinkan untuk menyimpan volum data yang lebih besar dan memproses lebih banyak pertanyaan berbanding sebelum ini.

Bagaimanakah pangkalan data NoSQL mengimbangi konsistensi dan ketersediaan?

Nampaknya kepada anda jika anda memilih pangkalan data NoSQL, anda akan sentiasa menerima sama ada beberapa data lapuk atau ralat sekiranya berlaku sebarang kegagalan. Dalam amalan, ketersediaan dan konsistensi bukanlah satu-satunya pilihan yang tersedia. Terdapat pelbagai pilihan yang tersedia untuk anda pilih. Pangkalan data perhubungan tidak mempunyai pilihan ini, tetapi NoSQL membenarkan anda mengawal pelaksanaan pertanyaan dengan cara yang sama. Satu cara atau yang lain, mereka membenarkan anda menetapkan dua parameter apabila melakukan operasi tulis atau baca dalam pangkalan data NoSQL: W - berapa banyak mesin dalam kelompok mesti mengesahkan menyimpan data semasa menjalankan operasi tulis . Lebih besar bilangan mesin tempat anda menulis data anda, lebih mudah untuk membaca data terkini pada operasi baca seterusnya, tetapi juga lebih lama masa yang diperlukan. R – berapa banyak mesin yang anda ingin membaca data daripada . Dalam sistem yang diedarkan, pengedaran data kepada semua mesin dalam kelompok boleh mengambil sedikit masa, jadi sesetengah pelayan akan mempunyai data terkini manakala yang lain akan ketinggalan. Lebih banyak bilangan mesin dari mana data dibaca, lebih tinggi peluang untuk membaca data semasa. Mari kita lihat contoh praktikal. Jika anda mempunyai lima komputer dalam kelompok anda dan anda memutuskan untuk menulis data kepada satu sahaja dan kemudian membaca data daripada satu komputer yang dipilih secara rawak, maka terdapat 80% kemungkinan anda akan membaca data basi. Sebaliknya, ini akan menggunakan sumber yang minimum. Oleh itu, jika data warisan baik dengan anda, itu bukan pilihan yang buruk. Dalam kes ini, parameter W dan R adalah sama dengan 1. Sebaliknya, jika anda menulis data ke semua lima mesin dalam pangkalan data NoSQL, anda boleh membaca data dari mana-mana mesin dan dijamin mendapat data terkini setiap kali. Melakukan operasi yang sama pada bilangan mesin yang lebih besar akan mengambil masa yang lebih lama, tetapi jika data terkini adalah penting kepada anda, maka anda boleh memilih pilihan ini. Dalam kes ini, W = R = 5. Apakah bilangan minimum baca dan tulis yang diperlukan untuk ketekalan pangkalan data? Berikut ialah formula mudah: R + W ≥ N + 1 , dengan N ialah bilangan mesin dalam kelompok. Ini bermakna dengan lima pelayan, anda boleh memilih sama ada R = 2 dan W = 4, atau R = 3 dan W = 3, atau R = 4 dan W = 2. Dalam kes ini, tidak kira kepada mesin mana data ditulis, baca akan sentiasa dilakukan daripada sekurang-kurangnya satu mesin dengan data terkini. Pangkalan data lain, seperti DynamoDB, mempunyai sekatan yang berbeza dan hanya membenarkan penulisan yang konsisten. Setiap sekeping data disimpan pada tiga pelayan, dan apabila sebarang data ditulis, ia ditulis kepada dua daripada tiga mesin. Tetapi apabila membaca data, anda boleh memilih salah satu daripada dua pilihan:

1. Bacaan yang konsisten, di mana data dibaca daripada dua mesin daripada tiga dan sentiasa mengembalikan data bertulis yang paling terkini.
2. Pembacaan konsisten akhirnya, di mana satu mesin dipilih secara rawak untuk membaca data. Walau bagaimanapun, ini mungkin mengembalikan data lapuk buat sementara waktu.

Mengapa terdapat begitu banyak pangkalan data NoSQL?

Jika anda mengikuti berita terkini dalam pembangunan perisian, anda mungkin pernah mendengar tentang banyak pangkalan data NoSQL yang berbeza, seperti MongoDB, DynamoDB, Cassandra, Redis dan banyak lagi. Anda mungkin tertanya-tanya: mengapa kita memerlukan begitu banyak pangkalan data NoSQL yang berbeza? Sebabnya mudah: pangkalan data NoSQL yang berbeza direka untuk menyelesaikan masalah yang berbeza. Inilah sebabnya bilangan pangkalan data yang bersaing adalah begitu besar. Pangkalan data NoSQL terbahagi kepada empat kategori utama:

Pangkalan data berorientasikan dokumen

Pangkalan data ini menyediakan keupayaan untuk menyimpan dokumen bersarang yang kompleks, manakala kebanyakan pangkalan data hubungan hanya menyokong baris satu dimensi. Ciri ini boleh berguna dalam banyak kes, contohnya, apabila perlu menyimpan maklumat tentang pengguna dengan beberapa alamat dalam sistem. Apabila menggunakan pangkalan data berorientasikan dokumen, dalam kes ini anda hanya boleh menyimpan objek kompleks yang mengandungi pelbagai alamat, manakala dalam pangkalan data hubungan anda perlu mencipta dua jadual: satu untuk maklumat pengguna dan satu untuk alamat. Pangkalan data berorientasikan dokumen merapatkan jurang antara model objek dan model data. Sesetengah pangkalan data hubungan, seperti PostgreSQL, kini turut menyokong storan berorientasikan dokumen, tetapi kebanyakan pangkalan data hubungan masih kekurangan keupayaan ini.

Pangkalan Data Utama/Nilai

Pangkalan data kunci/nilai biasanya melaksanakan model NoSQL yang paling mudah. Pada asasnya, mereka memberikan anda jadual cincang yang diedarkan , membolehkan anda menulis data pada kunci yang diberikan dan membacanya kembali menggunakannya. Pangkalan data kunci/nilai sangat berskala dan mempunyai kependaman yang jauh lebih rendah daripada pangkalan data lain.

Pangkalan Data Graf

Banyak bidang subjek, contohnya, rangkaian sosial atau maklumat tentang filem dan pelakon, boleh diwakili sebagai graf. Walaupun graf boleh diwakili menggunakan pangkalan data hubungan, ia adalah sukar dan menyusahkan. Jika anda memerlukan data graf, lebih baik menggunakan pangkalan data graf khusus, yang boleh menyimpan maklumat tentang graf dalam kelompok teragih dan memungkinkan untuk melaksanakan algoritma pada graf dengan cekap.

Pangkalan Data Lajur

Perbezaan utama antara kolumnar dan jenis pangkalan data lain ialah cara data disimpan pada cakera. Pangkalan data hubungan membuat fail untuk setiap jadual dan menyimpan nilai untuk semua baris secara berurutan. Pangkalan data kolumnar mencipta fail untuk setiap lajur dalam jadual anda. Struktur ini membolehkan anda mengagregat data dan menjalankan pertanyaan tertentu dengan lebih cekap, tetapi anda mesti memastikan bahawa data itu sesuai dengan batasan pangkalan data tersebut.

Pangkalan data mana yang patut anda pilih?

Memilih pangkalan data biasanya merupakan masalah yang mengecewakan, dan dengan begitu banyak pilihan yang tersedia, ia boleh kelihatan seperti tugas yang memberangsangkan. Berita baiknya ialah tidak perlu memilih hanya satu. Daripada mencipta aplikasi monolitik tunggal yang melaksanakan semua keupayaan dan mempunyai akses kepada semua data sistem, anda boleh menggunakan corak moden lain yang dipanggil microservices : pecahkan aplikasi menjadi satu set perkhidmatan bebas. Setiap perkhidmatan menyelesaikan masalah sempitnya sendiri, dan hanya menggunakan pangkalan datanya sendiri, yang paling sesuai untuk menyelesaikan masalah ini.

Bagaimana anda sepatutnya mempelajari semua ini?

Dengan begitu banyak pangkalan data , mempelajari semuanya boleh kelihatan seperti satu tugas yang mustahil. Berita baik: anda tidak perlu melakukan ini. Terdapat hanya beberapa jenis asas pangkalan data NoSQL, dan jika anda memahami cara ia berfungsi, yang lain akan lebih mudah difahami. Selain itu, sesetengah pangkalan data NoSQL digunakan lebih kerap daripada yang lain, jadi sebaiknya anda memfokuskan usaha anda pada penyelesaian yang paling popular. Berikut ialah senarai pangkalan data NoSQL yang paling biasa digunakan yang saya fikir anda perlu lihat:

1. MongoDB . Mungkin pangkalan data NoSQL yang paling popular di pasaran. Jika syarikat tidak menggunakan pangkalan data hubungan sebagai stor data utamanya, ia mungkin menggunakan MongoDB. Ini ialah storan dokumen yang fleksibel dengan set alat yang baik. Pada awal kerjayanya, MongoDB mempunyai reputasi buruk kerana kehilangan data dalam beberapa kes , tetapi sejak itu kestabilan dan kebolehpercayaannya telah bertambah baik dengan ketara. Lihatlah kursus MongoDB ini jika anda ingin mengetahui lebih lanjut.


2. DynamoDB . Jika anda menggunakan Perkhidmatan Web Amazon (AWS), lebih baik anda mengetahui lebih lanjut tentang DynamoDB. Ia adalah pangkalan data kependaman rendah yang sangat boleh dipercayai, berskala, dengan set ciri yang kaya dan penyepaduan dengan banyak perkhidmatan AWS lain. Bahagian yang terbaik ialah anda tidak perlu menggunakannya sendiri. Menyediakan gugusan DynamoDB berskala yang boleh mengendalikan beribu-ribu pertanyaan hanya dengan beberapa klik sahaja. Jika ini menarik minat anda, anda boleh melihat kursus ini .


3. Neo4j . Pangkalan data graf yang paling biasa. Ini ialah penyelesaian berskala dan stabil yang sesuai untuk mereka yang ingin menggunakan model data graf. Jika anda ingin mengetahui lebih lanjut, mulakan dengan kursus ini .


4. Redis . Walaupun pangkalan data lain yang diterangkan di sini digunakan untuk menyimpan data aplikasi teras, Redis digunakan terutamanya untuk melaksanakan cache dan menyimpan data tambahan. Dalam banyak kes, salah satu pangkalan data yang disebutkan di atas digunakan seiring dengan Redis. Untuk mengetahui lebih lanjut, lihat kursus ini.

Pada tahun 2018 dengan NoSQL

Pangkalan data NoSQL adalah bidang yang luas dan berkembang pesat. Mereka membenarkan anda menyimpan dan memproses jumlah data yang tidak dapat dibayangkan sebelum ini, tetapi ia memerlukan kos. Pangkalan data ini tidak mempunyai banyak ciri yang anda kenali dalam pangkalan data hubungan, dan mungkin sukar untuk menyediakan diri anda untuk menggunakannya. Tetapi sebaik sahaja anda memahaminya, anda boleh mencipta pangkalan data teragih berskala yang boleh mengendalikan jumlah permintaan baca dan tulis yang menakjubkan, yang boleh menjadi sangat penting kerana volum data yang lebih besar dan lebih besar dijana. Asal: https://simpleprogrammer.com/guide-nosql-software-developers/