Mengapa menggunakan MySQL untuk situs web kamus merupakan ide yang buruk?

55

Saya berencana untuk merancang dan mengatur database untuk menyimpan entri kamus (biasanya kata tunggal) dan artinya dalam bahasa lain. Jadi, misalnya, Daftar Istilah tabel harus memiliki entri dan definisi dan setiap catatan tabel memiliki referensi ke id catatan yang disimpan di Tag(Setiap entri harus memiliki tag atau kategori).

Karena data saya memiliki struktur, saya pikir menggunakan database SQL (seperti MySQL) bukan ide yang buruk; tetapi orang mengatakan MongoDB jauh lebih baik untuk kinerja.

Di sisi klien, aplikasi harus dapat menyediakan kotak pencarian dengan pelengkapan otomatis yang menggunakan API REST yang disediakan oleh backend. Apakah aman menggunakan MySQL dalam skenario seperti itu? atau haruskah saya menggunakan MongoDB atau ElasticSearch dari solusi lain untuk ini? Ratusan ribu catatan seharusnya disimpan dan diakses dengan cara ini.

— Aziz Az
sumber

79

Orang-orang yang memberi tahu Anda banyak hal belum melakukan banyak penelitian tentang hal ini. Bahasa dengan kosa kata terbesar, Inggris, memiliki kurang dari satu juta kata yang berbeda. Ini berada dalam ranah kemampuan kinerja DB relasional.

— TheCatWhisperer

25

Saya tidak melihat apa pun di sini yang akan membuat saya berpikir MySQL tidak akan berfungsi dengan baik untuk itu. Performa pada pencarian sederhana tidak akan menjadi masalah, dan memiliki pencarian teks lengkap jika Anda perlu menempuh rute itu.

— GrandmasterB

46

Mengenai "MongoDB jauh lebih baik untuk kinerja" —sebagai pernyataan yang tidak dimodifikasi tanpa klarifikasi ruang lingkup, ini adalah omong kosong peringkat. Sebagai contoh, lihat Alat baris perintah bisa 235x Lebih Cepat dari Hadoop Cluster Anda (yang saya temui dari tautan di The Website Obesity Crisis ).

— Wildcard

82

Saya sangat lelah dengan orang yang mengatakan bahwa basis data relasional itu buruk dan MongoDB lebih baik karena lebih cepat. Itu seperti mengatakan mobil itu buruk dan kita harus menggunakan pesawat terbang karena mereka melakukan perjalanan lebih cepat. Saran saya adalah mengabaikan saran seperti ini.

— Brandon

13

@Brandon Yang menyedihkan adalah bahwa keseluruhan "NoSQL jauh lebih cepat" klaim biasanya bermuara pada beberapa penjelasan teoritis tentang mengapa mereka harus jauh lebih baik, tetapi dalam praktiknya bahkan tidak berlaku untuk banyak skenario dunia nyata. Lihat misalnya di sini . Suite benchmark yang digunakan adalah open source dan tersedia di github juga. Hell CERN mengelola data PB mereka dengan OracleDB.

— Voo

95

Saya tidak bisa memberi tahu Anda mengapa itu ide yang buruk. Saya dapat memberi tahu Anda banyak alasan mengapa database relasional adalah ide yang baik .

Ingat bahwa tidak semua orang berkonsultasi dengan kamus untuk definisi. Lebih sering daripada tidak, kamus digunakan untuk menemukan ejaan yang benar. Ini berarti Anda tidak hanya menemukan jarum di tumpukan jerami , Anda sedang mencari tumpukan jerami untuk jarum yang mirip dengan yang dijelaskan oleh pengguna (jika saya dapat menggunakan idiom).

Anda tidak akan hanya melakukan pencarian kunci primer. Anda akan melakukan pencarian kata kunci
Kata-kata dapat dihubungkan, baik dalam arti atau ejaan ( baca, baca , merah dan buluh )

