Comments 14
бедный йорикRID
А вы смотрели в сторону Neo4j? Я когда-то имел удовольствие сравнивать эти базы данных и остановился на нео. Что вы думаете по этому поводу?
а во что она превращается на миллионах и миллиардах записей? и что она может предложить для переваривания таких объемов?
performance это изначально холивар, так что предлагаю в практической теме для новичков не поднимать вопрос производительности и сравнения с др. базами данных, но если все же интересно, то посмотрите тут
Я пока только присматриваюсь. Вобщем и целом — инструмент не для гагар.
С одной стороны сотни тысяч записей в секунду на среднем оборудовании и мгновенный join связанных записей, с другой стороны связи между таблицами проектируются на уровне архитектуры бд и вроде как полная деградация на запросах типа like «text%» (сваливается в fullscan).
Если у Вас есть четкое понимание что вы хотите от СУБД — ориент Ваш выбор. Если Вам нужно универсальное хранилище — то конечно нет, ну или использовать как документоориентированную БД.
Думаю это выбор аналитиков — типа какой товар покупают с прокладками, женщины старше 30 лет в после обеденное время примерно в том же ценовом диапазоне. Поразмышляйте на досуге сможете ли Вы ответить на этот вопрос с использованием классической БД, без построения DWH и OLAP над ней.
С одной стороны сотни тысяч записей в секунду на среднем оборудовании и мгновенный join связанных записей, с другой стороны связи между таблицами проектируются на уровне архитектуры бд и вроде как полная деградация на запросах типа like «text%» (сваливается в fullscan).
Если у Вас есть четкое понимание что вы хотите от СУБД — ориент Ваш выбор. Если Вам нужно универсальное хранилище — то конечно нет, ну или использовать как документоориентированную БД.
Думаю это выбор аналитиков — типа какой товар покупают с прокладками, женщины старше 30 лет в после обеденное время примерно в том же ценовом диапазоне. Поразмышляйте на досуге сможете ли Вы ответить на этот вопрос с использованием классической БД, без построения DWH и OLAP над ней.
Про like я кажется погорячился, надо писать SELECT FROM Account WHERE notes CONTAINSTEXT 'Adam'
ну для полнотекстового поиска есть более подходящие инструменты, а графовая БД нужна для выполнения своего специфичного стека задач, связанного с обработкой именно структуры этого графа. Не стоит забивать микроскопом гвозди
Как раз присматриваюсь к OrientDb для построения рекомендательного сервиса. На первый взгляд — она идеально подходит для этих целей.
По поводу продолжения: хотелось бы увидеть примеры запросов с использованием gremlin.
Еще интересно было бы почитать про поиск. Есть ли интеграция с чем ть типа Lucene?
Можно ли как то сочетать 2 модели хранения перелинковав их между собой?
По поводу продолжения: хотелось бы увидеть примеры запросов с использованием gremlin.
Еще интересно было бы почитать про поиск. Есть ли интеграция с чем ть типа Lucene?
Можно ли как то сочетать 2 модели хранения перелинковав их между собой?
Там недавно документация обновилась — рекомендую почитать.
В частности про Lucene: www.orientechnologies.com/docs/last/orientdb-lucene.wiki/Full-Text-Index.html
Сочетать две модели можно. Глафовая модель — не более, чем удобное апи над документной субд. Грубо говоря, вместо «в такое-то поле такой-то записи добавить ссылку на другую, а в другое поле другой записи добавить ссылку на первую» мы пишем просто «слинковать такую-то запись с такой-то используя такой-то тип связи».
В частности про Lucene: www.orientechnologies.com/docs/last/orientdb-lucene.wiki/Full-Text-Index.html
Сочетать две модели можно. Глафовая модель — не более, чем удобное апи над документной субд. Грубо говоря, вместо «в такое-то поле такой-то записи добавить ссылку на другую, а в другое поле другой записи добавить ссылку на первую» мы пишем просто «слинковать такую-то запись с такой-то используя такой-то тип связи».
Sign up to leave a comment.
OrientDB — простой пример работы с графами для начинающих