Здравствуйте, kl, Вы писали:

kl>Хм, я не уверен что это хорошая идея, но я очень плохо знаком с OLAP. Все-таки масштабируемость RDF пока не дотягивает до реляционных хранилищ, плюс там где можно за счет денормализации read-only хранилища добиться быстрых аналитических SQL запросов, обычный SPARQL-сервер (если он как-то хитро не заточен под данный вид запросов) будет делать множество джойнов. Впрочем, может есть и доводы "за", вот, например, известные люди опубликовали схему RDF Data Cube.
kl>Короче говоря, я бы посоветовал сначала получше понять преимущества и недостатки RDF как модели данных для твоего случая, а потом уже подбирать продукт, для которого смотреть лицензии и т.д.

Кстати, может подскажите что-нибудь почитать по внутренней организации распределенных RDF хранилищ? Возник вопрос относительно этой самой масштабируемости. Кругом пишут про RDF и всякие облачные технологии. Не могу себе представить как правильно RDF данные разложить на вычислительном кластере, чтобы обеспечить эту самую масштабируемость.

Получается, что типовой SPARQL-запрос -- это по сути куча "перевязок" между тройками. Если тройки как-то произвольно-равномерно распределять между узлами кластера, то интуитивно кажется, что при выполнении запроса сильно потеряем на пересылки промежуточных результатов этих "перевязок". Если тройки как-то объединять в связанные подграфы, а подграфы разместить каждый на отдельном узле, то рискуем не получить равномерного распределения данных между узлами кластера. Любопытная задача. Как-то было дело, столкнулся с проблемой обработки больших графов. Была идея использовать кластер. До практики дело, правда, не дошло. Хочется посмотреть как данную задачу решают в RDF-хранилищах.