On 18.03.2014 12:25, chukichuki wrote:
> Кстати, может подскажите что-нибудь почитать по внутренней организации > распределенных RDF хранилищ?
У нас было (оно и сейчас есть) хранилище в виде реляционной БД.
Нормализованной. С columnstore и векторной обработкой данных.
Возник вопрос относительно этой самой > масштабируемости. Кругом пишут про RDF и всякие облачные технологии. Не > могу себе представить как правильно RDF данные разложить на > вычислительном кластере, чтобы обеспечить эту самую масштабируемость.
Ну, просто hash-based partitioning по идентификатору subject-а триплов
по всем серверам кластера.
> Получается, что типовой SPARQL-запрос -- это по сути куча "перевязок" > между тройками.
Да.
Если тройки как-то произвольно-равномерно распределять > между узлами кластера, то интуитивно кажется, что при выполнении запроса > сильно потеряем на пересылки промежуточных результатов этих "перевязок".
Ну... не очень понятно. Смотря какой запрос, наверное.
> Если тройки как-то объединять в связанные подграфы, а подграфы > разместить каждый на отдельном узле, то рискуем не получить равномерного > распределения данных между узлами кластера. Любопытная задача. Как-то > было дело, столкнулся с проблемой обработки больших графов. Была идея > использовать кластер. До практики дело, правда, не дошло. Хочется > посмотреть как данную задачу решают в RDF-хранилищах.
Можешь почитать. Тут описана вся схема данных, с партицированием.
Здравствуйте, MasterZiv, Вы писали:
>> Хм, я не уверен что это хорошая идея, но я очень плохо знаком с OLAP. >> Все-таки масштабируемость RDF пока не дотягивает до реляционных >> хранилищ
MZ>У меня есть опыт работы с хранилищем на 55 миллиардов триплов. MZ>Положительный. Я бы сказал, очень положительный. Если ещё учесть, что MZ>триплов у меня предвидится гораздо меньше ( как минимум на 3 порядка ), MZ>то всё это очень привлекательно выглядит.
Ну тогда хорошо, раз есть. Просто единственный известный мне серьезный SPARQL бенчмарк с такого рода запросами (BSBM Business Intelligence) ворочается весьма медленно уже на 1B на известных мне СУБД (насчет кластерных не знаю). Но, опять-таки, я не знаю какие у тебя запросы и какое железо.
PS. А что за триплстор, или это военная тайна? =)
no fate but what we make
Re[11]: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Здравствуйте, Mystic, Вы писали:
M>>Графы практически полностью лежат вне покрытия реляционными БД. Т. е. оно то, конечно, возможно... Но простой запрос типа: вывести все вершины на расстоянии на более заданного. И как быть? Так что для полноты надо смотреть еще в сторону graph database.
C>Да, тут согласен. Графовые СУБД -- отдельный вопрос. Я их рассматривал, но опять-таки очень поверхностно. На уровне беглого просмотра википедии и всяких разных helloworld-ов и howto. Как я понял, основная их особенность -- это именно разного рода операции поиска по графу в глубину, в ширину, поиск путей из одного узла в другой и т.п. На мой взгляд весьма специфические операции. Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
Здравствуйте, chukichuki, Вы писали:
C>... Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
Здравствуйте, PSV100, Вы писали:
C>>... Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
PSV>ещё одна классика: http://www.neo4j.org
Здравствуйте, PSV100, Вы писали:
PSV>Здравствуйте, chukichuki, Вы писали:
C>>... Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
PSV>Кроме OrientDB, ещё одна классика: http://www.neo4j.org, плюс стек над графбазами: http://www.tinkerpop.com
там цена 12K$ vs 0 у OrientDb причем без всяких преимуществ перед последней, а даже еще и меньше фишек и больше тормозов.
Re[5]: Экзотические модели и языки запросов к базам данных
Здравствуйте, _Claus_, Вы писали:
_C_>Здравствуйте, PSV100, Вы писали:
PSV>>Здравствуйте, chukichuki, Вы писали:
C>>>... Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
PSV>>Кроме OrientDB, ещё одна классика: http://www.neo4j.org, плюс стек над графбазами: http://www.tinkerpop.com
_C_>там цена 12K$ vs 0 у OrientDb причем без всяких преимуществ перед последней, а даже еще и меньше фишек и больше тормозов.
C>Да, тут согласен. Графовые СУБД -- отдельный вопрос. Я их рассматривал, но опять-таки очень поверхностно. На уровне беглого просмотра википедии и всяких разных helloworld-ов и howto. Как я понял, основная их особенность -- это именно разного рода операции поиска по графу в глубину, в ширину, поиск путей из одного узла в другой и т.п. На мой взгляд весьма специфические операции.
Ничего специфического. Физические сети, сойиальные сети, travelling salesman, FSM'ы, и еще миллион задач — это все графы. Примеры некоторых задач можно посмотреть тут: https://github.com/neo4j-contrib/graphgist/wiki
