База данных Graph для .NET, поможет ли она в нашем случае?

Краткое описание нашего приложения: Мы анализируем сборки .NET и выявляем зависимости между ними (например, вызовы методов). Мы сохраняем эти зависимости в базе данных сервера MSSQL. Из класса/метода в коде теперь мы можем найти все прямые и косвенные зависимости и узнать, какой код может сломаться, если мы изменим интерфейс или реализацию.

Несмотря на то, что мы хорошо используем индексы (ухудшили производительность импорта, но он все равно работает в одночасье), у нас все еще есть проблемы с производительностью. Поскольку мы импортируем множество версий одной и той же сборки, у нас довольно большой объем данных, а запросы занимают несколько секунд, что просто недостаточно быстро (‹ 1,5 с — цель).

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

Если да, вы, конечно, также можете опубликовать рекомендуемую базу данных графов .NET :-)


person D.R.    schedule 29.08.2012    source источник
comment
В каком масштабе вы работаете? Это миллионы строк? Миллиарды? Адекватно ли аппаратное обеспечение? Вы уверены, что больше не нужно проводить оптимизацию? Пожалуйста, обновите свой вопрос, указав дополнительную информацию, подобную этой, и это может помочь кому-то посоветовать вам лучше.   -  person Tom Chantler    schedule 29.08.2012
comment
В настоящее время у нас есть около 1,5 миллиона записей для целей тестирования в важной таблице зависимостей, однако мы думаем, что в продуктивном режиме нам придется иметь дело с примерно 10 миллионами записей. Аппаратно — 4-ядерный Intel Core2, достаточно оперативной памяти, нормальный HDD (к сожалению, без SSD).   -  person D.R.    schedule 29.08.2012
comment
Таблица зависимостей: TYPE, PART_REFERENCED, PART_DEPENDENT Таблица частей зависимостей: ASSEMBLY_ID, TYPE_ID, MEMBER_ID, SRC_FILE, SRC_LINE   -  person D.R.    schedule 29.08.2012
comment
Справочная информация: мы можем легко выполнить запрос прямой зависимости вовремя, однако мы должны рекурсивно запрашивать базу данных для косвенных зависимостей, что затем занимает время...   -  person D.R.    schedule 29.08.2012
comment
Как насчет чтения данных из базы данных в график в памяти при запуске и запроса к нему? 10 миллионов записей — это не так уж много.   -  person Patrik Svensson    schedule 29.08.2012
comment
Проблема с графиком in-memory заключается в том, что мы ежедневно импортируем ночные сборки. Нам пришлось бы восстанавливать это каждый день. По той же причине кэширование не очень нам помогает.   -  person D.R.    schedule 29.08.2012


Ответы (1)


Назовите меня старым туманным, но я был бы очень осторожен при переключении такой технологии, как это -a-proven-track-record">SO question показывает, что выбор технологий довольно ограничен, и я думаю, вы рискуете превратить свой проект в проект "Neo4J", а не в "управление зависимостями" проект. Если вы действительно попали в буферы, это стоит рассмотреть, но не похоже, что вы должны быть там с объемами данных, которые вы обсуждаете.

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

person Neville Kuyt    schedule 29.08.2012