Коллеги, Добрый день/вечер/утро!

Предположим, что мы взяли очень популярную социальную сеть, закачали к себе.
Задача: мы хотим сделать поиск по любому слову, которое может присутствовать в профиле странички средствами oracle database, имея сервак с количеством процессоров = 100.
Мы точно знаем, что у любого профиля есть Имя (ник), фамилия, день и месяц рожедния. Иногда даже год
Предположим (1) , что у нас получилось 200 млн. уникальных сочетаний ФИО+ДР.

1. Сделаем таблицу PROFILE_ID | FAM | IM | OT | BIRTH_DATE

Собственно дальше включается полет фантазии. Как сделать так, чтобы поиск по любому сочетанию любых слов выполнялся менее 1 секунды (понятно, совсем гугл не получиться, но объем индексированных данных значительно меньше, впрочем как и количество серверов = 1)


Предположим (2), что у одного профиля может быть не более 30 различных параметров (пол, вес, рост, адрес 1 , адрес 2, количество фото, количество альбомов, любимые цитаты, любимые книги и т.д.)

2. Принимаем решение сделать следующий вариант:
а. Создается таблица PROFILE_ID | TAGVALUE и наполняется значениями (получилось 200 млн * 30 вариантов) = 6 млрд строк
б. Создаем 50 партиций по RANGE (PROFILE_ID)
в. Для каждой партиции создаем субпартиции по HASH (TAGVALUE)
г. Делаем LOCAL INDEX .... TAGVALUE PARALLEL 100
д. select /*+parallel(100) */ * from ... where tagvalue='XX' and PROFILE_ID in ( select .... where tagvalue='YY' and profile id in ( select .... where PROFILE_ID in... ))

Как результат: время работы 6-7 секунд. И в основном тратиться на JOIN самой таблицы с собою же по PROFILE_ID.

3. Вариант с ctxsys.context - позволяет делать только лишь партиционирование по PROFILE_ID, и работает на таком объеме дольше, чем хотелось.. (5 сек - 3 минуты)


Может быть, задачу как-то можно решить иначе?

askkas, Заранее прошу прощения за тся и ться

orawish, бюджет располагает хоть построение bigdata. Я думаю правильным образом секционированная / индексированная таблица даст мне нужный результат. Объем данных 6 млрд строк - это потолок, который будет загружен в таблицу. Пользователей не много, а желание выжать максимум скорости из минимума характеристик - не угасает. 6-7 секунд добился - это уже победа. Кто бы мог подумать, что такая скорость на данных характеристиках на данной задаче это реальность?

orawish, на Ваш взгляд какая технология была бы эффективнее? В организации oracle имеется, время ограничено. Закупка нового софта и серверов - это время.

dbms_photoshop, мысль про in memory интересная, однако при постоянно увеличивающимся количестве атрибутов (сейчас до 20, а потом может быть и до 40), оперативной памяти будет не хватать. На стойке же физической памяти предостаточно. Если отбросить опцию inmemopry, то проблема с pivot table будет следующего характера:
FAM | IM | OT
ИВАНОВ ИВАН ИВАНОВИЧ
ПЕТРОВ ПЕТР ПЕТРОВИЧ


Пользователь в строку поиска ввел ИВАН ИВАНОВ ИВАНОВИЧ.
соотетственно имея 3 параметра, запрос преобразуется в нечто сложное
...where (fam='ИВАН' or im ='ИВАН' or ot='ИВАН' ) and (FAM='ИВАНОВ' or IM ='ИВАНОВ' or OT='ИВАНОВ') and (FAM='ИВАНОВИЧ'....)....

таким образом вариант с использованием многоколоночной таблицы создает сложности. А если аргументов еще больше, то запрос получится просто зверским.

Вернемся к варианту profile_id,tag,tagname,tagvalue

Насчет list по TAGVALUE видимо в ответе имелось ввиду TAGNAME ... Есть у меня такой столбец. Раз пользователь не указывает при поиске то, по чему он ищет (фамилия, имя, отчество и другие названия тегов), то количество используемых parallel соответственно будет равно 20 (число различных параметров)., из этого вытекает, что 80 процессоров будут относительно простаивать. RANGE (PROFILE_ID) позволяет мне разделить 200 млн профилей пользователя по 2 млн на каждый процессор.
Можете раскрыть Вашу идею, может я что-то не так прочитал, и в Вашей мысли действительно есть профит?
Коллеги, кто еще может что посоветовать? Любые варианты рассмотрю :)

Alex__kK, тестировал. Для того, чтобы все теги внести использую clob (ввиду длинного значения совокупности тегов). К сожалению, очень долгий update при добавлении нового тега. Я сейчас протестирую еще раз эту фичу, может что и получится хорошего.

askkas, вспомнил проблему - в решении tagname-tagvalue я могу тэги разбивать по типам. Чтобы была возможность указать, что этот поиск-только по тэгам с типом FAM, другой поиск - по тэгам ADDRESS... Свалив все в кучу для индексирования oracle text, я потеряю эту возможность. Если индексировать не кладя все в 1 колонку, строить индекс по набору столбцов - при моих количествах построение контекстных индексов грузит процы на 100 и не успевает завершиться даже за несколько часов. Дальше ждать нет смысла, да еще и при добавлении нового тега-столбца в такую реализацию будет трудозатратно все снова переиндексировать.

Коллеги, проблема так и не решена. Есть еще дельные советы?