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

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

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

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

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

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

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

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

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

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

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

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

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