Setiap kali Anda melihat kata "terkait" pikirkan "Database Relasional"
Jika Anda membutuhkan kecepatan, Anda perlu caching di atas database relasional Anda, bukan model data relasional yang rusak
Basis data yang dinormalkan dengan benar mempercepat pencarian kunci utama dan pencarian karena hanya ada sedikit bit yang harus disaring.
Orang-orang yang mengatakan database yang dinormalisasi lebih lambat mengacu pada 0,1% kasus di mana ini benar. Dalam 99,9% kasus lainnya mereka belum benar - benar bekerja dengan database yang benar-benar normal untuk melihat kinerja secara langsung, jadi abaikan saja. Saya telah bekerja dengan database yang dinormalisasi. Suka. Tidak mau kembali. Dan saya bukan orang basis data. Saya seorang pria C # / JavaScript / HTML / Ruby.
Kata-kata memiliki asal. Bahkan, banyak kata dalam bahasa yang sama dapat memiliki asal yang sama, yang merupakan kata lain dalam bahasa yang berbeda. Misalnya, resume (hal yang kami unggah ke situs web perekrut sehingga kami bisa mendapatkan panggilan telepon dan email tanpa henti selama 7 tahun ke depan) adalah kata dalam bahasa Prancis.
Kamus juga mendefinisikan jenis kata apa itu (kata benda, kata kerja, kata sifat, dll). Ini bukan hanya sepotong teks: "kata benda" itu memiliki makna juga. Ditambah dengan database relasional Anda dapat mengatakan hal-hal seperti "berikan saya semua kata benda untuk bahasa Inggris" dan karena database yang dinormalisasi akan menggunakan kunci asing, dan kunci asing memiliki (atau seharusnya memiliki) indeks, pencarian akan menjadi mudah.
Pikirkan bagaimana kata-kata diucapkan. Khususnya dalam bahasa Inggris, banyak kata memiliki pengucapan yang sama (lihat contoh saya di atas dengan baca dan alang-alang, atau baca dan merah).

Pelafalan suatu kata adalah kata itu sendiri. Database relasional akan memungkinkan Anda untuk menggunakan kunci asing untuk pengucapan apa pun. Informasi itu tidak akan diduplikasi dalam basis data relasional. Itu digandakan seperti orang gila di database no-SQL.
Dan sekarang mari kita bicara tentang versi kata jamak dan tunggal. :) Pikirkan "perahu" dan "perahu". Atau fakta bahwa sebuah kata "tunggal" atau "jamak".
Oh! Dan sekarang mari kita bicara tentang past tense, present tense, future tense dan present participle (jujur, saya tidak tahu apa itu "present participle". Saya pikir itu ada hubungannya dengan kata-kata yang berakhiran "ing" di Bahasa Inggris atau sesuatu).

Cari "lari" dan Anda akan melihat bentuk lainnya: berlari, berlari, berlari

Bahkan, "tegang" adalah hubungan lain itu sendiri.
Bahasa Inggris tidak banyak melakukan hal ini, tetapi gender adalah hal lain yang mendefinisikan sebuah kata. Bahasa seperti Spanyol memiliki akhiran yang menentukan apakah subjek dari kata benda adalah pria atau wanita. Jika Anda perlu mengisi bagian yang kosong untuk kalimat, gender sangat penting dalam banyak bahasa.

Karena Anda tidak selalu dapat bergantung pada konvensi bahasa untuk menentukan jenis kelamin (dalam bahasa Spanyol, kata-kata yang berakhiran "o" adalah maskulin / laki-laki, tetapi itu tidak berlaku untuk semua kata), Anda memerlukan nilai identifikasi: Pria atau Wanita. Ini adalah hubungan lain yang ditangani oleh database yang dinormalisasi dengan anggun bahkan pada jutaan catatan.

Dengan semua aturan yang bengkok dan hubungan antara kata-kata, dan bahkan bahasa yang berbeda, sulit bagi saya untuk membayangkan penyimpanan data ini sebagai "penyimpanan dokumen" seperti yang disediakan oleh solusi no-SQL. Ada begitu banyak dan begitu banyak variasi hubungan antara kata dan komponennya sehingga database relasional adalah satu-satunya solusi yang masuk akal.

— Greg Burghardt
sumber

7

Untuk # 1, pengindeksan sering kali merupakan salah satu kekuatan dari penawaran non-relasional, bukan kelemahan.

— JimmyJames

61

@ JimmyJames. Jangan berpikir sejenak bahwa sistem relasional tidak menggunakan jenis indeks yang sama. Banyak dari teknik itu dipelopori di dunia itu.

