Mengapa menggunakan database alih-alih hanya menyimpan data Anda ke disk?


193

Alih-alih database saya hanya membuat serial data saya ke JSON, menyimpan dan memuatnya ke disk bila perlu. Semua manajemen data dibuat pada program itu sendiri, yang lebih cepat DAN lebih mudah daripada menggunakan query SQL. Untuk alasan itu saya tidak pernah mengerti mengapa database diperlukan sama sekali.

Mengapa seseorang harus menggunakan database dan bukannya hanya menyimpan data ke disk?


61
Jika mengelola hubungan data Anda dalam aplikasi Anda sebenarnya lebih cepat daripada melakukannya dalam database (yang menurut saya sangat sulit dipercaya) maka Anda perlu membaca tentang SQL dan normalisasi basis data. Apa yang Anda alami kemungkinan besar adalah efek samping dari database yang dirancang dengan mengerikan.
yannis

68
Anda tidak memerlukan database dalam skenario yang Anda gambarkan karena kumpulan data Anda sepele. Basis data dimaksudkan untuk kumpulan data yang lebih kompleks, jika semua yang Anda lakukan adalah membaca dan menampilkan daftar, pendekatan Anda akan berhasil.
yannis

16
Kondisi ras apa yang bisa Anda temui, dan apakah Anda siap untuk itu? Apakah Anda ingin skala melewati server web tunggal? Apa rencana cadangan Anda jika server Anda gagal? Jawaban Anda untuk semua pertanyaan ini kemungkinan akan lebih baik jika Anda memiliki basis data daripada jika tidak. Juga jika Anda pernah mempelajari cara menggunakan database, tebakan saya adalah Anda akan menemukan "Anda lebih mudah daripada menggunakan query SQL" harus diubah menjadi "lebih mudah daripada menggunakan query SQL jika Anda tidak mengerti SQL."
btilly

37
Database menyimpan data ke disk. Ini hanya hasil akhir dari evolusi alami sistem untuk menyimpan data terstruktur ke file. Kemungkinannya adalah jika Anda memutuskan untuk menggunakan file untuk menyimpan data terstruktur Anda, Anda akan menemukan diri Anda menemukan kembali fitur yang telah dikembangkan dalam database. Jadi mengapa tidak menggunakan database saja dari awal?
Benediktus

13
Bergantung pada bagaimana proyek Anda berkembang, Anda mungkin harus berhadapan dengan hal-hal seperti akses dan kemunduran bersamaan. Kedengarannya sepele, tetapi tidak. Pada saat Anda selesai menyelesaikannya, Anda akan menemukan bahwa pada dasarnya Anda telah menulis database. Apakah Anda benar-benar ingin berada dalam bisnis basis data, atau bisnis lain?
jwernerny

Jawaban:


280
  1. Anda dapat meminta data dalam database (ajukan pertanyaan).
  2. Anda dapat mencari data dari database dengan relatif cepat.
  3. Anda dapat menghubungkan data dari dua tabel yang berbeda bersama-sama menggunakan BERGABUNG.
  4. Anda dapat membuat laporan yang bermakna dari data dalam database.
  5. Data Anda memiliki struktur bawaan untuk itu.
  6. Informasi jenis yang diberikan selalu disimpan hanya sekali.
  7. Database ACID .
  8. Database toleran terhadap kesalahan.
  9. Basis data dapat menangani kumpulan data yang sangat besar.
  10. Database bersamaan; banyak pengguna dapat menggunakannya secara bersamaan tanpa merusak data.
  11. Database skala dengan baik.

Singkatnya, Anda mendapat manfaat dari beragam teknologi terkenal dan teruji yang dikembangkan selama bertahun-tahun oleh beragam orang yang sangat pintar.

Jika Anda khawatir database terlalu banyak, lihat SQLite.


21
6. Normalisasi, 7. Lihat tautan, 8. Bacalah toleransi kesalahan. Oh, dan sebelum Anda terseret ke kegilaan NoSQL, pelajari tentang basis data SQL; mengenal mereka dengan cara mereka sendiri. Kamu akan mengerti. Jika Anda hanya berbicara tentang data konfigurasi sederhana, JSON mungkin yang Anda butuhkan. Tetapi ada banyak jenis data lain di luar sana selain pengaturan program.
Robert Harvey

25
Sejauh ini tidak aman untuk memiliki dua program mengedit data sekaligus, yah, itu sebabnya database ada. Jika Anda pernah memiliki kebutuhan ini (dan beberapa atau semua kebutuhan lain yang saya sebutkan), Anda akan sangat senang bahwa Anda tidak perlu menemukan kembali semua ini.
Robert Harvey

23
@ Dokkat Itu tidak perlu, tidak ada. Jika pendekatan Anda bekerja untuk Anda, tentu saja lakukanlah. Namun saya harus menyebutkan bahwa sebagian besar rdbms yang layak mendukung penyimpanan berbasis memori, Anda dapat memuat semua yang Anda butuhkan dalam memori ketika aplikasi Anda bangun (seperti yang sudah Anda lakukan), dan meminta mereka seperti yang Anda lakukan pada database biasa (menjaga semua manfaat yang disebutkan Robert). ).
yannis

28
Dengan kata lain, kadang-kadang Anda membutuhkan tenda, tetapi kadang-kadang Anda membutuhkan rumah, dan membangun rumah adalah permainan bola yang sangat berbeda daripada memasang tenda.
Robert Harvey

