Почему использование MySQL для словарного сайта - плохая идея?

55

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

Поскольку мои данные имеют структуру, я подумал, что использование базы данных SQL (например, MySQL) - неплохая идея; но люди говорят, что MongoDB намного лучше для производительности.

На стороне клиента приложение должно быть в состоянии предоставить в поле поиска автозаполнение, которое использует API REST, предоставляемый серверной частью. Безопасно ли использовать MySQL в таком сценарии? или я должен использовать MongoDB или ElasticSearch любого другого решения для этого? Сотни тысяч записей должны быть сохранены и доступны таким образом.

Азиз Аз
источник
79
Люди, рассказывающие вам вещи, не сделали много исследований в этом. Язык с самым большим словарным запасом, английский, содержит менее миллиона отдельных слов. Это вполне в пределах возможностей производительности реляционной БД.
TheCatWhisperer
25
Я не вижу здесь ничего такого, что заставило бы меня думать, что MySQL не будет работать для этого. Производительность при простом поиске не будет проблемой, и он имеет полнотекстовый поиск, если вам нужно пойти по этому пути.
GrandmasterB
46
Относительно "MongoDB намного лучше для производительности" - как неизмененное утверждение без пояснения области, это чепуха ранга. Например, см. Раздел Инструменты командной строки могут быть в 235 раз быстрее, чем ваш кластер Hadoop (на который я натолкнулся по ссылке в «Кризис ожирения на веб-сайте» ).
Wildcard
82
Я так устал от людей, которые говорят, что реляционные базы данных - это плохо, а MongoDB лучше, потому что это быстрее. Это все равно что говорить, что машины плохие, и мы должны использовать самолеты, потому что они летят быстрее. Мой совет - игнорировать подобные советы.
Брэндон
13
@Brandon Печально то, что все утверждения «NoSQL намного быстрее» обычно сводятся к некоторому теоретическому объяснению того, почему они должны быть намного лучше, но на практике это даже не применимо для многих реальных сценариев. Смотрите, например, здесь . Их используемый набор тестов является открытым исходным кодом и доступен на github. Адский ЦЕРН прекрасно справляется с ПБ своих данных с помощью OracleDB.
Voo

Ответы:

95

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

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

    Вы не просто будете искать первичный ключ. Вы будете делать поиск по ключевым словам

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

    Всякий раз, когда вы видите слово «связанные», думайте «Реляционная база данных»

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

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

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

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

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

  8. Подумайте, как произносятся слова. Особенно в английском языке многие слова имеют одинаковое произношение (см. Мой пример выше с надписью «Рид» и «Рид» или «Рид и красный»).

    Произношение слова само по себе другое слово. Реляционная база данных позволит вам использовать внешние ключи для любых произношений. Эта информация не будет дублироваться в реляционной базе данных. Он дублируется как сумасшедший в базе данных без SQL.

  9. А теперь давайте поговорим о множественном и единственном числе слов. :) Подумайте «лодка» и «лодки». Или тот факт, что слово «единственное число» или «множественное число».

  10. Ой! А теперь давайте поговорим о прошедшем времени, настоящем времени, будущем времени и причастии настоящего времени (если честно, я не знаю, что такое хрень «причастие настоящего». Я думаю, что это как-то связано со словами, заканчивающимися на «ing» в Английский или что-то).

    Посмотрите вверх «бежать», и вы должны увидеть другие времена: бег, бег, бег

    На самом деле «напряженное» само по себе является другим отношением.

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

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

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

Грег Бургхардт
источник
7
Для # 1 индексация часто является одной из сильных сторон нереляционных предложений, а не слабостью.
JimmyJames
61
@JimmyJames Не думайте ни на минуту, что реляционные системы не используют одинаковые индексы. Многие из этих методов были впервые в этом мире.
Blrfl
14
«Всякий раз, когда вы видите слово« связанный », думайте« Реляционная база данных »». Я не согласна «Реляционный» в «реляционной базе данных» относится к самим кортежам. Этот термин слишком широк для данного утверждения, чтобы держать в нем какую-либо воду
глава сада
12
Существуют также базы данных графов (на ум приходит Neo4j), которые явно ориентированы на обход связей, а не на выполнение традиционных объединений. Это может быть выгодно, учитывая, что многие словари на самом деле являются паутиной слов; например, проект WordNet использует свой собственный графоподобный формат вместо традиционного RDMS.
Tucuxi
4
Я отклонил этот ответ только за то, что «всякий раз, когда вы видите слово« связанный », думайте« Реляционная база данных »». Это смешно . Я люблю реляционные базы данных, но реляционная модель подходит не для всех видов отношений. Ваше представление о нормализованных данных также совершенно неверно. Нормализация данных оптимизирует редактирование , поскольку данные не дублируются, а не выполняются поиски. (Вот почему отчетные БД не нормализуются. Они используют методы размерного моделирования и звездные схемы.) Не думаю, что вы знаете, о чем говорите. 80 голосов подтверждают все мои опасения по поводу советов на этом сайте.
jpmc26
27

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

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

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

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

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

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

Эрик Эйдт
источник
13
Эпилог в этой статье описывает сценарий изменения требований, лишающих законной силы дизайн. Он описывает одно (реальное) приложение как «идеальный вариант использования для MongoDB», но затем описывает, как относительно незначительное изменение требований, которое было бы тривиально для внедрения в СУБД, требовало приличного объема работы и перенесло бы его для варианта использования, который (как объясняют предыдущие части статьи) очень не очень хороший вариант использования Mongo.
Дерек Элкинс
5
Статья Сары о MongoDB - это именно то, что мы изучили с помощью продукта 1.0, который мы создали с его помощью; на 1.1 мы использовали Postgres.
Джо
@DerekElkins, супер ссылка, спасибо!
Эрик Эйдт
1
«но затем описывает, как относительно незначительное изменение требований, которое было бы тривиально для внедрения в СУБД» Конечно, но верно обратное. Мы используем RDBMS на работе и сталкиваемся с проблемами, которые было бы тривиально решить в MongoDB. Как ни странно, требования к программному обеспечению не всегда идеально соответствуют возможностям используемых нами инструментов.
NPSF3000
@ NPSF3000, было бы замечательно, если бы вы могли ссылаться на ссылку, например, на блог или какой-то другой текст, посвященный этому вопросу!
Эрик Эйдт
10

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

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

JimmyJames
источник
Как CAP применяется к относительно нормальному веб-приложению? В зависимости от вашего комплекта, вероятно, вы сможете поддерживать тысячи входящих соединений, а уровень кэширования страниц может увеличить его на порядок. CAP начинает становиться тем, что вам нужно учитывать, когда распределенные системы являются единственным способом достижения вашей цели.
Бен
2
Устойчивость @Ben - сама по себе цель. Если наличие одной точки отказа неприемлемо для приложения, распределенные решения предлагают решение. Решения, не относящиеся к РСУБД, как правило, более ориентированы на это. Это не просто объем для рассмотрения. Задержка и доступность являются проблемами. Если ваше требование - 99,9% безотказной работы. Вы можете быть недоступны только около 9 часов в год, и потеря данных в одной БД катастрофична, поэтому вам необходимо учитывать репликацию / резервное копирование / снимки. Ошибочно думать, что это обязательно упрощает вещи.
JimmyJames
2

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

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

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

joel.cass
источник