Как агрегации баз данных образуют моноид?

На cs.stackexchange я спросил о scala-библиотеке algebird на github, размышляя о том, почему им может понадобиться пакет абстрактной алгебры.

Страница GitHub имеет несколько подсказок:

Реализации Monoids для интересных алгоритмов аппроксимации, таких как фильтр Блума, HyperLogLog и CountMinSketch. Они позволяют вам думать об этих изощренных операциях, как о числах, которые вы можете, и складывать их в hadoop или онлайн для получения мощной статистики и аналитики.

и в другой части страницы GitHub:

Первоначально он был разработан как часть Scalding's Matrix API, где у Matrices были значения, которые являются элементами Monoids, Groups или Rings. Впоследствии стало ясно, что код имеет более широкое применение в Scalding и других проектах в Twitter.

Даже Оскар Бойкин из Твиттера вмешался:

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

Используя моноиды, мы можем воспользоваться разреженностью (мы имеем дело с множеством разреженных матриц, где почти все значения равны нулю в некотором моноиде).

Используя Кольца, мы можем делать умножение матриц на другие вещи, кроме чисел (что мы иногда и делали).

Сам проект algebird (а также история проблем) довольно четко объясняет, что здесь происходит: мы строим множество алгоритмов для агрегации больших наборов данных, а использование структуры операций дает нам выигрыш в системной части. (что обычно является основной проблемой при попытке реализовать алгоритмы на тысячах узлов).

Решите системные проблемы один раз для любой полугруппы / моноида / группы / кольца, и тогда вы сможете подключить любой алгоритм, не думая о Memcache, Hadoop, Storm и т. Д.

Как Bloom filters/ hyperloglog/ countminsketchкак числа?

Почему агрегаты баз данных имеют моноидальную структуру?
Как выглядит этот моноид? У них когда-нибудь есть групповая структура?

Литературные ссылки будут полезны.

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

$a$$b$$a$$b$$a.b$

$.$$(a.b).c = a.(b.c)$

Почти всегда есть какая-то идентичность, будь то число 0 или 1, пустая строка, матрица идентичности, равномерное распределение или пустой набор, который зависит от операции. Так что на самом деле данные обычно образуют моноид .

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

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

$+$$.$$.$$+$$.$

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

• Стефано Бистарелли, Уго Монтанари и Франческа Росси, Удовлетворение и оптимизация ограничений на основе полукольца , JACM 44 (2), 1997, 201–236. doi: 10.1145 / 256303.256306

Нынешний всплеск теоретического анализа полукольцевой модели агрегирования данных был запущен в 2007 году в контексте провенанса . Происхождение это причудливый термин для аннотирования данных. Поскольку любой кортеж базы данных можно рассматривать как аннотации, применяемые к некоторому уникальному идентификатору кортежа, агрегирование данных можно рассматривать как просто комбинацию аннотаций. Таким образом, провенанс является обобщением идеи агрегирования данных, и было явно доказано, что правильная теоретическая модель объединения аннотаций является полукольцом. Самый общий полукольцо, из полиномов провенанса, фактически позволяет отслеживать всю историю того, как часть данных была получена из составных частей. В качестве примера, р-значениеПри анализе клинического испытания можно отслеживать, как оно было рассчитано на основе каждого из отдельных результатов испытания. Если некоторые из них окажутся неверными (или фальшивыми), то можно просто пересчитать без неверных данных.

• Тодд Дж Грин, Grigoris Karvounarakis и Val Tannen, Провенанс полукольцами , стручки 2007, 31-40. doi: 10.1145 / 1265530.1265535

Была проведена большая работа по использованию полуколец для агрегирования данных, см. Статьи, цитирующие эту .

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

• Сринивас М. Аджи и Роберт Дж. Маклис, Обобщенное распределительное право , IEEE. Труды по теории информации 46 (2), 2000, 325–343. doi: 10.1109 / 18.825794