|
|
|
100 млн записей + 100 параметров в каждом - поиск по параметрам
|
|||
|---|---|---|---|
|
#18+
Уважаемые, есть такая задача: Есть таблица, в ней 100 млн. записей. К у каждой записи есть примерно 100 параметров, причем каждая запись относится к одному из миллиона документов (ста тысяч, не знаю точно) нужно осуществить поиск всех документов, в которых есть несколько разных записей, причем с определенными значениями параметров. Другими словами: Есть ID документа (их разных - 100 тыс), ID записи (их 100млн), Название записи + 100 параметров. Мне надо найти ID документа, в котором есть Название записи=aaa с определенными параметрами, в котором есть запись с названием bbb с ее параметрами и тд - до 5 записей на документ. На маленьких таблицах это реализуется с помощью join, на большой будет тормозить. Причем выборка будет ограничиваться 1000 документами, хотя запрос может выбирать даже все 100 тыс документов (в каждом из документов может встречаться одна из записей - априори это не известно). Мне кажется, что такая линейная структура БД не подходит под эту задачу - какая должна быть правильная структура под нее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 15:38 |
|
||
|
100 млн записей + 100 параметров в каждом - поиск по параметрам
|
|||
|---|---|---|---|
|
#18+
FireStormНа маленьких таблицах это реализуется с помощью join, на большой будет тормозить. А Вы сначала попробуйте и посмотрите, будет или не будет. Напишите с JOIN, в лоб, как можно проще, без оптимизации, с LIMIT, и прогоните раз 10-15. Может статься, что компиллятор запросов умнее, чем Вы думаете :) . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 15:49 |
|
||
|
100 млн записей + 100 параметров в каждом - поиск по параметрам
|
|||
|---|---|---|---|
|
#18+
Всё у вас будет работать очень быстро, если вы не поленитесь и купите побольше винчестеров, а потом их обьедините в один (не помню какой это raid - 0 или 1) Судя по всему, у вам таблица типа DocId,RecordId,RecordName,P1,P2,...P100 Предлагаю сделать вам 101 индекс(каждый индекс состоит их трёх полей): 1ый иддекс (RecordName,RecordId,DocId) 2ой индекс (P1,RecordId,DocId) 3ий индекс (P2,RecordId,DocId) и т.д. после всего этого ваша БД вырастет в 100 раз по обьёму(а может и больше), зато если вы сделаете запрос select DocId,RecordId from tbl where RecordName = "aaa" and p1 = "xxx" and p34="yyy", то сначала бинарным поиском будут найдены все DocId,RecordId у которых P1 равно xxx, потом все DocId,RecordId у которых p34 = "yyy" ну и все DocId у которых RecordName = "aaa". Поскольку поиск бинарный, то потребуется около 30, а не 100 млн проходов по базе для каждого условия и ваша выборка будет работать очень быстро. Главное, не пишите select *, этим вы просто собьёте с толку и индексы, и sql ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2006, 14:40 |
|
||
|
100 млн записей + 100 параметров в каждом - поиск по параметрам
|
|||
|---|---|---|---|
|
#18+
1. Прежде чем говорить о структуре, думаю, нужно определить, как эта БД будет работать. Варианты: - частое обновление/редкие запросы на выборку - редкое обновление/частые запросы на выборку - частое обновление/частые запросы на выборку. 2. Далее, определив режим работы, нужно иметь информацию об объемах (в записях, например): - изменяемых данных - добавляемых данных - удаляемых данных - выбираемых данных 3. Кроме того, для выборки нужно определить наиболее частые комбинации атрибутов (полей), используемые в запросах. Вот минимум, от которого нужно отталкиваться в подобных задачах. Поправьте, если что-то упустил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2006, 10:48 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=136&tid=1545158]: |
0ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
296ms |
get topic data: |
16ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 202ms |
| total: | 613ms |
| 0 / 0 |
