Почему использование 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. Английский не делает это так много, но пол - это еще одна вещь, которая определяет слово. Такие языки, как испанский, имеют суффиксы, определяющие, является ли предмет существительного мужской или женский. Если вам нужно заполнить пробелы в предложении, пол очень важен во многих языках.

    Поскольку вы не всегда можете полагаться на языковые соглашения для определения пола (на испанском языке слова, оканчивающиеся на «о», являются мужскими / мужскими, но это не относится ко всем словам), вам необходимо идентифицирующее значение: мужской или женский. Это еще одно отношение, которое нормализованная база данных корректно обрабатывает даже для миллионов записей.

При всех запутанных правилах и отношениях между словами и даже разными языками мне трудно представить это хранилище данных как «хранилище документов», как решение без SQL. Существует так много и такое большое разнообразие отношений между словами и их компонентами, что реляционная база данных является единственным разумным решением.

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

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

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

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

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

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

Для такой небольшой базы данных, вероятно, не будет иметь большого значения для производительности. Стандартная СУБД не является ужасной идеей, потому что, по-видимому, должно быть гораздо больше операций чтения, чем записи данной записи. Производительность не является основным фактором для этого. Кэширование на уровне приложений также смягчает такие проблемы.

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

Эти базы данных NoSQL всегда звучат как хорошая идея с самого начала, но вы гарантированно столкнетесь с проблемами, когда начнете работать с крайними случаями (например, когда ключевые слова должны быть найдены, например, по их значению (или части).

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

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