49
@Dokkat ketika orang-orang mengacu pada crash, mereka berarti hal-hal seperti ... CPU Anda meledak setengah menulis file "database" Anda. Apa yang terjadi sekarang? Kemungkinan besar file Anda rusak / tidak dapat dibaca (setidaknya, mungkin tidak lagi sesuai dengan format Anda sendiri), dan Anda perlu mengembalikan formulir cadangan (sementara kebanyakan DB "nyata" hanya akan kehilangan transaksi terakhir). Tentu saja, Anda dapat menulis kode untuk membuatnya menangani ini. Kemudian Anda dapat menulis kode untuk semua hal lainnya. Dan kemudian Anda menyadari bahwa Anda telah menghabiskan 6 bulan menulis DB, yang bisa Anda gunakan sejak awal, untuk sedikit usaha.
Daniel B

200

Sementara saya setuju dengan semua yang dikatakan Robert, dia tidak memberi tahu Anda kapan Anda harus menggunakan database dan bukan hanya menyimpan data ke disk.

Jadi, ambil ini sebagai tambahan dari apa yang dikatakan Robert tentang skalabilitas, keandalan, toleransi kesalahan, dll.

Kapan menggunakan RDBMS, berikut adalah beberapa hal yang perlu dipertimbangkan:

  • Anda memiliki data relasional, yaitu Anda memiliki pelanggan yang membeli produk Anda dan produk-produk tersebut memiliki pemasok dan produsen
  • Anda memiliki sejumlah besar data dan Anda harus dapat menemukan informasi yang relevan dengan cepat
  • Anda perlu mulai mengkhawatirkan masalah-masalah sebelumnya yang diidentifikasi: skalabilitas, keandalan, kepatuhan ACID
  • Anda perlu menggunakan alat pelaporan atau intelijen untuk mengatasi masalah bisnis

Adapun kapan harus menggunakan NoSQL

  • Anda memiliki banyak data yang perlu disimpan yang tidak terstruktur
  • Skalabilitas dan kebutuhan kecepatan
  • Anda biasanya tidak perlu mendefinisikan skema Anda di muka, jadi jika Anda memiliki persyaratan yang berubah, ini mungkin poin yang bagus

Akhirnya, kapan harus menggunakan file

  • Anda memiliki data yang tidak terstruktur dalam jumlah wajar yang dapat ditangani oleh sistem file
  • Anda tidak peduli dengan struktur, hubungan
  • Anda tidak peduli dengan skalabilitas atau keandalan (meskipun ini bisa dilakukan, tergantung pada sistem file)
  • Anda tidak ingin atau tidak bisa berurusan dengan overhead yang akan ditambahkan database
  • Anda berurusan dengan data biner terstruktur yang termasuk dalam sistem file, misalnya: gambar, PDF, dokumen, dll.

14
+1, saya pikir ini penting bahwa Anda menunjukkan ada kalanya file benar-benar cocok untuk penyimpanan.
GrandmasterB

15
Anda dapat menambahkan contoh lain ke daftar ketiga Anda: Ketika data sebenarnya adalah file, mis. Gambar yang diunggah, dokumen pdf dan semacamnya. Ini mungkin tampak jelas tetapi saya memang melihat kasus di mana gambar disimpan dalam gumpalan database tanpa alasan yang baik sama sekali.
Goran Jovic

5
Yah, tidak pernah ada yang menyebutkan secara eksplisit bahwa itu adalah aplikasi web tapi saya menyimpulkannya dari komentar JSON. Namun, terkadang sesuatu hanya akan digunakan oleh beberapa orang dan Anda dapat membenarkan ruang lingkup aplikasi untuk tidak khawatir tentang skalabilitas dan keandalan. Maksud saya, tidak mengkhawatirkan hal-hal seperti pengelompokan dan redundansi.
Sam

8
@ GoranJovic terkadang masuk akal. Simpan 10.000+ gambar dalam direktori dan beberapa filesystem akan terhenti - DB mungkin lebih mudah daripada skema partisi sub-direktori manual.
Martin Beckett

2
@ MartinBeckett: sistem file mana dalam dekade terakhir yang melakukan itu?
Eamon Nerbonne

55

Satu hal yang tampaknya tidak ada yang disebutkan adalah pengindeksan catatan. Pendekatan Anda baik-baik saja saat ini, dan saya berasumsi bahwa Anda memiliki kumpulan data yang sangat kecil dan sangat sedikit orang yang mengaksesnya.

Ketika Anda menjadi lebih kompleks, Anda sebenarnya membuat database. Apa pun yang Anda ingin menyebutnya, database hanyalah satu set catatan yang disimpan ke disk. Apakah Anda sedang membuat file, atau MySQL , SQLite atau apa pun yang membuat file, keduanya adalah database.

Apa yang Anda lewatkan adalah fungsionalitas kompleks yang telah dibangun ke dalam sistem basis data untuk membuatnya lebih mudah digunakan.

Hal utama yang muncul di pikiran adalah pengindeksan. OK, jadi Anda dapat menyimpan 10 atau 20 atau bahkan 100 atau 1000 catatan dalam array berseri, atau string JSON dan tarik keluar dari file Anda dan lakukan iterasi dengan relatif cepat.

Sekarang, bayangkan Anda memiliki 10.000, 100.000, atau bahkan 1.000.000 catatan. Ketika seseorang mencoba masuk Anda harus membuka file yang sekarang beberapa ratus megabytes, muat ke dalam memori di program Anda, tarik keluar array informasi berukuran sama dan kemudian iterate 100-an ribu catatan hanya untuk temukan satu catatan yang ingin Anda akses.

