...продолжение оффтопика, начатого в обсуждении Postgres в роли национальной СУБД.

MBGiv_an_ruИз "чужого, но виртуозного" могу посоветовать services.data.gov/sparql как "правительственный" пример, kegg.bio2rdf.org/sparql и chebi.bio2rdf.org/sparql для биологов, linkedgeodata.org/sparql с геоданными, а ещё проще гуглить по словам из "умолчательной" страницы .../sparql .О, вот spatial data очень интересны! Только как с геоданными работать? Скажем, поиск ближайших в заданных окрестностях, притом если данные в разных системах координат?..С геоданными долгое время был "застой", по нескольким причинам. Во-первых, разные крупные активные пользователи требовали совершенно разную функциональность, но при этом одновременно просили обеспечить им совместимость друг с другом. Во-вторых, многим крупным поставщикам была нужна бОльшая, чем доступная ранее, масштабируемость. В третьих, объединение в одном запросе пространственной и семантической фильтрации --- большая исследовательская задача на стыке семантических и классических реляционных технологий, там есть малозаметные "снаружи", но все равно очень серьёзные проблемы построения плана исполнения.
Сейчас я буду писать для Virtuoso что-то вроде постгресовой гисовской функциональности, но с заделами 1) на поддержку всех типов ESRI в будущем, 2) на поддержку 12-квадратных координат и 3) на opengl-friendly поиск с сортировкой по полю зрения.

Для обмена, так уж повелось, используется только вэгээс.

В доступных версиях Virtuoso есть только точки и bounding box-ы :| Ну и двухкоординатный индекс для этих боксов.

MBGРасскажите, что у вас (и в SPARQL в общем) с поддержкой полнотекстового поиска?Виртуозовский Free Text Search :) Сейчас добавится индекс для regex.

> В идеале - выкладывать для тестового железа результат стандартных тестов (архиватор, кодирование видео/звука, скорость работу эскулайт и т.п.). Тогда можно тест запустить на любом оборудовании/ОС и учесть поправочный коэффициент по стандартным тестам.

Поправочных коэффициентов не бывает. Есть только два действительно надёжных способа выжать максимум. Можно после "авторского" прогона бенчмарки отправить результат разработчику, и если ему интересно, то дать логин и пусть настраивает подопытную машину сам. Либо "наоборот" --- пусть разработчик делает всё сам на своей машине, сообщает результат, и на какой-то срок оставляет машину доступной для желающих, а автор бенчмарки перед публикацией результата делает аудит.

MBGiv_an_ruВо-первых, разные крупные активные пользователи требовали совершенно разную функциональность, но при этом одновременно просили обеспечить им совместимость друг с другом. Во-вторых, многим крупным поставщикам была нужна бОльшая, чем доступная ранее, масштабируемость. В третьих, объединение в одном запросе пространственной и семантической фильтрации --- большая исследовательская задача на стыке семантических и классических реляционных технологий1) А спецификация опенгис консорциума чем не устраивает? Ее все равно надо делать.
2) И впридачу поддержка распределенных данных, т.к. геоданные имеют такие объемы, что на одном сервере хранить и обрабатывать нереально (технически возможно метаинформацию хранить отдельно, но практически очень неудобно и приводит к ошибкам).
3) Так вот оно и интересно.1) Меня всем устраивает, но речь-то про пользователей.
2) Это-то понятно. Там изначально векторное распараллеливание и поддержка кластера.
3) Тут мало быть интересным, надо ещё и обеспечить устойчивость всех компонент. Что такое выставить endpoint голым тухесом в Сеть? Это значит, что малолетние кулхакеры будут бомбардировать его мусорными запросами в надежде подвесить.

MBGiv_an_ruДля обмена, так уж повелось, используется только вэгээс.
Где повелось? :) Опять же, WGS84 бывает в градусах и в метрах... Кстати, если уж у вас везде WGS84, то дистанцию на сфероиде ну просто грешно не реализовать ;)Повелось у публикаторов. В основном градусы, но бывают и просто синтаксические ошибки :) И да, что такое хаверсинус мы знаем, даже "формулу жульнического хаверсинуса на эллипсоиде" знаем :)

