|
|
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
vb-expert2 Yo.! : Спасибо за идею с IOT! Я немного рогуглил - IOT. Это только Oracle? в мсскл это IOT кластерной таблицой завется. наверника в дб2 есть. я бы в первую очередь oracle XE попробывал 200М с тремя полями думаю в 4гб влезет легко. большой SQL с тучей IN долго парсится, во всяком случае я такое замечал в оракле. думаю тут оптимальней создать массив на клиенте и его передать в SQL как переменную. на паре сотен IN я видел значительный прирост скорости, на тысячах быстрей получалось скинуть во временную таблицу, т.к. частенько съезжал план сложного запроса. 2miksoft а что такое "покрывающего индекса" ? ЗЫ. у первой тройки еще одно огромное преимущество - scattered read ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 01:16 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
база хэшей MD5 для подбора паролей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 01:46 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
Yo.!2miksoft а что такое "покрывающего индекса" ?Индекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 11:19 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
vb-expertОсобенность: В секунду на БД посылаеться 10 таких запросов. Т.е. база просто засыпается сотнями тысяч запросов. Вопрос: какая СУБД лучше всего справиться с такой задачей? Посмотрите Oracle11g. Там есть весьма полезные в данной ситуации: 1. Query Result Cache 2. Client-Side Query Cache ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 15:06 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
miksoftИндекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе. как-то не догнал, а как он поможет достать что-либо по конкретному хешу ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 19:39 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
Yo.!miksoftИндекс, в который входят все используемые в запросе поля. Многие СУБД (в т.ч. и MySQL) умеют в таких случаях читать все данные из индекса, вообще не обращаясь к таблице. Ес-сно, порядок полей в индексе должен быть правильным, чтобы он мог эффективно использоваться в запросе.как-то не догнал, а как он поможет достать что-либо по конкретному хешу ?Делаем индекс (`hash`,`doc_id`,`fp_offset`) и из него достаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 19:58 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
vb-expert, 1) Поставьте несколько машин. Настройте репликацию. Все изменения посылкайте на master, а эту тучу запросов на select - можно размазать но всем машинам. 2) Можно попробовать распилить таблицу с помощью partitioning на 20-30 кусков, чтобы быстрее доступ был. Не уверен что поможет, но поиграться и замерить можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 23:16 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
3)Можете попробовать load index into cache `_index_a` чтобы закинуть индекс полностью в кэш. Конечно, нужно выделить достаточно места для key_buffer_size ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 23:39 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
4) Вместо запроса с тучей чисел в in (), может быть выгоднее использовать низкоуровневый handler и каждое число отдельно.. документация - надо пробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 23:45 |
|
||
|
Помогите определиться с выбором СУБД.
|
|||
|---|---|---|---|
|
#18+
Yo.!, от неумения делать IOT складывают все в один индекс. оверхед заметный. к счастью SQL Server 2005/2008 научились в индекс складывать не только сами индексируемые поля, но и те, которые раньше в индекс приходилось запихивать. например, для курсов валют покрывающий индекс Код: plaintext в новом варианте 2005/2008 Код: plaintext ну это все off. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2009, 01:16 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=35982462&tid=1552941]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 158ms |

| 0 / 0 |