Basis data yang tepat akan memungkinkan Anda untuk mengatur indeks pada bidang tertentu dalam catatan yang memungkinkan Anda untuk meminta basis data dan menerima respons dengan sangat cepat, bahkan dengan kumpulan data yang sangat besar. Gabungkan dengan sesuatu seperti Memcached , atau bahkan sistem cache buatan sendiri (misalnya, simpan hasil pencarian dalam tabel terpisah selama 10 menit dan muat hasilnya jika ada orang lain mencari hal yang sama segera setelah itu), dan Anda akan memiliki pertanyaan yang sangat cepat, sesuatu yang tidak akan Anda dapatkan dengan set data besar ketika Anda membaca / menulis ke file secara manual.

Hal lain yang secara longgar terkait dengan pengindeksan adalah transfer informasi. Seperti yang saya katakan di atas, ketika Anda punya file ratusan atau ribuan megabita Anda harus memuat semua informasi itu ke dalam memori, iterate secara manual (mungkin pada utas yang sama) dan kemudian memanipulasi data Anda.

Dengan sistem basis data, ia akan berjalan pada utasnya sendiri, atau bahkan pada servernya sendiri. Semua yang ditransmisikan antara program Anda dan server database adalah kueri SQL dan semua yang dikirimkan kembali adalah data yang ingin Anda akses. Anda tidak memuat seluruh dataset ke dalam memori - semua yang Anda kirim dan terima hanyalah sebagian kecil dari total data Anda.


1
1. Tolong jangan pernah memuat semua informasi pengguna Anda ke dalam kode sisi klien! (Saya yakin itu hanya contoh) 2. Memuat bahwa di tempat pertama dari file 100-an MB besar akan memakan waktu cukup lama. 3. Contoh Anda benar, namun menganggap bahwa Anda hanya akan mencari berdasarkan nama pengguna. Apa yang terjadi jika Anda ingin menyimpan lebih banyak data tentang pengguna? misalnya Umur. Sekarang Anda ingin mencari semua pengguna yang berusia antara 20-30. Atau lebih sederhana lagi, cari pengguna berdasarkan alamat ketika json Anda terlihat seperti ini: {login: {pass: pass, add1: "123 sasd", city: "Wherever"}}.
Thomas Clayson

2
Poin terakhir Anda berpotensi benar, tetapi kemudian saya dapat bekerja dari data lama - khususnya, jika saya membuka program Anda, memuat basis data saat ini kemudian 5 menit kemudian orang lain masuk dan mengedit sesuatu, basis data saya sekarang menjadi versi yang lebih baru sampai saya keluar dari program dan mulai lagi. Jika saya mengedit database saya dan menyimpannya lagi, saya akan menimpa perubahan yang dilakukan pengguna lain. Ketika Anda memiliki basis data pengguna, ini bisa berupa apa saja dari hanya mengubah kata sandi Anda. Jika dua pengguna mengubah kata sandi mereka selama setiap sesi lainnya maka satu pengguna akan memiliki perubahan mereka dibalik.
Thomas Clayson

4
Saya telah belajar banyak setelah mencari beberapa hal tentang pengindeksan. Benar-benar mencerahkan. Database lebih masuk akal sekarang. Masih ada beberapa hal yang saya tidak mengerti, tapi itu kemajuan besar. Terima kasih atas jawaban itu!
MaiaVictor

4
Tentang indeks, tidak, basis data tidak mengindeks semuanya secara otomatis. Hanya beberapa hal yang secara otomatis diindeks sementara sisanya memerlukan eksplisit "tolong buat ini diindeks". Dan indeks mengurangi pencarian ke waktu logaritmik, O (log (n)) yang sedikit lebih lambat dari konstan.
Kaisar Orionii

1
Khawatir tentang perbedaan antara implementasi berbasis hash dan berbasis b-tree adalah optimasi prematur. Jika data ada dalam indeks, itu masih akan belasan kali lebih cepat daripada membacanya dari disk.
SilverbackNet

14

Ketika Anda memiliki data sederhana, seperti daftar hal-hal seperti yang Anda jelaskan di komentar pertanyaan Anda, maka database SQL tidak akan memberi Anda banyak. Banyak orang masih menggunakannya, karena mereka tahu data mereka dapat menjadi lebih rumit dari waktu ke waktu, dan ada banyak perpustakaan yang membuat bekerja dengan sepele basis data.

Tetapi bahkan dengan daftar sederhana yang Anda muat, simpan dalam memori, kemudian tulis ketika dibutuhkan, dapat menderita sejumlah masalah:

Penghentian program yang tidak normal dapat kehilangan data, atau saat menulis data ke disk ada yang tidak beres, dan Anda dapat mematikan seluruh file. Anda bisa menggulung mekanisme Anda sendiri untuk menangani ini, tetapi database menangani ini untuk Anda menggunakan teknik yang sudah terbukti.

Jika data Anda mulai tumbuh terlalu besar dan memperbarui terlalu sering, membuat serialisasi semua data Anda dan menyimpan akan menjadi sumber daya yang besar dan memperlambat semuanya. Anda harus mulai bekerja bagaimana cara mempartisi hal-hal, sehingga tidak akan terlalu mahal. Database dioptimalkan untuk menyimpan hal-hal yang berubah ke disk dengan cara yang toleran terhadap kesalahan. Juga dirancang, sehingga Anda dapat dengan cepat memuat bit data yang Anda butuhkan pada waktu tertentu.

