Как стать автором
Обновить

Комментарии 13

Как быть если MySQL сервер на другом физическом сервере?
Если у вас есть доступ к ФС (и к файлам MySQL) на этом сервере, то я не вижу большой проблемы. Если же такого доступа нет, то можете попробовать использовать HANDLER (вместо SELECT) и LOAD DATA LOCAL INFILE (вместо INSERT). Но достичь такой же производительности, как если писать напрямую, не получится
Начало статьи обнадежило меня увидеть хоть какие-то цифры. Ан нет…
Надеюсь, так лучше
Всяко лучше чем ничего. Для себя уже нашел хитрое применение такой схемы, по этому спасибо за наводку. Никогда бы не подумал что у майисам такой оверхэд и такая простая структура. По идее таблицу в несколько террабайт можно создать из бд залить лоадом и использовать подобным образом вместо плоских файлов.
я как-то обнаружил упоминание о том, что в случае, если используется MyISAM, можно получить прирост в скорости чтения из таблицы в 5-7 раз, если читать данные из таблицы самостоятельно

Скажите пожалуйста, а вы сравнивали скорость с HandlerSocket или Handler interface? Думается мне, они быстрее будут, т.к. читают из памяти.
> Думается мне, они быстрее будут, т.к. читают из памяти.
Handler Interface читает из стораджа, который может быть полностью загружен в память, но необязательно.
а вы сравнивали скорость с HandlerSocket?

Хотелось бы увидеть цифры для:
— последовательного чтения — full scan
— произвольного чтения — index search
и сравнить их с прямыми NoSQL аналогами: HandlerSocket и memcached plugin от innoDB.
А то вроде бы начало за здравие, а в финале никаких сравнительных характеристи, может это велосипед…
> 3. Сам по себе FULL SCAN в MyISAM работает в 5-10 раз быстрее, чем скан по индексу с таким же числом записей.

вот это не понятно. Нет ли какой ошибки в том где _поиск записей_ быстрее.

Если ошибки нет, то хотелось бы услышать подробней про методику сравнения: какая операция делалась = что такое «скан» по индексу, как получалось её среднее время?
Допустим, у нас есть таблицы: tbl1 и tbl2
В таблице tbl2 содержится таблица tbl1 + содержится индекс на одном из полей (скажем, на поле field)

Для таблицы tbl1 делается запрос
SELECT * FROM tbl1 WHERE (условие, отсекающее 100% строк)


Для tbl2 делается такой же запрос:
SELECT * FROM tbl2 WHERE (условие, отсекающее 100% строк) ORDER BY field


Количество просмотренных строк будет одинаковое, а вот порядок выполнения — разный. В первом случае это будет обычный FULL SCAN, а во втором случае — скан по индексу (можно дополнительно поставить FORCE INDEX(field) для второго случая, чтобы никаких сомнений не осталось).
Разница по времени исполнения для этих запросов составляет 5-10 раз для обычного (незатюненного) MyISAM, в буфер ключей которого этот индекс помещается, и таблицы полностью помещаются в кеш ФС
Ошибки тут нет. Суть в том что при full scan происходит sequential read, т.е бошка винчестера идет подряд по секторам и не дергается. Индекс в этом примере фактически используется для выполнения сортировки, т.е _поиска_ по индексу не происходит, и происходит чтение всех записей. Поэтому во втором случае sequential read происходит только для индекса, а для чтения самих записей используется random read.
Т.к кластерных индексов в myisam нет, то бошка винчестера скачет туда-сюда, и из-за этого full index scan _в этом_ случае занимет гораздо больше времени. Кроме того, во втором случае больше информации читается с диска чем в первом.

Если бы во втором примере скан индекса использовался для поиска записей, то какая-то часть их была бы отсеена (т.е небыло бы некоторых random reads) и разница времени выполнения была бы другая.
Полное сканирование по индексу всегда медленнее за исключением индексно организованных таблиц, читай любой таблицы иннодб. Там каждая таблица это индекс. Любой индекс отвергается оптимизатором если надо сканировать более 10%.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории