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