Juga, Anda tidak perlu menggunakan database SQL. Anda dapat menggunakan "database" NoSQL yang banyak dilakukan, cukup gunakan JSON untuk menyimpan data. Tetapi ini dilakukan dengan cara yang toleran terhadap kesalahan, dan dengan cara di mana data dapat secara cerdas dibagi, dipertanyakan, dan terbagi secara cerdas di banyak komputer.

Juga, beberapa orang mencampuradukkan berbagai hal. Mereka mungkin menggunakan penyimpanan data NoSQL seperti Redis untuk menyimpan informasi login. Kemudian gunakan basis data relasional untuk menyimpan data yang lebih kompleks di mana mereka perlu melakukan kueri yang lebih menarik.


12

Saya melihat banyak jawaban fokus pada masalah konkurensi dan reliabilitas. Database memberikan manfaat lain selain konkurensi, keandalan, dan kinerja. Mereka memungkinkan untuk tidak mengganggu bagaimana byte dan karakter ditampilkan dalam memori. Dengan kata lain, basis data memungkinkan pemrogram untuk memfokuskan dirinya pada "apa" dan bukan "bagaimana".

Salah satu jawaban menyebutkan pertanyaan. "Mengajukan pertanyaan pada SQL database" dengan baik dengan kompleksitas pertanyaan. Ketika kode berevolusi selama pengembangan, pertanyaan sederhana seperti "fetch all" dapat dengan mudah berkembang menjadi "fetch all di mana property1 sama dengan nilai ini dan kemudian urutkan berdasarkan property2" tanpa membuatnya menjadi perhatian programmer untuk mengoptimalkan struktur data untuk kueri tersebut. Kinerja sebagian besar kueri dapat dipercepat dengan membuat indeks untuk properti tertentu.

Manfaat lainnya adalah hubungan. Dengan kueri, lebih bersih untuk mereferensi-silang data dari set data yang berbeda kemudian memiliki loop bersarang. Misalnya mencari semua posting forum dari pengguna yang memiliki kurang dari 3 posting di sistem di mana pengguna dan posting adalah kumpulan data yang berbeda (atau tabel DB atau objek JSON) dapat dilakukan dengan satu permintaan tanpa mengorbankan keterbacaan.

Semua dalam semua, database SQL lebih baik daripada array sederhana jika volume data bisa besar (katakanlah lebih dari 1000 objek), akses data di bagian kode non-sepele dan berbeda akses ke subset data yang berbeda.


Saya sedikit curiga tentang gagasan bahwa Anda bisa mengabaikan bagaimana hal-hal diwakili. Meskipun Anda dapat mengabaikan ini, jika Anda melakukannya, dan esp. jika Anda menulis kueri yang sedikit lebih rumit, kemungkinan besar aplikasi Anda tidak dapat lagi mengukur. "Menambahkan indeks" tidak selalu mungkin - Anda harus menulis untuk bersaing, dan itu tidak banyak membantu dengan kueri yang kompleksitasnya mencakup beberapa tabel. Ketika indeks diperlukan, itu menyiratkan Anda telah kehilangan manfaat dari queryability interaktif karena hanya permintaan terstruktur khusus yang dapat dijawab dalam waktu yang wajar.
Eamon Nerbonne

12

TLDR

Sepertinya Anda membuat keputusan teknis penyimpanan data jangka pendek yang valid untuk aplikasi Anda - Anda memilih untuk menulis alat manajemen penyimpanan data kustom.

Anda duduk di sebuah kontinum, dengan opsi untuk bergerak ke arah mana pun.

Dalam jangka panjang, Anda kemungkinan besar (hampir, tetapi tidak 100% pasti) menemukan diri Anda mengalami masalah, dan mungkin lebih baik untuk berubah menggunakan solusi penyimpanan data yang ada. Ada masalah kinerja yang spesifik, sangat umum, dapat diprediksi, dan Anda akan terpaksa mengatasinya, dan Anda lebih baik menggunakan alat yang ada daripada menggulirkan sendiri.


Kedengarannya seperti Anda telah menulis basis data tujuan khusus (kecil), dibangun ke dalam dan langsung digunakan oleh aplikasi Anda. Saya berasumsi Anda mengandalkan OS dan sistem file untuk mengelola penulisan dan pembacaan disk yang sebenarnya, dan memperlakukan kombinasi sebagai penyimpanan data.

Kapan melakukan apa yang Anda lakukan

Anda sedang duduk di sweet-spot untuk penyimpanan data. OS dan penyimpanan data sistem file sangat praktis, mudah diakses, dan lintas platform portabel. Kombinasi ini sudah ada sejak lama, sehingga Anda yakin akan didukung, dan menjalankan aplikasi Anda, di hampir semua konfigurasi penggunaan standar.

Ini juga merupakan kombinasi yang mudah untuk menulis kode - API cukup mudah dan sederhana, dan dibutuhkan beberapa baris kode untuk membuatnya berfungsi.

Secara umum, sangat ideal untuk melakukan apa yang telah Anda lakukan ketika:

  • Memprototipe ide-ide baru
  • Membangun aplikasi yang sangat tidak mungkin perlu diukur, berdasarkan kinerja
  • Terkendala oleh keadaan yang tidak biasa, seperti kurangnya sumber daya untuk menginstal database

Alternatif

