Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Помогите определиться с выбором СУБД.  [new]
vb-expert
Member

Откуда:
Сообщений: 5
Привет всем!

Ситуация:
У меня работает MySQL.
Структура таблицы:
---------------------------------------------------------------------
DROP TABLE IF EXISTS `pd_pt_documents`.`_index_a`;
CREATE TABLE `pd_pt_documents`.`_index_a` (
`doc_id` int(10) unsigned NOT NULL,
`hash` int(10) NOT NULL DEFAULT '0',
`fp_offset` int(10) unsigned NOT NULL,
KEY `hash_idx` (`hash`) USING BTREE
) ENGINE=MyISAM DEFAULT CHARSET=utf8 PACK_KEYS=0 ROW_FORMAT=FIXED;
---------------------------------------------------------------------
итого - 3 поля.
Кол-во записей - 200.000.000

Всё что мне нужно это высокоскоростной поиск:

SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash = 0000123
OR hash = 0000123
OR hash = 0000124
OR hash = 0000125
[...]
OR hash = 000999

Особенность:
В секунду на БД посылаеться 10 таких запросов.

Т.е. база просто засыпается сотнями тысяч запросов.

Вопрос: какая СУБД лучше всего справиться с такой задачей?
--
Заранее всем спасибо!
8 май 09, 16:07    [7163076]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Саабразим Аль-каши Бухани
Member

Откуда:
Сообщений: 325
Может быть, лучше подправить запросы?
8 май 09, 16:14    [7163110]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
перепишите запрос либо через UNION ALL, либо через IN.

искомые значения hash действительно всегда идут подряд или это только пример?
8 май 09, 16:15    [7163116]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
vb-expert
Member

Откуда:
Сообщений: 5
2 miksoft:

У меня немного опыта с SQL -
уточните пожалуйста как именно и зачем "UNION ALL, либо через IN."?

Это повысит быстродействие?
8 май 09, 17:22    [7163442]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
vb-expert
Member

Откуда:
Сообщений: 5
2 Саабразим Аль-каши Бухани:

Скажу спасибо за пинок в нужном направлениии!
Что именно оптимизировать?
8 май 09, 17:24    [7163454]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
vb-expert
2 miksoft:

У меня немного опыта с SQL -
уточните пожалуйста как именно и зачем "UNION ALL, либо через IN."?

Это повысит быстродействие?
Скорее всего - да. Чтобы сказать точно, нужно видеть план текущего запроса и план переписанного запроса.
8 май 09, 17:28    [7163476]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Саабразим Аль-каши Бухани
Member

Откуда:
Сообщений: 325
vb-expert
2 Саабразим Аль-каши Бухани:

Скажу спасибо за пинок в нужном направлениии!
Что именно оптимизировать?


Больше чем miksoft не скажу по имеющемуся куску. Мне вообще не очень ясно как могла возникнуть ситуация с таким количеством "..OR..". Опишите проблему более развернуто, а если это сделаете на форуме MySQL то шанс решить проблему будет еще выше.
8 май 09, 17:49    [7163556]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Yo.!
Guest
имхо быстрее чем MyIsam только база с Index Organized Table может получится (на таком запросе).
8 май 09, 18:10    [7163603]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
vb-expert
Member

Откуда:
Сообщений: 5
2 Yo.!:

Спасибо за идею с IOT! Я немного рогуглил - IOT. Это только Oracle?
9 май 09, 00:37    [7164343]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
vb-expert
Member

Откуда:
Сообщений: 5
2 miksoft:

Замечания - хеши идут НЕ подряд (я подправил примеры)

Структура запроса (старого) была такая:
-----------------------------------------
SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash = 204777
OR hash = -66780123
OR hash = 067831124
OR hash = -345125
[...много других хешей - размер кол-ва хешей регулирую переменной...]
OR hash = 000999
-----------------------------------------

Я почитал про IN и согласно Вашему совету переделал так:
-----------------------------------------
SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash IN (234777,
-36780123,
067831124,
-345125,
[...много других хешей - размер кол-ва хешей регулирую переменной...]
000999)
-----------------------------------------

Быстродействие заметно увеличилось!

Статистика:

В БД - 52.000.000 записей.
Поиск (т.е. вышеописаный SELECT с IN вместо OR) 10000 хешей (размазаны по всем 52 миллионам - т.е.
почти всегда) худший вариант составляет 15-30 секунд.

Насколько я понимаю логику работы БД, наиболее оптимальным вариантом будет
именно максимально большего кол-ва хешей при SELECT-е
чтобы "проход по диску" был только один.

Я обязательно протестирую всё вышеописанное на Orace Index-Organized Tables.

