Максимальные возможности MySQL

Question

Как узнать, когда проект слишком велик для MySQL, и я должен использовать что-то с лучшей репутацией для масштабируемости?

Существует ли максимальный размер базы данных для MySQL до того, как произойдет снижение производительности? Какие факторы способствуют тому, что MySQL не является жизнеспособным вариантом по сравнению с коммерческими СУБД, такими как Oracle или SQL Server?

Answer 1

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

Одна проблема, с которой вы можете столкнуться, заключается в том, что индекс размером более 4 гигабайт не может войти в память. Однажды я потратил много времени, пытаясь улучшить полнотекстовую производительность MySQL, манипулируя некоторыми параметрами индекса, но вы не можете обойти фундаментальную проблему, заключающуюся в том, что если ваш запрос попадает на диск для индекса, он работает медленно.

Вы можете найти несколько вспомогательных приложений, которые помогут решить вашу проблему. Для полнотекстовой задачи есть Sphinx: http://www.sphinxsearch.com/

У Джереми Заводни, который сейчас работает в списке Крейга, есть блог, в котором он иногда обсуждает производительность больших баз данных: http://blog.zawodny.com/

Итак, ваш проект, вероятно, не слишком велик для MySQL. Возможно, он слишком велик для некоторых из тех способов, которыми вы пользовались ранее в MySQL, и вам может потребоваться адаптировать их.

Answer 2

Если вы ищете пару примеров:

• Facebook перешел на Cassandra только после того, как на нем было сохранено более 7 терабайт входных данных. (Источник: Лакшман, Малик: Кассандра - Децентрализованная структурированная система хранения .) (... Даже при том, что у них было довольно много проблем на этом этапе.)

• Википедия также обрабатывает сотни гигабайт текстовых данных в MySQL.

Answer 3

Google использует MySQL. Ваш проект больше, чем Google?

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

Answer 4

В основном это размер таблицы.

Я предполагаю, что здесь вы будете использовать плагин Oracle innoDB для mysql в качестве движка. Если вы этого не сделаете, это, вероятно, означает, что вы используете коммерческий движок, такой как infiniDB, InfoBright для Tokutek, и в этом случае ваши вопросы следует направлять им.

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

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

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

Если индексы вашей таблицы не все (или, по крайней мере, БОЛЬШИНСТВО - если у вас есть несколько индексов, которые в 99,99% случаев имеют значение ПУСТО (NULL), которые вы можете обойтись без них) вписываются в оперативную память, скорость вставки будет плохой.

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

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

Infobright и Infinidb используют ядро ​​на основе mysql и являются движками на основе столбцов, которые могут обрабатывать очень большие таблицы.

Токутек тоже довольно интересен - вы можете связаться с ними для оценки.

Когда вы оцениваете пригодность двигателя, убедитесь, что загружаете его очень большими данными о серийном оборудовании. Нет смысла тестировать его с (например) базой данных 10G, это ничего не доказывает.

Answer 5

Вещи, на которые вы должны смотреть, это не только размер операций. Критическими являются также:

• Сценарии для резервного копирования и восстановления?
• обслуживание. Пример: SQL Server Enterprise может перестроить индекс, пока старый доступен - прозрачно. Это означает отсутствие простоев при перестроении индекса.
• Доступность (в основном, вам не нужно восстанавливать базу данных объемом 5000 ГБ, если сервер умирает) - предпочтение отдается зеркальному копированию, репликация «отстой» (технически).

К чему бы вы ни стремились, будьте осторожны с Oracle RAC (их кластером) - это, как известно, «проблематично» (если говорить точнее). Известно, что SQL Server намного дешевле, масштабируется намного хуже (без опции «RAC»), но в основном работает без того, чтобы администраторы хотели совершать самоубийство каждый час (опция «RAC», кажется, делает это). Масштабируемость "намного хуже" все еще достаточно хороша для сервера Terra (http://msdn.microsoft.com/en-us/library/aa226316(SQL.70).aspx)

Недавно у нас возникли вопросы о людях, у которых возникают проблемы с перестройкой индексов в базе данных объемом 10 Гб или чем-то подобным.

Так много для моих 2 центов. Я уверен, что некоторые специалисты по MySQL будут сталкиваться с проблемами там.

Answer 6

MySQL - это коммерческая СУБД, у вас просто есть опция , чтобы получить поддержку / мониторинг, предлагаемый Oracle или Microsoft. Или вы можете использовать поддержку сообщества или предоставленное сообществом программное обеспечение для мониторинга.