SpinifexКоллеги,
Ищу СУБД для хранения графа. Граф не направленный, не взвешенный, размерность графа не более 100 000 узлов.
По факту нужно хранить матрицу 100 000 на 100 000, где каждый бит указывает на наличие связи. Такую СУБД в принципе не долго и самому написать, но есть проблема, что пользоваться ей должны из нескольких приложений, написанных на разных языках. Так что какое-то готовое решение - предпочтительнее.


Сейчас храним данные в SQL сервер, для каждой связи - запись в таблице. Не устраивает скорость проверки наличия связи и скорость добавления новой связи, размер БД. Очевидно, что в случае с матрицей можно добиться наилучшей производительности.
Есть ли что-то похожее?

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

SQL Server 2017?

EleanorРолг Хупин,

Посмотрела документацию MS по SQL Graph-у - даже там внизу несколько негативных отзывов: MS всего лишь создал "синтаксический сахар" поверх реляционной по сути реализации.
В результате получатся ровно те же таблицы, что у ТС, с похожим размером и похожей производительностью.

мэм, что-то я про сахар не нашел там, однако, хорошая фича.
Негативные отзывы будут всегда и обо всём, я, например, могу вам написать десяток матерных негативных отзывов про FTS, и даже для 2017.

EleanorРолг Хупинчто-то я про сахар не нашел там
I see no section about indexing and why this is better/different from implementing it traditionally. Is this merely syntactic sugar ?

Ролг Хупиноднако, хорошая фича
"Хорошая" - это в текущей версии Sql Server 2017 или в будущем? Уже ей пользовались?

ТС спрашивал про размер и производительность:

- Графы MS пока что используют традиционные таблицы с традиционными индексами.
Если залить данные ТС в граф, то это будут те же таблицы, что у него есть, но с опциями AS NODE и AS EDGE и несколькими скрытыми полям (2 и 8 полей). Объем данных в итоге увеличится.

- Синтаксис MATCH эквивалентен нескольким JOIN, в планах выполнения запросов будут JOIN-ны. Производительность запросов немного выше , т.к. строятся другие планы выполнения.

Возможно, ТС есть смысл перелить данные в граф MS, но лишь потому что он уже хранит их в Sql Server.

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