Я стремлюсь к идеалу :-) но

Как ещё можно ускорить процесс?
9 май 09, 00:54    [7164390]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
vb-expert
Статистика:

В БД - 52.000.000 записей.
Поиск (т.е. вышеописаный SELECT с IN вместо OR) 10000 хешей (размазаны по всем 52 миллионам - т.е.
почти всегда) худший вариант составляет 15-30 секунд.

Насколько я понимаю логику работы БД, наиболее оптимальным вариантом будет
именно максимально большего кол-ва хешей при SELECT-е
чтобы "проход по диску" был только один.

Я обязательно протестирую всё вышеописанное на Orace Index-Organized Tables.

Я стремлюсь к идеалу :-) но

Как ещё можно ускорить процесс?
Требуется только чтение из этой таблицы? Тогда есть смысл попробовать в MySQL тип таблиц MEMORY.

10000 из 52.000.000 записей - это, скорее всего, не "проход по диску", а 10 тысяч INDEX RANGE SCAN-ов. Планы, чтобы можно было точно судить об этом, вы так и не показали.

Orace Index-Organized Tables требует наличия первичного ключа. И, имхо, вряд ли будет быстрее, чем чтение из покрывающего индекса в той же MySQL.
9 май 09, 10:13    [7164620]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Yo.!
Guest
vb-expert
2 Yo.!:

Спасибо за идею с IOT! Я немного рогуглил - IOT. Это только Oracle?


в мсскл это IOT кластерной таблицой завется. наверника в дб2 есть. я бы в первую очередь oracle XE попробывал 200М с тремя полями думаю в 4гб влезет легко.
большой SQL с тучей IN долго парсится, во всяком случае я такое замечал в оракле. думаю тут оптимальней создать массив на клиенте и его передать в SQL как переменную. на паре сотен IN я видел значительный прирост скорости, на тысячах быстрей получалось скинуть во временную таблицу, т.к. частенько съезжал план сложного запроса.

2miksoft
а что такое "покрывающего индекса" ?

ЗЫ. у первой тройки еще одно огромное преимущество - scattered read
13 май 09, 01:16    [7172481]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
база хэшей MD5 для подбора паролей?
13 май 09, 01:46    [7172507]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Yo.!
2miksoft
а что такое "покрывающего индекса" ?
Индекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе.
13 май 09, 11:19    [7173536]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8521
vb-expert
Особенность:
В секунду на БД посылаеться 10 таких запросов.

Т.е. база просто засыпается сотнями тысяч запросов.

Вопрос: какая СУБД лучше всего справиться с такой задачей?

Посмотрите Oracle11g. Там есть весьма полезные в данной ситуации:
1. Query Result Cache
2. Client-Side Query Cache
13 май 09, 15:06    [7175435]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Yo.!
Guest
miksoft
Индекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе.


как-то не догнал, а как он поможет достать что-либо по конкретному хешу ?
13 май 09, 19:39    [7176641]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Yo.!
miksoft
Индекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе.
как-то не догнал, а как он поможет достать что-либо по конкретному хешу ?
Делаем индекс (`hash`,`doc_id`,`fp_offset`) и из него достаем.
13 май 09, 19:58    [7176689]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
vb-expert,

1) Поставьте несколько машин. Настройте репликацию. Все изменения посылкайте на master, а эту тучу запросов на select - можно размазать но всем машинам.

2) Можно попробовать распилить таблицу с помощью partitioning на 20-30 кусков, чтобы быстрее доступ был. Не уверен что поможет, но поиграться и замерить можно.
13 май 09, 23:16    [7177076]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
3)Можете попробовать load index into cache `_index_a`
чтобы закинуть индекс полностью в кэш. Конечно, нужно выделить достаточно места для key_buffer_size
13 май 09, 23:39    [7177135]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
4) Вместо запроса с тучей чисел в in (), может быть выгоднее использовать низкоуровневый handler и каждое число отдельно.. документация - надо пробовать.
13 май 09, 23:45    [7177145]     Ответить | Цитировать Сообщить модератору
 Re: Помогите определиться с выбором СУБД.  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Yo.!,

от неумения делать IOT складывают все в один индекс. оверхед заметный. к счастью SQL Server 2005/2008 научились в индекс складывать не только сами индексируемые поля, но и те, которые раньше в индекс приходилось запихивать.

например, для курсов валют покрывающий индекс
CREATE INDEX IX1 on rates (from_curr, to_curr, rate)

в новом варианте 2005/2008
CREATE INDEX IX1 on rates (from_curr, to_curr) INCLUDE (rate)
в 2008 можно еще и фильтр повесить на индекс.

ну это все off.
15 май 09, 01:16    [7182467]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить