Представление сжатого графика?

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

Мой вопрос: есть ли способ без потерь сжать слишком большой граф, чтобы он поместился в память, чтобы он соответствовал памяти? Если нет, есть ли хороший алгоритм потери, который для некоторого определения "структуры" не теряет слишком много структуры из исходного графика?

ОТВЕТЫ

Ответ 1

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

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

Их код (для Java, Python и С++) доступен на их веб-странице в качестве рамки сжатия графа, поэтому вы должны быть в состоянии экспериментировать с ним без большой кодировки.

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

Ответ 2

Недавно я был частью статьи о сжатии веб-графов, чтобы они поместились в памяти. Мы получили его примерно до 6 бит на ссылку.

Ответ 3

В общем, если у вас есть N узлов и среднее число X исходящих ссылок на node, X намного меньше N, вам понадобится XN ln N бит информации, чтобы представить это, если вы не можете найти шаблонов в структуре ссылок (которые затем можно использовать для снижения энтропии). XN ln N находится в порядке величины от сложности вашего 32-битного списка смежности.

Есть несколько трюков, которые вы могли бы сделать, чтобы уменьшить размер:

  • Используйте коды huffman для кодирования назначений ссылок. Назначьте более короткие коды часто ссылающимся страницам и более длинным кодам на нечастые страницы.
  • Найдите способ разбить набор страниц на классы. Храните каждую ссылку между страницами в пределах того же класса, что и "0" + "# внутри класса"; ссылки между страницами в разных категориях как "1" + "целевой класс" + "# внутри класса".

Ссылки от Giuseppe заслуживают проверки, но только эксперимент расскажет вам, насколько эти алгоритмы применимы к Википедии.

Ответ 4

Как просто писать ваши узлы, ссылки и ассоциации в существующую масштабируемую систему баз данных (MySQL, SQL Server, Oracle и т.д.)? При необходимости вы можете создавать индексы и хранимые процедуры для более быстрой обработки уровня DB.

Если вы не можете поехать по этому маршруту по какой-либо причине, вам нужно будет вставлять и вводить данные страницы (как это делают системы БД!). Сжатие данных - это кратковременное полосовое пособие во многих случаях. Если вы по какой-то причине не можете поднять крышу RAM, вы покупаете только ограниченное время, поэтому я бы рекомендовал не сжимать ее.

Ответ 5

Если вам не нужна изменчивость, посмотрите, как BGL представляет график в сжатом разреженном формате строки. Согласно документам он "минимизирует использование памяти для O (n + m), где n и m - количество вершин и ребер соответственно". В библиотеке Boost Graph даже есть пример, который отражает ваш прецедент.

Прежде чем вы перейдете к этому вопросу, вам действительно нужно выяснить, как вы собираетесь допрашивать свой график. Вам нужны ссылки, указывающие на страницу, а также ссылки на странице? Нужно ли вам эффективно находить количество ссылок на данной странице? Для довольно хорошо продуманного списка основных операций с графиком взгляните на концепцию Boost Graph Library (BGL). Затем вы можете сопоставить это с требованиями к различным алгоритмам. Самый короткий путь Dijkstra, например, требуется граф, который моделирует "График списка вершин" и "Диаграмма инцидентов".

Ответ 6

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

Предположим, что у вас есть 2 30 (миллиард) страниц, и у всех есть ровно 2 4 исходящие ссылки и что ссылки действительно распределены случайным образом. Ссылки на каждой странице представляют собой почти 16 * 30 бит информации (не полностью, потому что 16 ссылок различны, и это добавляет незначительную избыточность). Таким образом, у вас есть 2 30 * 16 * 30 = 2 32 * 120 = 15 ГБ информации, и теория информации говорит, что вы не можете найти меньшее ОБЩЕЕ представление. Вы должны использовать определенную структуру графа Википедии, чтобы получить ниже нижеследующую теоретическую информацию.