Neden bir sözlük sitesi için MySQL kullanmak kötü bir fikir?

Sözlük girişlerini (genellikle tek kelimeler) ve bunların anlamlarını başka bir dilde saklamak için bir veritabanı tasarlamayı ve düzenlemeyi planlıyorum. Bu nedenle, örneğin, Sözlük tablosunda giriş ve tanım bulunmalı ve her tablo kaydında saklanan bir kaydın kimliğine bir atıfta bulunmalıdır Tag(Her kayıtta bir etiket veya kategori olmalıdır).

Verilerim bir yapıya sahip olduğundan, bir SQL veritabanı kullanmanın (MySQL gibi) kötü bir fikir olmadığını düşündüm; Ancak insanlar MongoDB'nin performans için daha iyi olduğunu söylüyor.

İstemci tarafında, uygulamanın, arka uç tarafından sağlanan bir REST API'sini tüketen otomatik tamamlama özelliğine sahip bir arama kutusu sağlayabilmesi gerekir. Böyle bir senaryoda MySQL ile gitmek güvenli midir? Ya da MongoDB veya ElasticSearch'ü bunun için başka bir çözüm kullanmalı mıyım? Bu şekilde yüz binlerce kaydın saklanması ve erişilmesi gerekiyor.

Bunun neden kötü bir fikir olduğunu söyleyemem. İlişkisel bir veritabanının neden iyi bir fikir olduğu konusunda size birkaç neden söyleyebilirim .

1. Herkesin bir tanım için bir sözlük istemediğini unutmayın. Şundan çok kez, doğru yazımı bulmak için bir sözlük kullanılır. Bu, sadece bir samanlıkta iğne bulamadığınız anlamına gelir , kullanıcı tarafından tarif edilene benzer iğneler ararsınız (bir deyim kullanabilirsem).

   Sadece birincil anahtar aramaları yapmayacaksınız. Anahtar kelime aramaları yapacaksınız

2. Kelimelerin anlamı veya imla ile ilgisi olabilir ( oku, oku , kırmızı ve kamış )

   Ne zaman "ilgili" kelimesini gördüğünüzde "İlişkisel Veri Tabanı" deyin

3. Hıza ihtiyacınız varsa, bozuk bir ilişkisel veri modelini değil, ilişkisel veritabanınızı önbelleğe almanız gerekir.

4. Düzgün bir şekilde normalize edilmiş bir veritabanı, atılması gereken daha az bit olduğundan birincil anahtar aramalarını ve aramaları hızlandırır.

5. Normalleştirilmiş veritabanlarının daha yavaş olduğunu söyleyenler bunun doğru olduğu vakaların% 0,1'ini kastediyor. Olguların diğer% 99.9 onlar değil aslında performans ilk elden görmek, bu yüzden onları görmezden gerçekten normalize veritabanı ile çalıştı. Normal bir veritabanıyla çalıştım. Sevdim. Geri dönmek istemiyorum. Ve ben veritabanı görevlisi değilim. Ben bir C # / JavaScript / HTML / Ruby adamım.

6. Kelimelerin kökeni var. Aslında, aynı dilde birçok kelime farklı bir dilde başka bir kelime olan aynı kökene sahip olabilir. Mesela, özgeçmiş (işverenlerin web sitelerine yüklediğimiz ve önümüzdeki 7 yıl boyunca sürekli telefon görüşmeleri ve e-postalar alabilmemiz için kullanılan) Fransızca bir kelimedir.

7. Sözlük aynı zamanda ne tür bir kelime olduğunu da tanımlar (isim, fiil, sıfat vb.). Bu sadece bir metin parçası değil: "isim" de anlamı var. Ayrıca ilişkisel bir veritabanı ile "bana İngilizce dilindeki tüm isimleri ver" gibi şeyler söyleyebilirsiniz ve normalize edilmiş bir veritabanı yabancı anahtarlar kullanacağından ve yabancı anahtarların (veya olması gereken) dizinleri olduğundan, arama çok kolay olacaktır.

8. Kelimelerin nasıl telaffuz edildiğini düşünün. Özellikle İngilizce'de birçok kelime aynı telaffuza sahip (yukarıdaki örneğime okuma ve reed veya okuma ve kırmızı ile bakın).

   Bir kelimenin telaffuzu, kendisi, başka bir kelimedir. İlişkisel bir veritabanı, herhangi bir telaffuz için yabancı anahtar kullanmanıza izin verir. Bu bilgi ilişkisel bir veritabanında çoğaltılmaz. SQL olmayan bir veritabanında deli gibi çoğaltılır.

9. Şimdi kelimelerin çoğul ve tekil versiyonlarından bahsedelim. :) "Kayığı" ve "kayığı" düşünün. Veya bir kelimenin "tekil" veya "çoğul" olduğu gerçeğidir.

10. Ah! Ve şimdi en geçmiş zaman, şimdiki zaman, gelecek zaman ve şimdiki sıfat bahsedelim (dürüst olmak gerekirse, ben bok "Mevcut ortacı" ne olduğunu bilmiyorum. Ben de "ing" ile biten kelimeler ile ilgili bir şey olduğunu düşünüyorum İngilizce ya da bir şey).

    "Koş" u ara ve diğer zamanları görmelisin: koş, koş, koş

    Aslında "gergin" bir başka ilişkidir.