MBGiv_an_ruпропущено...
Виртуозовский Free Text Search :) Сейчас добавится индекс для regex.
Вижу чистейший SQL - как это использовать в sparql?так и писать --- FILTER (contains (?document, "pattern" ...)). У нас всё просто: SPARQL можно использовать везде, где синтаксис разрешает SQL-запрос или подзапрос, SQL-ные данные и процедуры доступны из SPARQL, в XSLT тоже можно вставлять хоть SPARQL хоть SQL, равно как и звать XSLT из них и т.п.

MBGiv_an_ruЕсть только два действительно надёжных способа выжать максимум. Можно после "авторского" прогона бенчмарки отправить результат разработчику, и если ему интересно, то дать логин и пусть настраивает подопытную машину сам. Либо "наоборот" --- пусть разработчик делает всё сам на своей машине, сообщает результат, и на какой-то срок оставляет машину доступной для желающих, а автор бенчмарки перед публикацией результата делает аудит.Ничего, хватит знания того, насколько отличается полученный вами результат от оптимального. Например, вы получили, что виртуозо вдвое быстрее эскулайт, а я настроил эскулайт вдесятеро быстрее вашего результата, значит, виртуозо мне и ставить смысла нет :D Все цифры придуманы для иллюстрации, разумеется.Для "домашнего" неофициального прогона проще всего скачать bsbm себе, прогнать, и если разница с ожидаемой скоростью менее чем двукратная, то и не греть голову :) Это не тот случай, когда двукратный разрыв означает покупку 200 серверов вместо 70 :)

MBGiv_an_ruИ да, что такое хаверсинус мы знаем, даже "формулу жульнического хаверсинуса на эллипсоиде" знаем :)Господь с вами, вы где учились? :) Нынче геодезию не знают и профильные специалисты, не говоря уж про ИТ :DМехмат НГУ. Но геодезию знаю в основном потому, что бегал за девочками из НИИГАиКа :)
MBG Жульнический - это про укороченное разложение в ряд?Это мега-лень такая --- в формулу для правильной сферы в зависимости от расположения концов подсовываем разный диаметр Земли --- малую ось, по экватору или нечто среднее :) Для демок хватает, а баллистические ракеты пока никто наводить не пробовал.
MBGiv_an_ruтак и писать --- FILTER (contains (?document, "pattern" ...)). У нас всё просто: SPARQL можно использовать везде, где синтаксис разрешает SQL-запрос или подзапрос, SQL-ные данные и процедуры доступны из SPARQL, в XSLT тоже можно вставлять хоть SPARQL хоть SQL, равно как и звать XSLT из них и т.п.Стандартный Filter в SPARQL - только по точному совпадению/регекспу. А у вас как со стеммингом/морфологией/стопсловами/синонимами?Есть возможность "втыкать" плагинами новые языки, но мало желающих эти самые плагины писать :) Язык "по умолчанию" знает категории символов UNICODE, поэтому умеет отличить слова из букв от разделителей и от тех иероглифов, которые каждый "сам себе однобуквенное слово", и умеет нормализовать эти слова по регистру --- вот этот язык народ в основном и юзает. Зато в языке запросов есть фразы, AND, OR, NEAR, AND NOT, и "слова без окончани*" .
Ещё есть полнотекстовая индексация XML вместе с элементами и атрибутами и акселерация XPath таким полнотекстовым индексом.
Ещё есть "подсветка аннотированных фраз". Скажем, если есть словарь всех заголовков страниц Википедии с соответствующими ссылками, то можно для данного (длинного) текста очень быстро найти все вхождения всех фраз из этого словаря. или из нескольких таких словарей. Можно, скажем, сделать прокси-сервер, распознающий проходящие через него документы и вставляющий дополнительные ссылки, скажем, рекламу или списки полезного чтива по темам :)

