ДохтаРUkraineИ еще один неприятный вечерний сюрприз, версия индекса либрусека оказалась currupted из-за какойто ошибки в движке.
Теперь по коду прийдется расставлять ошибки. Эмпирично искать глюк. :(


А помнишь мы с тобой говорили про 1 случай непопадания куда то там на мильйон ключей ?
Про сложение и умножение вероятностей.

Таки ИМХО ты в него вступил

Проверь на досуге :)

"Это С++ детка"(с)
Тут может быть все что угодно.

Пока вся надежда на Тайгу.
Щас барин разберется с иерархиями

iv_an_ruMX-9,

Всё красиво, вот только нужда в отдельных БДшных фенечках именно для иерархий, она плавно сходит на нет. star joins потихоньку становятся более и более приемлемыми по масштабируемости. Свежачок: 150 Billion Triple dataset hosted on the LOD2 Knowledge Store Cluster.

Возьмем библиотеку либрусек, и попробуем ее представить в виде RDF.
Triple будет таким Документ->Содержит->Слово.
Слов в либрусеке 20 млрд, значит фактов будет 20 млрд.
Каждое слово примерно 8 байт + 1 байт на дефенишин + 2 байта на документ. Минимально уже получается 11 байт.
11 * 20 = 220 гигабайт. С оверхедом в твоем хранилище 500 гигабайт.
Только вот фокус покус. Это хранилище хранит "воду", после компрессии моими алгоритмами
весь либрусек помещается в 1.5 гига . И содержит теже 20 млрд фактов о том в каком документе какое слово находится.

Вывод - научитесь там в своих РДФах по взрослому жать дынные ;)

iv_an_ruUkraine,

Что за бред? Вы ещё предложите картинки хранить в виде отдельных фактов для каждого пикселя.

Если вести поиск картинки по наличию определенного пикселя то прийдется.
Я это к тому веду что РДФ как никрути имеет огромнейший оверхед.
"150 млрд фактов" это вообще ниочем. После сжатия там вполне может быть 3-5 гиг полезной структурированой информации для наносекундного поиска :))

Ну и 8 серверов тудаже ....

iv_an_ruUkraine"150 млрд фактов" это вообще ниочем. После сжатия там вполне может быть 3-5 гиг полезной структурированой информации для наносекундного поиска :))Вы будете не первым, решившим, что показать приличное время на BSBM --- раз плюнуть :) На самом деле, если вы сможете просрать меньше, чем в 100--140 раз, это уже будет неплохой рекламой вашему продукту.

Да, я уже понял стратегию РДФ. С плевой базы раздуть петабайты, а потом рисовать бенчи на спарке что мы одолели этот запрос всега навсего за какихто там 11 тыс секунд

iv_an_ru,

Так что, либрусек можно представить в качестве направленного графа с миллиардами графов или нет ?

maytonUkraineпропущено...


Если вести поиск картинки по наличию определенного пикселя то прийдется.
Я это к тому веду что РДФ как никрути имеет огромнейший оверхед.
"150 млрд фактов" это вообще ниочем. После сжатия там вполне может быть 3-5 гиг полезной структурированой информации для наносекундного поиска :))
Такой поиск никому не нужен. Технологии будущего в хранении графики
это математические способы сжатия графики на основе Wavelet transform (j2k, LuraWave).
Коэффициенты выбирает сам пользователь от 2 до 100 (в принципе так же как и при сохранении
картинок Jpeg). Интересно что формат организован так что частичная потеря файла
(недозагрузка с веба) или повреждение середины практически не оказывают
влияния на картинку. Она только теряет фокусировку. В этом плане такой
способ описания информации близок к природе. К нейросетям и прочим
нечётким (непиксельным) способам описания графики.

А таких задач как "найти какой-то пиксель через индексный поиск" - никто
не ставит. Это бесполезная задача. А вот более полезная - классификация
картинок (лица, или места географии) это задача интересная и имеющая
перспективу. Туда-же быстрое распознавание лиц.

Ты не понял. Я предложил библиотеку книг хранить в хранилище РДФ, да так, чтобы можно было искать полнотекстово.
Ваня возразил, мол это что еще за издевательство над православным РДФ, это всеравно что хранить картинку попиксельно.
На что я ему возразил что зря он возражает, поскольку картинки не нужно искать по пикселям, а вот книжки по словам нужно искать.

iv_an_ruUkraine,
Можно, только в этом нет нужды потому что просрем фтристараз для банального полнотекстового поиска.


фиксед

iv_an_ruОтдельные дуги для слов могут понадобиться только для семантического анализа текста, для которого лопушки-стебельки-цветочки-морковки, очевидно, не годятся никак.

Погоди про дуги дудеть, ты бы сначала показал базу хотябы с простыми связями.
Если дудеть про дуги то там точно петабайты нарисуются.

Вот есть либрусек, 240 тыс книг, 200 гб текста.
РДФ наносит ответный удар, сколько нужно места чтобы хранить и искать по 20 млрд фактов ?

iv_an_ruUkraineкнижки по словам нужно искать.Ну так и ищите. Запихайте текст книжки в литерал, и всё.
Шаг 1: запомнили для каждой книжки факт <IRI_книжки> <content> "текст книжки" .
Шаг 2: указали полнотекстовому индексу, что объекты фактов с предикатом <content> подлежат индексации.
Шаг 3: sparql select ?s where { ?s <content> ?txt . ?txt bif:contains "'моя любимая фраза'" }

ээ кавбой ... это лажа. Если ты собираешся все книжки запихивать в литералы, то получается у тебя 200 гиг литералов, по размеру либрусека. А индекс должен быть 2 гига максимум ... и он содержит информацию о каждом документе и о каждом слове которое там встречается. Это я называю православное хранение данных. А не РДФное.

Ну и запросы должно пулять от сто тыщ в секунду по фразам ...

iv_an_ruUkraineпропущено...


Погоди про дуги дудеть, ты бы сначала показал базу хотябы с простыми связями.
Если дудеть про дуги то там точно петабайты нарисуются.

Вот есть либрусек, 240 тыс книг, 200 гб текста.
РДФ наносит ответный удар, сколько нужно места чтобы хранить и искать по 20 млрд фактов ?Я пока никак не пойму, зачем заниматься сексом в гамаке и на лыжах, бессмыссленно генеря 20 млрд абсолютно тупых фактов там, где их надо 240 тыс?

ты все верно подметил. Представить полнотекстовую базу в РДФной модели, это как заниматся сексом в гамаке и на лыжах. Для таких случаев в чудо виртуозо имеется специальный костыль, называется "полнотекстовый поиск от стороннего производителя для индексации литералов". И тут настает пичалька. Потому что этот костыль не имеет никакого отношения к РДФ а значит запросы нужно будет писать не по спарке а по геометрии костыля.