Является ли InnoDB (MySQL 5.5.8) правильным выбором для многомиллиардных строк?

Question

Итак, одна из моих таблиц в MySQL, которая использует механизм хранения InnoDB, будет содержать многомиллиардные строки (потенциально без ограничения на то, сколько будет вставлено).

Можете ли вы сказать, какие оптимизациия могу помочь ускорить процесс?Потому что уже с несколькими миллионами строк оно начнет замедляться.

Конечно, если вы предложите использовать что-то еще.Единственные варианты, которые у меня есть, это PostgreSQL и Sqlite3.Но мне сказали, что sqlite3 не является хорошим выбором для этого.Что касается postgresql, я абсолютно не представляю, как это, так как я никогда не использовал его.

Я думаю, что хотя бы около 1000-1500 вставок в секунду в этой таблице.

Answer 1

Простой ответ на ваш вопрос: да, InnoDB был бы идеальным выбором для многомиллиардного набора данных.

Существует множество вариантов оптимизации, которые возможны.

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

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

В InnoDB есть некоторые дополнительные возможности, такие как защита от повреждения данных, автоматическое восстановление и т. Д.

Что касается повышения производительности записи, вам следует настроить файлы журналов транзакций до 4G.

Еще одна вещь, которую вы можете сделать, это разделить таблицу.

Вы можете добиться большей производительности, установив bin-log-format в «row» и установив auto_inc_lock_mode в 2 (это гарантирует, что innodb не удерживает блокировки на уровне таблицы при вставке в столбцы с автоинкрементом).

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

Answer 2

оптимизаций

• Старайтесь не иметь слишком много индексов.Они дорогие при вставке
• . Сделайте так, чтобы ваши типы данных соответствовали вашим данным, насколько это возможно.(так что не сохраняйте ip-адреса в тексте или блобе, если вы знаете, что я имею в виду).Посмотрите на varchar против char.Не забывайте, что, поскольку varchar более гибок, вы торгуете некоторыми вещами.Если вы много знаете о своих данных, это может помочь в использовании char или, может быть, лучше использовать varchars.и т.д.
• Читаете ли вы вообще из этой таблицы?Если это так, возможно, вы захотите выполнить все чтение с реплицированного ведомого устройства, хотя ваше соединение должно быть достаточно хорошим для такого объема данных.
• Если у вас большие вставки (кроме количества вставок), сделайтеЯ уверен, что ваш ввод-вывод достаточно быстр, чтобы справиться с нагрузкой.
• Не думаю, что есть какая-то причина, по которой MySQL не будет поддерживать это.Вещи, которые могут замедлить вас от «тысяч» до «миллионов» и «миллиардов», похожи на вышеупомянутые индексы.Насколько я знаю, проблема "mysql is full" отсутствует.
• Посмотрите на Частичные индексы. Из википедии (самый быстрый источник, который я смог найти, не проверял ссылки, но я уверен, что вы можете управлять:)

MySQL с версии 5.4 делаетне поддерживает частичные индексы. [3]В MySQL термин «частичный индекс» иногда используется для ссылки на индексы префикса, где в индексе хранится только усеченный префикс каждого значения.Это еще один метод уменьшения размера индекса. [4]

Answer 3

Понятия не имею в части MySQL / InnoDB (я бы предположил, что справится). Но если вы в конечном итоге ищете альтернативы, PostgreSQL может управлять БД неограниченного размера на бумаге. (По крайней мере одна база данных 32 ТБ существует согласно FAQ .)

Можете ли вы сказать мне, какую оптимизацию я могу сделать, чтобы ускорить процесс?

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

В случае с PostgreSQL вы также, возможно, захотите создать частичные индексы.

Answer 4

Возможно, вы захотите взглянуть на:

http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/

http://forums.whirlpool.net.au/archive/954126

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