— Blrfl

14

"Setiap kali Anda melihat kata" terkait "pikirkan" Database Relasional "". Saya tidak setuju. "Relasional" dalam "basis data relasional" mengacu pada tupel itu sendiri. Terkait adalah istilah yang terlalu luas untuk pernyataan ini untuk menampung air

— kepala kebun

12

Ada juga basis data grafik (Neo4j muncul di benak) yang secara eksplisit difokuskan pada hubungan traversing daripada melakukan penggabungan tradisional. Ini mungkin menguntungkan mengingat bahwa banyak kamus sebenarnya adalah jaringan kata-kata; misalnya, proyek WordNet menggunakan format seperti grafik sendiri, bukan RDMS tradisional.

— tucuxi

4

Saya menurunkan jawaban ini hanya untuk "Setiap kali Anda melihat kata 'related' think 'Relational Database'." Itu konyol . Saya suka basis data relasional, tetapi model relasional tidak sesuai untuk semua jenis hubungan. Pandangan Anda tentang data yang dinormalkan juga sepenuhnya salah. Normalisasi data mengoptimalkan pengeditan , karena data tidak digandakan, bukan pencarian. (Itu sebabnya pelaporan DB tidak menjadi normal. Mereka menggunakan teknik pemodelan dimensi dan skema bintang.) Saya pikir Anda tidak tahu apa yang Anda bicarakan. 80 upvotes mengkonfirmasi semua kekhawatiran saya tentang saran di situs ini.

— jpmc26

27

Jika Anda menggunakan kunci-nilai toko (yang menawarkan Anda model pemrograman yang lebih miskin) dan ternyata Anda membutuhkan lebih banyak struktur (dalam kasus Anda, katakanlah, tambahkan bahasa ketiga), atau Anda perlu melakukan kueri yang lebih kompleks yang melibatkan gabungan , Anda akan menghabiskan banyak waktu mengatur ulang kunci Anda, mendenormalkan data Anda, dan / atau mengulang semua data untuk menemukan apa yang Anda butuhkan.

Jika Anda mulai dengan database relasional, Anda dapat bekerja melalui desain, kode aplikasi Anda, dan mencobanya lebih berkonsentrasi pada model data alami untuk aplikasi Anda, daripada memilihnya menjadi bentuk nilai kunci.

Setelah aplikasi selesai, Anda dapat bekerja pada kinerja, dengan mengukur berbagai opsi. Ada beberapa trik kinerja yang harus dilakukan dalam SQL sebelum perlu beralih teknologi. Anda akan belajar banyak tentang aplikasi Anda dan akan berada dalam posisi yang jauh lebih baik untuk memutuskan apakah hubungan merugikan Anda dan apakah nilai kunci akan bekerja untuk model data Anda.

Jika ternyata nilai kunci persis seperti yang dibutuhkan aplikasi Anda, Anda dapat beralih tanpa membuang-buang investasi yang signifikan dalam model relasional, sedangkan sebaliknya Anda mungkin berakhir dengan membuang-buang waktu membuat model nilai kunci melakukan hal-hal yang sepele dalam model relasional.

Pertimbangkan basis data relasional sebagai akselerator untuk membuat aplikasi Anda dirancang, ditulis, dan dijalankan, dalam menghadapi persyaratan yang terus berubah saat Anda mempelajari lebih lanjut tentang domain dan pengguna Anda.

Ketika Anda memiliki jutaan pengguna, Anda hampir pasti perlu memperbaiki desain, walaupun Anda telah memilih nilai kunci untuk memulainya.

— Erik Eidt
sumber

13

Epilog dalam artikel ini menjelaskan persis skenario perubahan persyaratan yang membatalkan desain. Ini menggambarkan satu aplikasi (nyata) sebagai "kasus penggunaan yang sempurna untuk MongoDB", tetapi kemudian menggambarkan bagaimana perubahan yang relatif kecil dalam persyaratan, yang sepele untuk diterapkan dalam RDBMS, membutuhkan jumlah pekerjaan yang layak dan akan memindahkannya untuk kasus penggunaan yang (seperti yang dijelaskan bagian sebelumnya dari artikel) sangat banyak bukan kasus penggunaan yang baik dari Mongo.

— Derek Elkins

