Будет ли таблица MySQL с 20 000 000 записей быстрой с одновременным доступом?

Question

Я провел проверку поиска по индексированной таблице MySQL, содержащей 20 000 000 записей, и, согласно моим результатам, для извлечения записи с заданным идентификатором требуется 0,004 секунды, даже при объединении с другой таблицей, содержащей 4000 записей. Это было на двухъядерной машине с частотой 3 ГГц, и только один пользователь (я) имел доступ к базе данных. Запись выполнялась также быстро, поскольку для создания этой таблицы за 20 000 000 записей потребовалось менее десяти минут.

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

Полагаю, InnoDB будет лучше?

Answer 1

Это зависит от механизма хранения, который вы собираетесь использовать, и от того, какое соотношение чтение / запись.

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

InnoDB определенно безопаснее, поэтому я все равно буду его придерживаться.

КСТАТИ. помните, что сейчас ОЗУ очень дешево, так что покупайте много.

Answer 2

Зависит от любого количества факторов:

• Серверное оборудование (особенно ОЗУ)
• Конфигурация сервера
• Размер данных
• Количество индексов и размер индекса
• Запоминающее устройство
• Соотношение писатель / читатель

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

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

Answer 3

Нет причин, по которым MySql не мог бы справиться с такой нагрузкой без каких-либо существенных проблем. Однако существует ряд других переменных (в противном случае это вопрос «как долго это кусок строки»). Лично у меня было несколько таблиц в различных базах данных, которые находятся далеко за этим диапазоном.

• Насколько велика каждая запись (в среднем)
• Сколько оперативной памяти имеет сервер базы данных - и сколько выделено для различных конфигураций Mysql / InnoDB.

Конфигурация по умолчанию может разрешать только буфер по умолчанию 8 МБ между диском и клиентом (который может нормально работать для одного пользователя) - но попытка разместить базу данных объемом 6 ГБ + через это обречена на провал. Между прочим, эта проблема была реальной - и она вызывала несколько сбоев в день базы данных / веб-сайта, пока меня не привели для устранения неполадок.

Если вы, вероятно, сделаете намного больше с этой базой данных, я бы порекомендовал привлечь кого-то с немного большим опытом или, по крайней мере, поработать над тем, чтобы вы могли оптимизировать его. Чтение ' High Performance MySQL, 2nd Edition ' - хорошее начало, так как мы рассматриваем некоторые инструменты, такие как Maatkit .

Answer 4

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

Answer 5

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

Одинаковый ответ для обоих двигателей.