Mysql. Оптимизация выборки

← →
Zeqfreed © (2009-05-28 19:25) [0]

Всем доброго вечера.

Имеется таблица InnoDB, на данный момент в ней 4 миллиона строк. Ожидается до 40-50 миллионов. В таблице около 25 столбцов, в основном дробного типа + несколько временных (datetime).

Используя одновременную вставку нескольких строк удалось добиться приемлемого времени вставки (4 миллиона записей — около 30 минут). Сейчас начались проблемы с выборкой.

Оожидается, что выборка в основном будет осуществляться по интервалу времени (одно из временных полей) с указанием дополнительных ограничений (по значению целочисленного поля tinyint). Сегодня я попробовал добавить индекс по одному из временных полей, и так и не дождался его создания.

Вопрос следующий. Возможно ли добиться адекватного времени выборки в Mysql на таком наборе данных и что для этого следует попробовать предпринять? Имеет ли смысл пробовать Postgres или у него нет каких-либо существенных преимуществ в такой ситуации?

Надеюсь на помощь опытных форумчан, спасибо :)

← →
turbouser © (2009-05-28 19:57) [1]

> Имеет ли смысл пробовать Postgres

имеет

← →
Zeqfreed © (2009-05-28 20:09) [2]

> turbouser © (28.05.09 19:57) [1]

А какие преимущества я от этого смогу получить? Мне так думается, что от одной только смены СУБД мало что поменяется, или я не прав? Если не прав, то опять же хотелось каких-нибудь бы аргументов :)

← →
T&F (2009-05-28 20:11) [3]

> Имеет ли смысл пробовать Postgres

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

← →
Sergey13 © (2009-05-29 08:54) [4]

> [0] Zeqfreed © (28.05.09 19:25)
> 4 миллиона записей — около 30 минут

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

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

← →
palva © (2009-05-29 09:39) [5]

> Почему не дождался?

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

← →
Zeqfreed © (2009-05-29 15:16) [6]

> Sergey13 © (29.05.09 08:54) [4]

Не дождался, т.к. домой пошел :)

> palva © (29.05.09 09:39) [5]

Там были индексы, только то поле, по которому я пробовал выборку, входило в мультиколоночный индекс и по всей видимости он не использовался.

← →
Sergey13 © (2009-05-29 15:59) [7]

> [6] Zeqfreed © (29.05.09 15:16)
> Не дождался, т.к. домой пошел

Это так же действенный способ и при решении проблем с выборкой данных.

← →
Zeqfreed © (2009-05-29 20:12) [8]

> Sergey13 © (29.05.09 15:59) [7]

К сожалению, он действует не всегда. Жаль, что что-то реальное посоветовать никто не может.

← →
Нат © (2009-05-30 01:46) [9]

Что значит "по одному из временных полей"?
Зачем такое важно поле вре"менное? Или в смысле "временно"е", вре"менного типа?
Кстати, не известно, каков запрос.

← →
turbouser © (2009-05-30 02:48) [10]

> Zeqfreed © (29.05.09 20:12) [8]

Почему? а как же [1] ?

← →
Zeqfreed © (2009-05-30 04:56) [11]

> Нат © (30.05.09 01:46) [9]

Я имею в виду поле временного типа. Как его правильно назвать? Datetime в общем.
Запрос примерно такой: select * from table where datetime_column >= timestamp1 and datetime_column <= timestamp2 and tinyint_column in (val1, val2, val3). Но может быть и несколько сложнее. Хотя мне кажется, что если выборка по дате пройдет с использованием индексов, то дальше уже пошустрее в любом случае будет?

> turbouser © (30.05.09 02:48) [10]

Реальность этого совета я еще не успел опробовать. Но вообще да, спасибо :)

← →
Псалтырь © (2009-05-30 10:14) [12]

> T&F (28.05.09 20:11) [3]
>
>
> > Имеет ли смысл пробовать Postgres
>
> Недавно читал, что по производительности она не особо-то
> лучше MySQL, а даже совсем наоборот.

Брэд... Не Пит, который. А который сивой кобылы брэд

← →
turbouser © (2009-05-30 10:33) [13]

> Псалтырь © (30.05.09 10:14) [12]

> Брэд...

Ну так заказных тестов в сети до и больше.
У MySQL своя ниша, из которой они пытаются выползти, с переменным успехом :)
Работал с энтим MySQL... 5.х... тоже миллионы записей... ну его нафик.... не люблю я его... =) или =(

← →
Нат © (2009-05-31 02:28) [14]

select * from table where datetime_column >= timestamp1 and datetime_column <= timestamp2 and tinyint_column in (val1, val2, val3)
Проверьте, как быстро будет выполняться запрос без "in ()".
Если всего три значения...
"=" выполняется быстрее.

> [8] Zeqfreed © (29.05.09 20:12)
> Жаль, что что-то реальное посоветовать никто не может.

А как тебе советовать если ты домой уходишь? 8-)
Нужен индекс - построй его. В чем проблема то?
Кстати, если нужно строить по ДатеТайм+Интежер зачем строить только по ДатеТайм? Строй сразу нужный.

В общем я таки добрался до постгреса сегодня, работает заметно быстрее :)

Мускуль создавал индексы по 15-20 минут, я создал три индекса и в принципе выборка
стала происходить в разумное время. Однако потом проявились проблемы с определением того, какие индексы использовать и как. При ручном указании индекса запрос отрабатывал за секунду примерно, а без указания мускуль путался и выбирал 20 секунд.

Сегодня импортировал базу в постгрес, 46 минут ушло на импорт 4 млн. записей. Затем создал индексы, каждый создавался по 25-30 секунд, что очень заметно по сравнению со временем, которое показывал мускуль. Выборка в среднем в два раза быстрее. На том запросе, на котором мускуль начинал путаться в индексах, постгрес сам разобрался как использовать два индекса и в итоге выборка ускорилась примерно в 9 раз.

Я не большой специалист по мускулю, конечно, но видимо пока я остановлюсь на постгресе, результаты впечатляют и вообще он интересней :)

Всем спасибо за комментарии, извиняюсь что не отвечал.

> Выборка в среднем в два раза быстрее

Составные индексы + хранимые не пробовал?

> результаты впечатляют и вообще он интересней :)

Недобаза и есть недобаза - OLTP огрызок. Но помни о VACUUM %-)

> tesseract © (15.06.09 22:43) [17]

У меня задача оптимизировать по возможности все потенциальные произвольные запросы, поэтому сложно предполагать какие составные индексы могут пригодиться. Хранимые — то же самое, в перспективе необходимо будет работать с произвольными запросами.

Недобаза это кто и почему?

> Недобаза это кто и почему?

мускул. Она только как OLTP и в качестве оптимизированной выдаче не индексированной текстовой информации может быть хоть как-то применена. Поизвольных запросов не бывает - они всё равно попадают в определённые рамки. Ни разу не видел запросов только по одному критерию в сколько нибудь сложной базе. Это уже ведёт к понятию "сервер отчётов".

> tesseract © (16.06.09 00:04) [19]

Ну, по сути отчеты и нужно составлять. Запросы, конечно, не по одному критерию, подумать насчет составных может быть и стоит, но все равно всех случаев не предусмотреть. Насколько они полезны?

Mysql. Оптимизация выборки Найти похожие ветки