5

Artikel MongoDB Sarah adalah persis apa yang kami alami dengan produk 1.0 yang kami buat dengan menggunakannya; oleh 1.1 kami menggunakan Postgres.

— Joe

@DerekElkins, referensi super, thx!

— Erik Eidt

1

"tetapi kemudian menjelaskan bagaimana perubahan yang relatif kecil dalam persyaratan, itu akan sepele untuk diterapkan dalam RDBMS" Tentu, tetapi yang terjadi adalah sebaliknya. Kami menggunakan RDBMS di tempat kerja dan menghadapi masalah yang sepele untuk dipecahkan di MongoDB. Anehnya, persyaratan perangkat lunak tidak selalu memetakan dengan sempurna kemampuan perangkat yang kami gunakan.

— NPSF3000

@ NPSF3000, akan luar biasa jika Anda bisa mengutip referensi, seperti blog atau teks yang diuraikan tentang itu!

— Erik Eidt

10

Untuk database sekecil ini, mungkin tidak akan membuat banyak perbedaan untuk kinerja. RDBMS standar bukan ide yang buruk di sini karena mungkin, seharusnya ada lebih banyak membaca daripada menulis entri yang diberikan. Performa sepertinya tidak menjadi pendorong utama untuk ini. Caching di lapisan aplikasi juga mengurangi kekhawatiran tersebut.

Pertimbangan lainnya adalah replikasi dan ketahanan. Database relasional cenderung dirancang berdasarkan satu instance. Anda harus membaca teorema CAP dan mempertimbangkan apa yang paling penting bagi Anda.

— JimmyJames
sumber

Bagaimana CAP berlaku untuk aplikasi web yang relatif normal? Tergantung pada kit Anda, kemungkinan Anda dapat mempertahankan ribuan koneksi masuk dan lapisan cache halaman dapat meningkatkannya dengan urutan magnutude. CAP hanya mulai menjadi sesuatu yang perlu Anda pertimbangkan ketika sistem terdistribusi adalah satu - satunya cara untuk mencapai tujuan Anda.

— Ben

2

@Ben Resiliency adalah tujuan dalam dirinya sendiri. Jika memiliki satu titik kegagalan tidak dapat diterima untuk suatu aplikasi, solusi terdistribusi menawarkan solusi. Solusi non-RDBMS cenderung lebih berorientasi pada hal ini. Ini bukan sekadar volume untuk dipertimbangkan. Latensi dan ketersediaan menjadi perhatian. Jika kebutuhan Anda adalah memiliki 99,9% waktu aktif. Anda hanya bisa turun selama sekitar 9 jam setahun dan kehilangan data dalam satu db adalah bencana sehingga Anda harus memperhitungkan replikasi / cadangan / snapshot. Ini salah arah untuk berpikir bahwa itu selalu menyederhanakan hal-hal.

— JimmyJames

2

Basis data NoSQL ini selalu terdengar seperti ide yang bagus sejak awal, tetapi Anda akan dijamin akan mengalami masalah ketika Anda mulai berurusan dengan kasus tepi (misalnya, di mana kata kunci harus dilihat dengan melihat nilainya (atau bagian dari) misalnya.

Ini akan menjadi pilihan yang lebih aman untuk pergi dengan database relasional pada awalnya dan kemudian tidak normal lagi. MySQL mengagumkan untuk tujuan semacam ini (database relasional sederhana dengan pencarian berbasis teks), tidak ada terlalu banyak kasus penggunaan di mana Anda akan merasa kesulitan dengan data semacam ini. Pastikan indeks Anda sudah diatur dengan benar dan Anda akan menemukannya akan bekerja pada tingkat yang sebanding (atau lebih baik ketika melakukan pencarian teks) ke database NoSQL, dan itu akan memberi Anda fleksibilitas untuk memodifikasi logika aplikasi Anda tanpa menjadi terikat pada struktur data yang konkret.

Ketika Anda menemukan penggunaan data yang paling umum (dan jika Anda merasa itu tidak memenuhi kebutuhan kinerja Anda), Anda kemudian dapat melanjutkan untuk menormalkan data dengan mengeluarkan ke format yang dapat dimasukkan ke (dan diambil dari) skema NoSQL.

— joel.cass
sumber