11. İngilizce bunu pek yapmaz, ancak cinsiyet, bir kelimeyi tanımlayan başka bir şeydir. İspanyolca gibi diller, ismin öznesinin erkek mi kadın mı olduğunu tanımlamaktadır. Bir cümle için boşlukları doldurmanız gerekirse, birçok dilde cinsiyet çok önemlidir.

    Cinsiyeti belirlemek için her zaman dil sözleşmelerine güvenemeyeceğinizden (İspanyolca olarak, "o" ile biten kelimeler eril / erkek, ancak tüm kelimeler için bu doğru değildir), tanımlayıcı bir değere ihtiyacınız var: Erkek veya Kadın. Bu normalize edilmiş bir veritabanının milyonlarca kayıtta bile incelikle ele aldığı başka bir ilişkidir.

Tüm bükülmüş kurallar ve kelimeler ve hatta farklı diller arasındaki ilişkiler sayesinde, bu veri deposunu SQL-olmayan bir çözüm gibi bir "belge deposu" olarak düşünmek zor. Sözler ve bileşenleri arasında çok fazla ve çok çeşitli ilişkiler vardır, ilişkisel bir veritabanı tek mantıklı çözümdür.

Anahtar-değer deposuyla giderseniz (size daha fakirleştirilmiş bir programlama modeli sunar) ve daha fazla yapıya ihtiyacınız varsa (sizin durumunuzda, örneğin üçüncü bir dil ekleyerek) ya da katılımlarla ilgili daha karmaşık sorgular yapmanız gerekiyor. , ihtiyacınız olanı bulmak için anahtarlarınızı yeniden düzenlemek, verilerinizi normalleştirmek ve / veya tüm verilerde dolaşmak için çok zaman harcayacaksınız.

İlişkisel bir veritabanıyla başlarsanız, uygulamanızın tasarımı, kodu ile çalışabilir ve onu anahtar-değer formuna koymak yerine, uygulamanız için doğal veri modeline yoğunlaşarak deneyebilirsiniz.

Uygulama kapandığında, çeşitli seçenekleri ölçerek performans üzerinde çalışabilirsiniz. Teknolojileri değiştirmek zorunda kalmadan önce SQL'de yapılması gereken birkaç performans püf noktası vardır. Başvurunuz hakkında çok şey öğrendiniz ve ilişkiselinizin sizi incitip incitmeyeceğine ve veri modeliniz için anahtar değerin işe yarayıp yaramadığına karar vermek için daha iyi bir konumda olacaksınız.

Anahtar-değerin uygulamanızın tam olarak ihtiyaç duyduğu şey olduğu ortaya çıkarsa, ilişkisel modelde kayda değer bir yatırım yapmadan geçiş yapabilirsiniz, oysaki çevrenizdeki diğer yol, anahtar-değer modelini yapmak için zaman harcamanıza neden olabilir. ilişkisel modelde önemsiz.

İlişkisel veritabanınızı, etki alanınız ve kullanıcılarınız hakkında daha fazla şey öğrenirken sürekli değişen gereksinimler karşısında uygulamanızı tasarlamanızı, yazmanızı ve çalıştırmanızı sağlamak için bir hızlandırıcı olarak düşünün.

Milyonlarca kullanıcınız olduğunda, başlangıçta bir anahtar-değer seçmiş olsanız bile, kesinlikle tasarımı yine de yeniden düzenlemelisiniz.

Bu kadar küçük bir veri tabanı için muhtemelen performans açısından pek bir fark yaratmayacak. Standart bir RDBMS burada berbat bir fikir değil, çünkü belli bir girişin yazdıklarından çok daha fazla okunması gerekiyor. Performans bunun için birincil bir sürücü gibi görünmüyor. Uygulama katmanında önbellekleme ayrıca bu endişeleri azaltır.

Diğer bir husus, çoğaltma ve esnekliktir. İlişkisel veritabanları, tek bir örnek çevresinde tasarlanma eğilimindedir. CAP teoremini okumalı ve sizin için en önemli olanı düşünmelisiniz.

Bu NoSQL veritabanları, başlangıçta her zaman iyi bir fikir gibi görünür, ancak örneğin, örneğin, anahtar kelimelerin değerlerine göre (veya bunların bir kısmına göre bakılması gereken), uç vakalarla uğraşırken sorunla karşılaşmanız garanti edilir.

Başlangıçta ilişkisel bir veritabanı ile gitmek ve daha sonra denormalize etmek daha güvenli bir seçenek olacaktır. MySQL bu amaç için mükemmeldir (metin tabanlı arama ile basit ilişkisel veritabanları), bu tür verilerle uğraşırken bulacağınız çok fazla kullanım örneği yoktur. Dizinlerinizin doğru kurulduğundan emin olun ve bir NoSQL veritabanına göre karşılaştırılabilir bir seviyede (veya bir metin araması yaparken daha iyi bir performans gösterecek) bulunmasını sağlayın ve uygulama mantığınızı değiştirmeden değiştirme esnekliği sunar. somut bir veri yapısına bağlı.

Verilerinizin en yaygın kullanımını bulduğunuzda (ve performans gereksinimlerinizi karşılamadığını görürseniz), yüklenebilecek (ve alınabilecek) bir ayar biçimine çıkarak verileri normalize etmeye devam edebilirsiniz. NoSQL şeması.