Anda berada di kontinum pilihan, dan ada dua 'arah' yang bisa Anda tempuh dari sini, yang saya pikir sebagai 'turun' dan 'naik':

Turun

Ini adalah opsi yang paling tidak mungkin untuk diterapkan, tetapi ada di sini untuk kelengkapan:

Anda dapat, jika ingin, turun , yaitu memotong OS dan sistem file sekaligus dan benar-benar menulis dan membaca langsung dari disk. Pilihan ini biasanya hanya relevan dalam kasus-kasus di mana efisiensi ekstrem diperlukan - pikirkan, misalnya, perangkat pemutar MP3 minimal / kecil , tanpa RAM yang cukup untuk OS yang berfungsi penuh, atau sesuatu seperti Wayback Machine , yang membutuhkan massa yang sangat efisien operasi penulisan data (sebagian besar penyimpanan data menukar penulisan dengan lambat untuk pembacaan yang lebih cepat, karena itulah kasus penggunaan yang sangat umum untuk hampir semua aplikasi).

Naik

Ada beberapa sub-kategori di sini - ini tidak sepenuhnya eksklusif. Beberapa alat merentang keduanya, menyediakan beberapa fungsi di masing-masing, beberapa dapat sepenuhnya beralih dari bekerja dalam satu mode ke bekerja di yang lain, dan beberapa dapat berlapis di atas satu sama lain, menyediakan fungsionalitas yang berbeda ke berbagai bagian aplikasi Anda.

Menyimpan data yang lebih kuat

Anda mungkin perlu menyimpan volume data yang lebih tinggi dan lebih tinggi, sambil tetap mengandalkan aplikasi Anda sendiri untuk mengelola kompleksitas manipulasi data. Seluruh jajaran toko nilai kunci tersedia untuk Anda, dengan beragam dukungan untuk fungsi terkait. Alat NoSQL termasuk dalam kategori ini, serta yang lain.

Ini adalah jalur yang jelas untuk ditingkatkan ketika yang berikut menjelaskan aplikasi Anda:

  • Ini adalah ketergantungan membaca yang luar biasa berat
  • Anda setuju dengan menukar kinerja yang lebih tinggi untuk jaminan konsistensi yang lebih rendah (jangka pendek) (banyak yang menawarkan "konsistensi akhirnya").
  • Apakah "langsung" mengelola sebagian besar manipulasi data dan kurangnya konsistensi (pada praktiknya, Anda mungkin pada akhirnya akan menggunakan alat pihak ketiga, meskipun pada akhirnya Anda akan membawa ini ke dalam aplikasi Anda atau ke lapisan perantara yang ditulis khusus) .
  • Anda sedang mencari skala besar jumlah data yang Anda simpan dan / atau kemampuan Anda untuk mencari melalui itu, dengan persyaratan manipulasi data "relatif sederhana".

Ada beberapa ruang gerak di sini - Anda dapat memaksakan konsistensi membaca yang lebih baik, untuk bacaan yang lebih lambat. Berbagai alat dan opsi menyediakan apis manipulasi data, pengindeksan, dan opsi lain, yang mungkin lebih atau kurang cocok untuk dengan mudah menulis aplikasi spesifik Anda. Jadi, jika poin di atas hampir sepenuhnya menggambarkan aplikasi Anda, Anda mungkin "cukup dekat" untuk bekerja dengan solusi penyimpanan data yang lebih kuat.

Contoh terkenal: CouchDB , MongoDB , Redis , solusi penyimpanan cloud seperti Microsoft Azure , Google App Data Store dan Amazon ECE.

Mesin manipulasi data yang lebih kompleks

Keluarga "SQL" aplikasi penyimpanan data, serta berbagai lainnya, lebih baik digambarkan sebagai alat manipulasi data, daripada mesin penyimpanan murni. Mereka menyediakan berbagai fungsi tambahan, di luar penyimpanan data, dan seringkali melampaui apa yang tersedia di sisi penyimpanan nilai-penting. Anda akan ingin mengambil jalan ini ketika:

  • Anda benar-benar harus memiliki konsistensi membaca, bahkan jika itu berarti Anda akan mendapat pukulan kinerja.
  • Anda mencari untuk secara efisien melakukan manipulasi data yang sangat kompleks - pikirkan operasi JOIN dan UPDATE yang sangat kompleks, kubus dan pengiris data , dll ...
  • Anda baik-baik saja dengan menukar kekakuan untuk kinerja (berpikir paksa, format penyimpanan data tetap, seperti tabel, yang tidak dapat dengan mudah dan / atau diubah secara efisien).
  • Anda memiliki sumber daya untuk menangani seperangkat alat dan antarmuka yang sering kali lebih kompleks.

Ini adalah cara berpikir yang lebih "tradisional" tentang basis data atau penyimpanan data, dan telah ada lebih lama - jadi ada banyak yang tersedia di sini, dan sering ada banyak kerumitan untuk dihadapi. Mungkin saja, meskipun butuh keahlian dan pengetahuan, dan membangun solusi sederhana / menghindari banyak kerumitan - Anda kemungkinan besar akan menggunakan alat dan perpustakaan pihak ketiga untuk mengelola sebagian besar untuk Anda.

Contoh terkenal adalah MySQL , SQL Server , Oracle's Database, dan DB2 .

Mengalihdayakan pekerjaan

Ada beberapa, alat pihak ketiga modern dan perpustakaan, yang menempatkan diri di antara alat penyimpanan data Anda dan aplikasi Anda, untuk membantu Anda mengelola kompleksitas.

