Большие таблицы MySQL

Question

Для разрабатываемого веб-приложения мне необходимо хранить большое количество записей. Каждая запись будет состоять из первичного ключа и одного (короткого) строкового значения. Я ожидаю, что будет доступно около 100 ГБ памяти и хотел бы иметь возможность использовать все это.

Записи будут часто вставляться, удаляться и читать, и я должен использовать базу данных MySQL. Целостность данных не имеет решающего значения, но производительность. С какими проблемами и подводными камнями я могу столкнуться и какой механизм хранения лучше всего подходит для этой задачи?

Большое спасибо, J

Answer 1

Какое бы решение вы ни использовали, поскольку вы говорите, что ваша база данных будет загружена при записи, вам необходимо убедиться, что вся таблица не блокируется при записи. Это исключает MyISAM, что некоторые предложили. MyISAM заблокирует таблицу при обновлении, удалении или вставке. Это означает, что любой клиент, который хочет читать из таблицы, должен будет ждать окончания записи. Не знаю, что делает INSERT LOW PRIORITY, вероятно, некоторые взломали блокировку таблицы: -)

Если вам просто нужно использовать MySQL, вам понадобится InnoDB, который не блокируется при записи. Я не знаю, как MySQL работает с таблицами InnoDB в VACUUM (InnoDB - это MVCC, как PostgreSQL, и поэтому он нуждается в очистке) ... но вам придется принять это во внимание, если вы делаете много обновлений или удалений.

Answer 2

Все зависит от шаблона чтения / записи, который генерирует ваше приложение, и уровня точности, который вы хотите получить. Например, если вам не важно, чтобы все последние вставленные строки были немедленно доступны, рассмотрите возможность использования INSERT LOW PRIORITY, чтобы помочь в SELECT. Если размер текста относительно мал, вы можете использовать фиксированный тип CHAR, который поможет много индексировать и сократить время SELECT Если ваше приложение генерирует много обновлений, вы предпочтете механизм хранения InnoDB, который позволяет блокировать только одну строку при обновлении (против всей таблицы в myISAM). С другой стороны, он более ресурсоемкий, поэтому, если вы не используете транзакции и ваш шаблон обновления относительно мал, рассмотрите возможность использования myISAM

Answer 3

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

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

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

Answer 4

Вам гораздо лучше, если «короткая строка» находится в столбце фиксированной длины, чтобы в таблице были строки фиксированной длины. MySQL с MyISAM будет работать достаточно эффективно для вас. Выделите как можно больше памяти для буфера ключей, чтобы большая часть индекса находилась в памяти. Ваша цель должна состоять в одном произвольном доступе к диску для извлечения одной строки - вы не можете добиться большего успеха, чем при 100 ГБ данных и 8 ГБ памяти. Вы не должны ожидать выполнения более нескольких сотен таких запросов в секунду, потому что это все случайные обращения к диску.

Возможно, вас заинтересует мой пользовательский механизм хранения MySQL (см. Здесь ). Он управляет памятью не так, как MyISAM, хотя профиль вашего приложения не совсем подходит для моего движка.

Answer 5

больших запросов MySQL приводят к сбою моего сервера Quad Core / 8GB Ram DB ...

решение заключается в использовании PostgresSQL (SQL Server, если вы можете себе это позволить)

Answer 6

Вы определенно хотите использовать MyISAM для механизма хранения. Но вы говорите, что ожидаете 100 ГБ, и оно будет содержать только короткое строковое значение. Вы определенно хотите использовать 64-битный тип int для своего идентификатора / первичного ключа.

Но мой настоящий вопрос. Вы используете это для хранения информации о сеансе с веб-сайта? Если да, то вы хотите использовать memcache вместо MySQL.