Можно ли сделать тройные магазины масштабируемыми

Говорят, что большинство троек, о которых я читал, масштабируются примерно до 0,5 миллиарда троек.

Мне интересно знать, считают ли люди, что существует теоретическая причина, по которой они должны иметь верхний предел, и знаете ли вы какие-либо конкретные способы сделать их более масштабируемыми.

I am curious to know if existing triple stores do things like this:

  • Represent URIs with integers
  • Integers in order
  • Search the integers instead of the URIs which I would imagine must be faster (because you can do things like a binary search etc.)

    Мысли ...


  • person Community    schedule 22.07.2010    source источник


    Ответы (1)


    Просто чтобы получить 500 миллионов, тройной магазин должен делать все это и многое другое. Я несколько лет работал над реализацией тройного хранилища и могу вам сказать, что разбить 1 миллиард троек не так просто, как может показаться.

    Проблема в том, что многие rdf-запросы имеют 2-й или 3-й порядок (и более высокие порядки далеко не редкость). Это означает, что вы запрашиваете не только набор сущностей, но одновременно и данные о наборе сущностей; данные о схемах сущностей; данные, описывающие язык схемы, используемый для описания схем сущностей.

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

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

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

    person Community    schedule 23.07.2010
    comment
    Привет, Recurse, я должен признать, что не совсем понимаю, почему предложенный мной метод может быть полезен для 500 миллионов, но тогда будет очень сложно разбить 1 миллиард троек. Как я понимаю, для 500 миллионов требуется 29 поисков, а для 1 миллиарда — 30? Я все неправильно понял? Обратите внимание, что я не ожидаю полного ответа, это, очевидно, нетривиальный вопрос, но если вы знаете какие-либо исследовательские работы и т. Д., Которые касаются этого, и можете указать мне в их направлении, я был бы очень признателен. - person Ankur; 23.07.2010
    comment
    Это потому, что вы думаете о поиске; поиск в значительной степени не имеет отношения к производительности хранилища на пределе масштабируемости. Что убивает вас, так это поиск диска, и это становится критическим, когда вы начинаете регулярно видеть промахи кеша при обходе индекса. Переход с 29-го на 30-й уровень индекса кажется тривиальным, пока вы не подумаете, что это может быть переход с 1-2 или 2-3 поиска. Объедините это с глубокими соединениями, распространенными в запросах RDF, и, хотя это и не является непреодолимым, дальнейшее масштабирование становится далеко не простым. - person Recurse; 28.07.2010