Mereka awalnya mencoba untuk mengambil sebagian besar atau semua pekerjaan yang masuk ke dalam mengelola dan memanipulasi penyimpanan data, dan, idealnya, memungkinkan Anda untuk membuat transisi yang lancar ke kompleksitas hanya ketika dan jika diperlukan. Ini adalah bidang aktif kewirausahaan dan penelitian, dengan beberapa hasil terbaru yang segera dapat diakses dan digunakan.

Contoh terkenal adalah alat MVC ( Django , Yii ), Ruby on Rails , dan Datomic . Sulit untuk bersikap adil di sini karena ada lusinan alat dan perpustakaan yang bertindak sebagai pembungkus API dari berbagai penyimpanan data.


PS: jika Anda lebih suka video daripada teks, Anda mungkin ingin menonton beberapa video yang berhubungan dengan database Rich Hickey; ia melakukan pekerjaan dengan baik untuk menjelaskan sebagian besar pemikiran yang digunakan untuk memilih, merancang, dan menggunakan penyimpanan data.


11

Sebuah sistem file cocok dengan deskripsi dari basis data NoSQL, jadi saya katakan Anda harus mempertimbangkan untuk menggunakannya saat memutuskan bagaimana cara menyimpan data Anda dan tidak mengabaikannya begitu saja demi RDBMS, seperti beberapa jawaban yang sepertinya disarankan di sini.

Salah satu masalah dengan sistem file (dan NoSQL pada umumnya) adalah menangani hubungan antar data. Jika itu bukan pemblokir utama di sini, maka saya akan mengatakan lewati RDBMS untuk saat ini. Juga ingat sisi positif menggunakan sistem file sebagai penyimpanan:

  • Administrasi nol
  • Kompleksitas rendah, mudah diatur
  • Bekerja dengan sistem operasi, bahasa, platform, perpustakaan dll
  • Hanya pengaturan konfigurasi yang merupakan direktori
  • Sepele untuk diuji
  • Sepele untuk memeriksa dengan alat yang ada, cadangan, memodifikasi dll
  • Karakteristik kinerja yang baik dan disetel dengan baik oleh sistem operasi
  • Mudah dipahami oleh pengembang mana pun
  • Tidak ada ketergantungan, tidak ada driver tambahan
  • Model keamanan sepele untuk dipahami dan merupakan bagian dasar dari sistem operasi
  • Data tidak dapat diakses secara eksternal

( sumber )


10

Sistem file adalah jenis database. Mungkin bukan RDBMS seperti yang dibicarakan orang lain, tetapi tentu saja DB dalam arti yang paling ketat. Anda memberikan kunci (nama file) untuk mencari data (konten file), yang memiliki penyimpanan abstrak dan API yang digunakan oleh program Anda untuk berkomunikasi.

Jadi, Anda menggunakan Database. Posting lain dapat memperdebatkan tentang keutamaan berbagai jenis basis data ...


1
basis data dan penyimpanan tidak dapat digunakan secara bergantian. Basis data adalah jenis penyimpanan, tetapi sistem file tentu bukan jenis basis data
Gaz_Edge

3
"storage" adalah tempat bit dan byte disimpan. Basis data tidak harus menggunakan file pada sistem file. Suatu sistem file adalah jenis database yang paling tepat dalam pengertian istilah tersebut.
Chris S

6
Untuk seseorang yang berpendapat bahwa tidak ada gunanya dalam database ketika mereka alternatif adalah menggunakan database ; Iya. Tampaknya bermanfaat untuk menjelaskan kepada mereka bahwa argumen mereka didasarkan pada anggapan sebelumnya bahwa itu salah. Begitu mereka memiliki pemahaman yang lebih baik tentang situasi awal mereka, kami dapat membantu mereka bergerak maju dengan pemahaman yang lebih lengkap tentang teknologi yang tersedia. Sistem file adalah basis data hierarkis, ada alasan yang baik hubungan dan sistem basis data objek telah menggantikannya sebagai penyimpanan / pengambilan data yang lebih cepat, lebih terorganisir, dan lebih efisien.
Chris S

2
@Gaz_Edge Data sudah ada di "database" tidak efisien dengan disimpan dalam banyak file yang struktur dan kontennya dikelola oleh aplikasi OP. Mencoba membuat OP memahami dan menerima itu adalah langkah pertama yang berguna untuk membuat mereka memahami kasus penggunaan untuk sistem database "nyata"; begitu mereka mengerti bahwa "database" semacam itu terjadi, lebih mudah untuk mulai berbicara tentang di mana layanan yang terstruktur dan dikelola dengan benar lebih efisien daripada membiarkan aplikasi melakukan hal sendiri. Saya sarankan jawaban ini membantu, sangat banyak.
Rob Moir

8

Basis data diperlukan jika Anda memiliki banyak proses (pengguna / server) yang memodifikasi data. Kemudian database berfungsi untuk mencegah mereka saling menimpa perubahan.

Anda juga membutuhkan database saat data Anda lebih besar dari memori. Saat ini dengan memori yang kami miliki, ini memang membuat penggunaan database di banyak aplikasi menjadi usang.

Pendekatan Anda jelas lebih baik daripada omong kosong "database di memori". Yang pada dasarnya adalah pendekatan Anda, tetapi dengan banyak overhead ditambahkan.


