Понадобилась мне база данных, да не простая, а чтоб ну очень быстрая была.
Итак:
— у меня есть огромная куча данных, которые по сути представляют граф.
— в процессе работы важна только скорость чтения. Записи не будет.
— основной способ работы с данными (~80-85%) — обход графа по рёбрам, т.е. будет много маленьких запросов на еденицу времени.
— к БД нужен доступ из java. (Поэтому и пишу в этот форум, может зря?)
Склоняюсь к какой-то из реализаций InMemory DB, но поскольку не имел вообще дела с этим счастьем — обращаюсь к вам, может подскажете куда смотреть, чтоб не перебирать все и самому смотреть на производительность чтения?
Да, и в случае in-memory DB обязательно нужна возможность сохранение состояния БД на диск, чтоб не пересоздавать граф заново.
Здравствуйте, PAS_Tor, Вы писали:
PAS>Склоняюсь к какой-то из реализаций InMemory DB, но поскольку не имел вообще дела с этим счастьем — обращаюсь к вам, может подскажете куда смотреть, чтоб не перебирать все и самому смотреть на производительность чтения?
Если граф большой, то InMemory в пролёте.
Здравствуйте, Cyberax, Вы писали:
C>Если граф большой, то InMemory в пролёте.
Граф большой, но скорость на данный момент еще важнее. Потому не проблема составить кластер или даже взять один Amazon ec2 instance up to 64Gb RAM. Пока я себя не ограничиваю в этом пункте, как минимум до окончания поисков.
C>Из всех остальных, самая быстрая — h2 database.
Здравствуйте, PAS_Tor, Вы писали:
PAS>Всем доброго дня/ночи.
PAS>Понадобилась мне база данных, да не простая, а чтоб ну очень быстрая была. PAS>Итак: PAS>- у меня есть огромная куча данных, которые по сути представляют граф. PAS>- в процессе работы важна только скорость чтения. Записи не будет. PAS>- основной способ работы с данными (~80-85%) — обход графа по рёбрам, т.е. будет много маленьких запросов на еденицу времени. PAS>- к БД нужен доступ из java. (Поэтому и пишу в этот форум, может зря?)
Здравствуйте, PAS_Tor, Вы писали:
PAS>Всем доброго дня/ночи.
PAS>Понадобилась мне база данных, да не простая, а чтоб ну очень быстрая была. PAS>Итак: PAS>- у меня есть огромная куча данных, которые по сути представляют граф. PAS>- в процессе работы важна только скорость чтения. Записи не будет. PAS>- основной способ работы с данными (~80-85%) — обход графа по рёбрам, т.е. будет много маленьких запросов на еденицу времени. PAS>- к БД нужен доступ из java. (Поэтому и пишу в этот форум, может зря?)
Здравствуйте, PAS_Tor, Вы писали:
PAS>Всем доброго дня/ночи.
PAS>Понадобилась мне база данных, да не простая, а чтоб ну очень быстрая была. PAS>Итак: PAS>- у меня есть огромная куча данных, которые по сути представляют граф. PAS>- в процессе работы важна только скорость чтения. Записи не будет. PAS>- основной способ работы с данными (~80-85%) — обход графа по рёбрам, т.е. будет много маленьких запросов на еденицу времени. PAS>- к БД нужен доступ из java. (Поэтому и пишу в этот форум, может зря?)
Здравствуйте, PAS_Tor, Вы писали:
C>>Если граф большой, то InMemory в пролёте. PAS>Граф большой, но скорость на данный момент еще важнее. Потому не проблема составить кластер или даже взять один Amazon ec2 instance up to 64Gb RAM. Пока я себя не ограничиваю в этом пункте, как минимум до окончания поисков.
Просто оверхед от хранения данных в виде объектов очень велик.
C>>Из всех остальных, самая быстрая — h2 database. PAS>Спасибо большое, учтём. PAS>P.S. Насколько я понял in-memory она тоже умеет?
Да, умеет.
Здравствуйте, Cyberax, Вы писали:
C>Просто оверхед от хранения данных в виде объектов очень велик.
Да, я в курсе, к сожалению. Но оперировать массивами простых типов в памяти тоже не выход — нет гибкости поиска, сложно вносить изменения (когда они всё-таки нужны). Потому смотрю что есть на просторах БД.
Здравствуйте, iZEN, Вы писали:
ZEN>Специально для таких данных разработаны no-SQL БД. ZEN>Смотрите Apache Cassandra и HyperGraphD.
HyperGraphD смотрел. Немного не та специфика, там упор на общность данных, которые можно положить в БД, а не на скорость при моих масштабах данных. Кассандру гляну, спасибо.
Цитата отсюда:
HyperGraphDB has some generalizations that you don't see in any other
graph database (ability of edges to point n > 0 nodes, ability of
edges to point to other edges, the notion of types and type
constructors integrated at the core of the system). That doesn't make
HyperGraphDB necessarily better, because the extra generality
translates into different storage layout on disk which has
consequences for how you represent and query things.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, PAS_Tor, Вы писали:
PAS>>Всем доброго дня/ночи.
PAS>>Понадобилась мне база данных, да не простая, а чтоб ну очень быстрая была. PAS>>Итак: PAS>>- у меня есть огромная куча данных, которые по сути представляют граф. PAS>>- в процессе работы важна только скорость чтения. Записи не будет. PAS>>- основной способ работы с данными (~80-85%) — обход графа по рёбрам, т.е. будет много маленьких запросов на еденицу времени. PAS>>- к БД нужен доступ из java. (Поэтому и пишу в этот форум, может зря?)
ZEN>Специально для таких данных разработаны no-SQL БД. ZEN>Смотрите Apache Cassandra и HyperGraphD.
С Hypergraph нужно быть очень аккуратным. Документация — гауно(куча ошибок, часть — устаревшая), коммьюнити — ноль, на яве версии, насколько я знаю, отрабатываются концепции, которые будут использованы в C/С++ версии. Для production я бы не рискнул использовать эту штуку.
Я пока использую mongoDB. Непосредственно для графов она не предназначена, но мне хватает. Есть драйвера под основные языки, приличная документация, активные юзергруппы, роадмап и тд
Ничего туманного. Пишите — Вам отвечают.
Лийензия зависит от кол-ва всего, что вы попытаетесь запхнуть в БД, считаются ноды, связи, и любые параметры нод или связей.
Здравствуйте, hudvin, Вы писали:
H>Здравствуйте, b_manvelyan, Вы писали:
_>>Здравствуйте, PAS_Tor, Вы писали: _>>neo4j ? H>Туманная схема лицензирования.
Здравствуйте, PAS_Tor, Вы писали:
PAS>Ничего туманного. Пишите — Вам отвечают. PAS>Лийензия зависит от кол-ва всего, что вы попытаетесь запхнуть в БД, считаются ноды, связи, и любые параметры нод или связей.