MBGiv_an_ruЯзык "по умолчанию" знает категории символов UNICODE, поэтому умеет отличить слова из букв от разделителей и от тех иероглифов, которые каждый "сам себе однобуквенное слово", и умеет нормализовать эти слова по регистру --- вот этот язык народ в основном и юзает.
Это вообще-то токенайзер (с библиотекой ICU, вероятно).Самописка, с возможностью подгружать декларации всяких экзотических кодировок в фoрмате UCM.
MBGкак разбор xml делаете - зовете внешнюю либу или вручную? И в каком виде plaintext получаете (интересует в плане запросов с NEAR)? И ускорение запросов XPath - каким образом?Есть свой валидирующий парсер XML (он же "выпрямляющий" парсер "кривого" HTML). Поскольку слова в полнотекстовом индексе хранятся с позициями, а элементы, атрибуты и слова в значениях атрибутов тоже хранятся как "слова", и тоже с позициями, для XPATH выражения можно построить "фильтрующий" полнотекстовый запрос, и поиск в таблице всех XML-документов, содержащих фрагменты указанного вида, начнётся с полнотекста. Далее, полнотекстовый поиск вернёт не только id документов-"кандидатов", но и позиции "интересных" слов, элементов и т.п., а в каждой вершине XML-ного дерева хранятся диапазоны позиций "слов", в этом дереве. Стало быть, "неподходящие" поддеревья можно очень быстро пропускать, не залезая вглубь.
MBGiv_an_ruЕщё есть "подсветка аннотированных фраз". Скажем, если есть словарь всех заголовков страниц Википедии с соответствующими ссылками, то можно для данного (длинного) текста очень быстро найти все вхождения всех фраз из этого словаря. или из нескольких таких словарей. Можно, скажем, сделать прокси-сервер, распознающий проходящие через него документы и вставляющий дополнительные ссылки, скажем, рекламу или списки полезного чтива по темам :)Заинтриговали - как это сделать "очень быстро"? :) Со вхождениями слов алгоритмически понятно, но с фразами...Считаем контрольные суммы всех фраз текста, "просеиваем" через две битмаски, каждая из которых отвечает либо 0 ("нет, это точно не аннотированная фраза") либо 1 ("это аннотированная фраза или случайно модули сумм совпали"). Если две единички, что редко, то лезем в индекс.

MBGiv_an_ruСчитаем контрольные суммы всех фраз текста, "просеиваем" через две битмаски, каждая из которых отвечает либо 0 ("нет, это точно не аннотированная фраза") либо 1 ("это аннотированная фраза или случайно модули сумм совпали"). Если две единички, что редко, то лезем в индекс.Не понял - если в тексте N токенов, то имеем N вариантов первой фразы (содержит от 1 до N токенов)Максимальная длина фразы в словаре алгоритму известна заранее ;) Так что имеем не N вариантов первой фразы (буква N --- большая), а m вариантов (буква m --- маленькая).

MBG,

Он "потоковый", разумеется, никто список всех токенов в память не запихивает :)

iv_an_ru,

Побайтово сравнивать кусок текста и фразу нельзя --- нормализация же, оосбенно если в языке указани игнорировать какие-нибудь умляуты да тильды.

MBG,

Вы взяли пример в синтаксисе N3, а грузите его как TTL (небольшое но популярное подмножество N3).
Если нужен TTL, то

MBGСконвертировал лог веб-сервера в нижеуказанный формат:
...
То есть 160 Мб нужно для хранения 8 Мб исходных данных (!), полторы минуты заняла их загрузка и 14 секунд - выборка. Для сравнения, обычный grep в 300 раз быстрее и без предварительной подготовки данных:
...
Боюсь и подумать, что получится, если попытаться выполнить более практичный запрос на реальных данных.Ну так это проблемы не технологии как таковой, а конкретного программного продукта.