Jujur saya suka jawaban ini dan ingin itu menjadi kenyataan, tapi saya tidak yakin itu masalahnya. Misalnya, beberapa pengguna (dan Anda) mengemukakan kekhawatiran tentang memori. Tentu saja, jika saya menyimpan data senilai GBs saya tidak bisa menyimpan semuanya di memori. Tetapi bagaimana jika saya yakin datanya tidak akan sebesar itu, haruskah saya menggunakan memori saja? Ya, ada hal-hal lain juga. Sebagai contoh, saya telah belajar tentang pandangan inkremental CouchDB. Itu tentu sesuatu yang, berbeda dari pengindeksan, TIDAK akan sepele untuk mengimplementasikan diri Anda sendiri, dan tentu saja merupakan percepatan besar ketika Anda menggunakan model tampilan,
MaiaVictor

yang saya kira saya. Misalnya, ketika saya mengubah data dari "daftar pemain" menjadi "peringkat", ini hanyalah operasi pengurangan peta. Saat membuat game atau situs interaktif, hampir semua yang Anda sajikan adalah operasi mapReduce dari data inti Anda! Jadi memiliki optimasi semacam itu bisa sangat diinginkan. Yah, saya tidak tahu apakah ada yang saya bicarakan, tapi itu masuk akal. Belajar banyak hari ini, dan saya sangat menyukai konsep NoSQL. Terima kasih atas jawabannya (:
MaiaVictor

7

Anda harus selalu bertanya pada diri sendiri apakah aplikasi tertentu membutuhkan RDBMS. Terlalu banyak aplikasi dibangun dengan proses desain yang secara otomatis mengasumsikan semua alat dan kerangka kerja yang diperlukan di awal. Database relasional sangat umum dan banyak pengembang telah bekerja pada aplikasi yang sama seperti sebelumnya, sehingga mereka secara otomatis dimasukkan sebelum proyek dimulai. Banyak proyek bisa lolos dengan ini, jadi jangan menilai terlalu keras.

Anda memulai proyek Anda tanpa itu, dan itu berhasil. Lebih mudah bagi Anda untuk menjalankan dan menjalankan ini tanpa menunggu hingga Anda SQL. Tidak ada yang salah dengan itu.

Ketika proyek ini berkembang dan persyaratan menjadi lebih rumit, beberapa hal akan menjadi sulit untuk dibangun. Sampai Anda meneliti dan menguji metode alternatif, bagaimana Anda tahu mana yang lebih baik? Anda dapat bertanya pada Pemrogram dan menyaring melalui api dan 'itu tergantung' untuk menjawab pertanyaan ini. Setelah Anda mempelajarinya, Anda dapat mempertimbangkan berapa baris kode yang ingin Anda tulis dalam bahasa Anda untuk menangani beberapa manfaat dari database. Pada titik tertentu, Anda menciptakan kembali roda.

Mudah seringkali relatif. Ada beberapa kerangka kerja yang bisa membangun halaman web dan menghubungkan formulir ke tabel database tanpa mengharuskan pengguna untuk menulis kode apa pun. Saya kira jika Anda berjuang dengan mouse, ini bisa menjadi masalah. Semua orang tahu, ini tidak dapat diskalakan atau fleksibel karena Tuhan melarang Anda menggabungkan semuanya dengan GUI. Seorang non-programmer baru saja membuat prototipe; banyak YAGNI dapat ditemukan di sini.

Jika Anda lebih suka mempelajari ORM yang dimanipulasi oleh bahasa pilihan Anda alih-alih belajar SQL, coba saja, tetapi cobalah untuk menginstal, buat tabel dan tarik beberapa data dari database populer dengan SQL (Pilih * Dari; bukan hal yang membingungkan). Itu mudah dilakukan. Karena itulah seseorang menciptakannya. Sepertinya bukan investasi yang sangat besar untuk membuat keputusan yang tepat. Anda mungkin bisa melakukan tes kinerja juga.


Sebagai catatan, saya sudah menggunakan mysql selama bertahun-tahun ketika saya meng-host "otserv". Tebak apa? Yang dibawanya hanyalah masalah. Orang-orang dapat "mengkloning" item menggunakan trik kotor setelah mereka menyadari bahwa karakter mereka disimpan ketika mereka logout tetapi tidak ketika server crash. Ini adalah masalah serius bagi otservs. Dan komunitas otserv adalah BESAR. Itu tidak akan terjadi jika mereka hanya menyimpan data pada memori dan membuat serial itu secara berkala. Jadi saya memodifikasi sumbernya sendiri, file C ++ panjang itu dan mulai menyimpan ke mysql secara berkala, alih-alih ketika karakter keluar. Tebak apa? Itu lambat!
MaiaVictor

Mysql tidak bisa menangani keadaan penyimpanan penuh setiap 2 menit atau lebih. Itu cukup jelas ketika penghematan terjadi - seluruh server "tertinggal" sebentar. Sekarang saya akan sangat menghargai jika orang yang memposting di sini memiliki jawaban untuk yang itu!
MaiaVictor

1
Jangan menilai RDBMS berdasarkan apa yang terjadi dengan satu aplikasi yang mungkin memiliki kode yang buruk. Terutama ketika modifikasi untuk mendukung database dilakukan oleh seseorang yang tidak memiliki pengalaman database.
alroc

1
@Dokkat, saya harap tidak ada yang menendang kabel listrik di antara setoran dana di rekening bank Anda dan "secara berkala" menulis saldo akun ke disk. Anda telah menggambarkan arsitektur kehilangan data yang dijamin. Itu bagus untuk beberapa aplikasi, tetapi sebagian besar aplikasi database memberi pengguna kemampuan untuk memilih. Anda dapat menjalankan simpul basis data tunggal dengan cadangan dan berisiko kehilangan data atau menggunakan replikasi untuk menghilangkan kehilangan data jika satu simpul gagal.
mikerobi

@Dokkat sehingga Anda tidak menggunakan MySql atau DB gaya "server" berfitur lengkap lainnya. Anda menggunakan Sqlite (atau yang serupa) dan itu akan tetap ada di disk setiap saat, sambil memberi Anda DB yang tertanam di aplikasi Anda (jadi tidak perlu untuk instalasi yang terpisah) dan masih memberi Anda akses sql, integritas transaksional, dan kegigihan disk.
gbjbaanb

6

Menyimpan data ke disk IS menulisnya ke database, terutama jika Anda meletakkan setiap objek dalam file sendiri dengan nama file menjadi kunci untuk merekam. Dan untuk meminimalkan waktu pencarian untuk membaca file, buat subdirektori berdasarkan beberapa karakter pertama dari kunci tersebut.

Misalnya kunci = ghostwriter akan masuk dalam g / ho / stwriter.json atau g / h / o / stwriter.json atau g / ho / ghostwriter.json atau g / h / o / ghostwriter.json. Pilih skema penamaan Anda berdasarkan distribusi kunci Anda. Jika mereka nomor urut maka 5/4/3 / 12345.json lebih baik daripada sebaliknya.

Itu adalah database dan jika ia melakukan semua yang Anda butuhkan, maka lakukan dengan cara itu. Sekarang ini akan disebut basis data NoSQL seperti GDBM, atau Berkeley db. Begitu banyak pilihan. Pertama cari tahu apa yang Anda butuhkan, kemudian bangun pustaka antarmuka untuk menangani detail, mungkin antarmuka get / set seperti memcached atau antarmuka CRUD, dan kemudian Anda akan dapat menukar pustaka jika Anda perlu mengubah format database untuk satu dengan karakteristik yang berbeda.

Perhatikan bahwa beberapa database SQL seperti PostgreSQL dan Apache Derby DB, akan memungkinkan Anda untuk melakukan query SQL di atas banyak format NoSQL termasuk database homegrown Anda sendiri. Tidak yakin tentang MyBatis tetapi mungkin serupa.

Hindari hype NoSQL. Baca tentang fitur, uji kinerja dan kemampuan, lalu pilih berdasarkan seberapa cocok dengan kebutuhan aplikasi Anda.

http://www.hdfgroup.org/HDF5/ adalah format datastore lain yang menarik dan banyak digunakan yang tidak sering dipertimbangkan orang.


4

Segera setelah data diperbarui secara bersamaan, pendekatan yang menggunakan basis data (bisa juga dalam basis data memori) kemungkinan akan lebih benar dan lebih berkinerja, sementara pada saat yang sama kode Anda tetap mudah, karena Anda tidak punya untuk khawatir tentang pembaruan bersamaan, transaksi, caching, I / O yang tidak sinkron, dan semua itu.


Modifikasi bersamaan dalam suatu proses akan lebih efisien menggunakan kunci dalam proses daripada IPC ke daemon basis data yang memperoleh banyak kunci. Tetapi Anda mungkin berbicara tentang beberapa proses memodifikasi data.
dhasenan

@dasenan - Ini adalah keunggulan lain dari sistem basis data yang baik. Anda mendapatkan konkurensi, dan berfungsi dalam semua kasus: Multi-utas, multi-proses, beberapa klien di server yang berbeda, atau kombinasi dari semuanya. Program multi-threaded Anda yang baik meskipun keluar mungkin "lebih efisien" dalam kasus-kasus tertentu, namun itu tidak akan skala.
Ingo

-5

Anda memerlukan databse untuk menyimpan / mengambil QA seperti yang kami posting di sini! File sederhana tidak dapat mengatur data yang terkait dengan berbagai topik.


3
Tidak, "topik" bisa berupa folder, dan "pos" di situs bisa berupa file. Sangat mungkin untuk menjalankan situs seperti ini dari sistem file. Itu tidak efisien: lambat dan rumit untuk dikembangkan, menjalankan kueri, memasukkan data baru, dll.
Chris S

lambat + rumit = tidak bisa?
joe

Lambat dan rumit untuk dibangun! = Lambat dan rumit berfungsi
joe

1
@ Jo, benar-benar tidak benar bahwa file (mungkin bukan file "sederhana", tetapi apa artinya itu?) Tidak dapat digunakan untuk mengatur data yang terkait dengan berbagai topik. Anda dapat menggunakan JSON, seperti yang disarankan Dokkat, atau XML, atau file rekaman campuran seperti yang biasa kami lakukan di masa pra-XML, atau format file apa pun yang dapat Anda impikan. Saya tidak akan merekomendasikan pendekatan ini untuk sebagian besar skenario, tetapi itu tidak berarti mereka tidak dapat dilakukan.
John M Gant

@John M Gant: sepenuhnya setuju dengan Anda, basis data tidak dapat mengganti file tunggal (karena Anda tidak suka sederhana), dan sebaliknya, karena satu-satunya alasan bahwa mobil tidak dapat mengganti sepeda. saya berbicara 3 bahasa "manusia", dan pilihan kata dan kosakata saya adalah alasan mengapa saya disalahpahami ... saya kira
joe
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.