Чому використання MySQL для веб-сайту словника погана ідея?

Я планую розробити та створити базу даних для зберігання записів у словнику (як правило, окремих слів) та їх значення іншою мовою. Так, наприклад, Глосарій таблиці повинен мати запис та визначення, і кожен запис таблиці має посилання на ідентифікатор запису, що зберігається в Tag(Кожен запис повинен мати тег або категорію).

Оскільки мої дані мають структуру, я вважав, що використання бази даних SQL (як MySQL) не є поганою ідеєю; але люди кажуть, що MongoDB набагато кращий за продуктивність.

На стороні клієнта програма повинна мати можливість надати поле пошуку з автозаповненням, яке використовує API REST, наданий резервним сервером. Чи безпечно їхати з MySQL за таким сценарієм? або я повинен використовувати MongoDB або ElasticSearch для будь-якого іншого рішення для цього? Передбачається, що таким чином зберігаються та мають доступ до сотні тисяч записів.

Я не можу вам сказати, чому це погана ідея. Я можу розповісти вам багато причин, чому реляційна база даних є гарною ідеєю.

1. Пам'ятайте, що не кожен звертається до словника для визначення. Більше разів використовується словник, щоб знайти правильний написання. Це означає, що ви не просто знаходите голку в копиці сіна , ви шукаєте стоги сіна, схожі на описані користувачем (якщо я можу використовувати ідіому).

   Ви не будете просто робити перегляди первинного ключа. Ви будете робити пошук за ключовими словами

2. Слова можуть бути спорідненими як за значенням, так і за написанням ( читати, читати , червоними та очеретяними )

   Щоразу, коли ви бачите слово "споріднене", думайте "Реляційна база даних"

3. Якщо вам потрібна швидкість, вам потрібно кешування поверх вашої реляційної бази даних, а не розбита модель реляційних даних

4. Правильно нормалізована база даних прискорює пошук і пошук первинного ключа, оскільки для просіювання є просто менше біт.

5. Люди, які говорять про нормалізацію баз даних повільніше, посилаються на 0,1% випадків, коли це правда. В інших 99,9% випадків вони фактично не працювали з справді нормалізованою базою даних, щоб побачити продуктивність з перших рук, тому ігноруйте їх. Я працював з нормалізованою базою даних. Любіть це. Не хочу повертатися назад. І я не хлопець із бази даних. Я хлопець C # / JavaScript / HTML / Ruby.

6. Слова мають походження. Насправді багато слів однією мовою можуть мати те саме походження, що є іншим словом на іншій мові. Наприклад, резюме (те, що ми завантажуємо на веб-сайти рекрутерів, щоб ми могли отримувати постійні телефонні дзвінки та електронні листи протягом наступних 7 років) - французьке слово.

7. Словник також визначає, яке це слово (іменник, дієслово, дієприкметник). Це не просто фрагмент тексту: "іменник" він також має значення. Крім того, за допомогою реляційної бази даних ви можете сказати такі речі, як "дайте мені всі іменники для англійської мови", і оскільки нормалізована база даних буде використовувати іноземні ключі, а зовнішні ключі мають (або повинні мати) індекси, пошук буде швидким.

8. Подумайте, як вимовляються слова. Особливо англійською мовою багато слів мають однакову вимову (див. Мій приклад вище з читанням і очеретом, або з читанням і червоним).

   Вимова слова - саме по собі інше слово. Реляційна база даних дозволить вам використовувати іноземні ключі для будь-якої вимови. Ця інформація не буде дублюватися у реляційній базі даних. Він стає дублюватися як божевільний у базі даних без SQL.

9. А тепер поговоримо про множину та однину варіантів слів. :) Подумайте "човен" і "човен". Або сам факт, що слово є "одниною" або "множиною".

10. Ой! А тепер поговоримо про минулий час, теперішній час, майбутнє час і теперішній дієприкметник (якщо чесно, я не знаю, що таке лайно "дієприкметник". Я думаю, що це має щось спільне зі словами, що закінчуються на "ing" в Англійська мова чи щось таке).

    Подивіться "біжіть", і ви повинні побачити інші часи: бігав, бігає, бігає

    Насправді "напружений" - це вже самі відносини.

11. Англійська робить це не так сильно, але гендер - це ще одна річ, яка визначає слово. Такі мови, як іспанська, мають суфікси, які визначають, чи є предмет іменника чоловічим чи жіночим. Якщо вам потрібно заповнити пробіли для речення, гендер є надзвичайно важливим у багатьох мовах.

    Оскільки ви не завжди можете розраховувати на мовні конвенції для визначення статі (в іспанській мові слова, що закінчуються на "o", є чоловічим / чоловічим, але це не вірно для всіх слів), вам потрібно ідентифікаційне значення: Чоловік або Жінка. Це ще одне співвідношення, з яким нормалізована база даних витончено обробляє навіть мільйони записів.

Зі всіма перекрученими правилами та взаємозв'язками між словами та навіть різними мовами мені важко уявити цей сховище даних як "сховище документів", як передбачено рішення, яке не містить SQL. Між словами і їх компонентами існує стільки і таке велике різноманіття, що реляційна база даних є єдиним розумним рішенням.

Якщо ви працюєте з магазином ключових значень (який пропонує вам більш збіднілу модель програмування), і виявляється, вам потрібна більша структура (у вашому випадку, скажімо, додавання третьої мови), або вам потрібно робити більш складні запити, що включають приєднання , ви витратите купу часу на реорганізацію ваших ключів, денормалізацію своїх даних та / або прокручування всіх даних, щоб знайти те, що вам потрібно.

Якщо ви почнете з реляційної бази даних, ви можете опрацювати дизайн, код і застосувати додаток, сконцентрувавшись більше на природній моделі даних для вашої програми, а не на введенні її у форму ключового значення.

Після того, як додаток відстоюється, ви можете працювати над продуктивністю, вимірюючи різні варіанти. Перед тим, як перейти на комутацію технологій, слід виконати в SQL досить багато хитрощів. Ви дізнаєтесь багато про свою заявку, і зможете вирішити, чи зашкодить вам реляційний зв'язок і чи допоможе ключ-значення для вашої моделі даних.

Якщо виявиться, що ключова цінність - саме те, що потрібно вашій програмі, ви можете переключитися, не витрачаючи значних вкладень у реляційну модель, тоді як навпаки, можливо, ви витратите час, роблячи модель ключових значень робити те, що є тривіальне в реляційній моделі.

Розгляньте реляційну базу даних як прискорювач для розроблення програми, написання та створення додатків відповідно до постійно змінюваних вимог, коли ви дізнаєтесь більше про свій домен та користувачів.

Коли у вас мільйони користувачів, вам майже напевно потрібно буде переробити дизайн все одно, навіть якщо ви вибрали ключове значення для початку.

Для такої невеликої бази даних це, мабуть, не має великої різниці в продуктивності. Стандартна RDBMS тут не страшна ідея, оскільки, мабуть, має бути набагато більше читань, ніж записів заданого запису. Продуктивність, здається, не є головним рушієм для цього. Кешування в шарі додатків також зменшує такі проблеми.

Інший розгляд - це тиражування та стійкість. Реляційні бази даних, як правило, створюються навколо одного екземпляра. Вам слід прочитати теорему CAP та подумати, що для вас найбільше важливо.

Ці бази даних NoSQL завжди здаються гарною ідеєю з самого початку, але вам гарантовано виникнуть проблеми, коли ви почнете мати справу з кращими справами (наприклад, якщо ключові слова повинні, наприклад, шукати їх значення (або частина).

Більш безпечним варіантом було б спочатку скористатися реляційною базою даних, а потім пізніше денормалізувати. MySQL є приголомшливим для такої мети (прості реляційні бази даних з текстовим пошуком), не так вже й багато випадків використання, коли ви виявите, що вони борються з подібними даними. Просто переконайтеся, що ваші індекси налаштовані правильно, і ви побачите, що вони працюватимуть на рівні, порівнянному (або кращому під час пошуку тексту) з базою даних NoSQL, і це дасть вам можливість змінювати логіку програми, не будучи пов'язана з конкретною структурою даних.

Коли ви знайдете найбільш поширене використання своїх даних (і якщо ви коли-небудь виявите, що це не відповідає вашим потребам в продуктивності), ви можете перейти до денормалізації даних, вивівши у встановлений формат, який можна завантажувати (і витягувати з нього) схема NoSQL.