Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
No-SQL c большими возможностями, бесплатной лицензией, малый размер, на Java. Минусы - проблемы при работе local mode с Java API, неадекватная, странная поддержка форума (острые вопросы о неработоспособности API игнорируются). Но выглядит вкусно, видимых альтернатив как объектной СУБД с богатым языком запросов нет. Интересует опыт использования в боевых задачах. Насколько верны утверждения о сверхпроизводительности и мегамасштабируемости.
22 ноя 12, 01:15    [13510884]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
george33
Но выглядит вкусно

если сама СУБД на Java, то выглядит вкусно она только для программистов на Java, и ни для кого более. И ни о каких "сверхпроизводительности и мегамасштабируемости" не может быть и речи.
22 ноя 12, 02:08    [13510964]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33,
а дайте ссылку на описание архитектуры.
А то что-бы прикинуть сверхпроизводительность и масштабируемость - можно просто посмотреть на то, как они получаются :)
22 ноя 12, 03:24    [13511017]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
kdv,
если грамотно писать, можно издержки от java снизить. имхо. а жирный плюс - переносимость, опциональная встраиваемость, которая дает жирный плюс в отсутствии прокидывания/парсинга/упаковки между процессами.

доки
http://code.google.com/p/orient/wiki/Main

архитектура
http://code.google.com/p/orient/wiki/Concepts
22 ноя 12, 04:15    [13511025]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33,
что-то не вижу я поводов для сверхмасштабируемости и сверхпроизводительности.

Честно говоря, не вижу и принципиальных отличий от любой нормальной rdbms с хранением в блобах json-сериализованных объектов (и полей для индексов).
22 ноя 12, 04:48    [13511030]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
DPH3
george33,
что-то не вижу я поводов для сверхмасштабируемости и сверхпроизводительности.

Честно говоря, не вижу и принципиальных отличий от любой нормальной rdbms с хранением в блобах json-сериализованных объектов (и полей для индексов).


отличие в объектности. документ в док-ориентированной субд правится единым целым, здесь же документ - один из вариантов работы. лично мне не подходящий, а вот плести паутину объектов размером в терабайты - вот из-за этого я интересуюсь.
22 ноя 12, 05:30    [13511038]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
george33
No-SQL c большими возможностями, .

А там вроде SQL есть. Или что имелось в виду?
Насчет величины возможностей может преждевременно? Может надежнее дожаться каких-нибудь независимых источников?
22 ноя 12, 09:56    [13511519]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
george33
Насколько верны утверждения о сверхпроизводительности и мегамасштабируемости.
Для тестирования того и другого можете воспользоваться Yahoo! Cloud System Benchmark (YCSB), где есть поддержка в том числе OrientDB.
22 ноя 12, 10:36    [13511647]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33
отличие в объектности. документ в док-ориентированной субд правится единым целым, здесь же документ - один из вариантов работы.

Хм, судя по документации, тут запись вида документ мы также меняем целиком. И это - единственный "объектно-ориентированный" вариант. Поля типа "flat" от обычной РСУБД вообще ничем не отличаются.
Используемые механизмы ссылок от индексов в РСУБД также фактически не отличаются.

паутину объектов размером в терабайты - вот из-за этого я интересуюсь.

Если не секрет, что за предметная область, где терабайты объектных данных, но при этом можно использовать плохоподдерживаемую СУБД?
22 ноя 12, 10:48    [13511703]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33,
почитал описание внимательно.

В качестве маленькой примитивной embedded базы данных вполне может составить конкуренцию какой-нибудь sqllite, может даже побыстрее будет, если хорошо понимать, как устроена работа с диском в OrientDB и аккуратно настраивать стратегии кэширования и индексы.
По сравнению с любой большой БД и на больших объемах - будет заметно проигрывать, в первую очередь из-за примитивной схемы кэширования и примитивной схемы работы с диском.

Для Java для больших проектов связка ehcache+большая БД будет заметно производительнее.
22 ноя 12, 11:25    [13511877]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

И чем оно отличается от Н2, например?..

Posted via ActualForum NNTP Server 1.5

22 ноя 12, 15:50    [13514110]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
DPH3,

а что можете посоветовать объектное, сравнимое по цене-качеству-простоте? я близко ничего не вижу - даже за большие деньги. но я новичок на JVM


Dimitry Sibiryakov,

одно и то же ядро-код работает хоть с embedded, хоть с кластером. объектность+расширяемая схема на лету.
22 ноя 12, 16:17    [13514251]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

george33
одно и то же ядро-код работает хоть с embedded, хоть с кластером.
объектность+расширяемая схема на лету.

Это же самое заявляет и Н2 и даже Firebird. Но они-то хоть годами обкатаны и не имеют на
своём сайте страниц "under construction".

Posted via ActualForum NNTP Server 1.5

22 ноя 12, 16:23    [13514297]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
vadiminfo
george33
No-SQL c большими возможностями, .

А там вроде SQL есть. Или что имелось в виду?
Насчет величины возможностей может преждевременно? Может надежнее дожаться каких-нибудь независимых источников?


дождаться не смогу. нужно определяться. sql там есть, но он объектный, и база объектная, то есть она понимает что от чего наследуется и учитывает в запросах
22 ноя 12, 16:26    [13514313]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
Dimitry Sibiryakov,

да, H2 выглядит интересно. буду думать.. :)
22 ноя 12, 16:32    [13514374]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
george33
а что можете посоветовать объектное, сравнимое по цене-качеству-простоте? я близко ничего не вижу - даже за большие деньги. но я новичок на JVM
дождаться не смогу. нужно определяться. sql там есть, но он объектный, и база объектная, то есть она понимает что от чего наследуется и учитывает в запросах
Как я понимаю, Вам нужна СУБД с поддержкой ООП, SQL и NoSQL?
22 ноя 12, 16:35    [13514399]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33,
вы лучше конкретную задачу опишите. Я с трудом представляю в реальном продакшене нишу для ООБД.

Когда мне нужно работать с сложными документами, я сериализую их в блобы (Jackson, Spring jdbcTemplate и, собственно, все). Если производительность не критична, то можно обойтись каким-нибудь Hibernate и вообще не думать, что там на урове СУБД.
22 ноя 12, 16:50    [13514533]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
Задача, которую предстоит решать - торговля / бронирование/аренда недвижимости в масштабах большой, не нашей страны.
т. е. расширяемость пригодилась бы для описания всего многообразия подобных объектов, географические индексы , + подсистемы для работы с клиентами разных уровней и целей. только на первом этапе :)
22 ноя 12, 17:00    [13514638]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33,
Ну и в чем проблема?
Конкретный элемент недвижимости - объект какого-то конкретного класса, вполне себе сериализуется в блоб (Jackson), нужен обычно целиком. Jackson вполне себе умеет работать с наследуемыми параметрами сериализации, все там просто.

Те поля, по которым происходит поиск - вытаскиваются в отдельные поля, на них все равно придется вешать индекс. Но этих полей сравнительно мало, на самом-то деле.

Если нужен полнотекстовый поиск - то все равно SOLR прикручивать.

Если нужен очень сложный поиск - то, в любом случае, придется ручками делать.

При этом ровно то же самое придется делать в любой ООП базе - отдельно создавать индексы по тем полям, по которым ищешь и все остальное хранить "as is". В лучшем случае в ООБД сможешь упростить добавление "индексного поля" в обмен на поиск глюков и поддержку малоизвестной СУБД.

Горизонтальное масштабирование для объемов даже всего китайского рынка недвижимости вряд ли будет необходимо, не так уж и много разных сущностей и не такой уж и большой поток запросов.
22 ноя 12, 17:16    [13514770]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
DPH3,
джейсон знаю, Jackson - это про что?
мне объектность нужна из-за легкой расширяемости. табличные базы нужно будет постоянно курочить, это пугает, не потеряю ли данные. в объектных такой проблемы нет. добавил класс или поле, ей все равно. на остальном не сказывается.

>>Если нужен очень сложный поиск - то, в любом случае, придется ручками делать.

Это не пугает, главное чтобы база нигде не чинила для этого препятствия. в объектной я могу выбрать объекты, имеющие поле новое xx,
даже если я добавил их после определения схемы, xx не учитывающей. без лишнего кашля. можно ли от Н2 поиметь хоть треть этой гибкости?
22 ноя 12, 19:04    [13515521]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
george33
мне объектность нужна из-за легкой расширяемости. табличные базы нужно будет постоянно курочить, это пугает, не потеряю ли данные.


рукалицо.жпг

george33
Это не пугает, главное чтобы база нигде не чинила для этого препятствия. в объектной я могу выбрать объекты, имеющие поле новое xx,
даже если я добавил их после определения схемы, xx не учитывающей. без лишнего кашля. можно ли от Н2 поиметь хоть треть этой гибкости?


Дык спроектируйте так, чтоб "база не чинила препятствий". А то опять какая-то серебрянная пуля...
22 ноя 12, 20:13    [13515814]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
george33,

Почитайте, как можно реализовать "объектную модель" при использовании "классической" РСУБД: http://www.osp.ru/os/2005/05-06/185601/

ЗЫ. Проекты на данном "фреймворке" реализовывались и на базе Oracle и на базе MS SQL.
22 ноя 12, 20:25    [13515847]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
george33
Member

Откуда:
Сообщений: 18
pkarklin
george33
мне объектность нужна из-за легкой расширяемости. табличные базы нужно будет постоянно курочить, это пугает, не потеряю ли данные.


рукалицо.жпг



глубоко очень. нельзя ли подробней, особенно про жпг..
22 ноя 12, 21:32    [13516056]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
george33,

Это Вы нам, любезный, расскажите про:

автор
не потеряю ли данные


В чем пичалька то? В незнаниях РСУБД?
22 ноя 12, 21:35    [13516067]     Ответить | Цитировать Сообщить модератору
 Re: OrientDB  [new]
DPH3
Member

Откуда:
Сообщений: 456
george33
DPH3,
джейсон знаю, Jackson - это про что?

Это библиотека сериализации/десериализации Java-объектов в JSON. Быстрая и гибкая.

мне объектность нужна из-за легкой расширяемости. табличные базы нужно будет постоянно курочить, это пугает,

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

А уж сложностей с добавлением одной колонки к БД я ни в одной приличной БД не видел (ну, в Оракле - 9ке был баг, но это давно уже было).

Это не пугает, главное чтобы база нигде не чинила для этого препятствия. в объектной я могу выбрать объекты, имеющие поле новое xx, даже если я добавил их после определения схемы, xx не учитывающей. без лишнего кашля.

Не совсем верно. Это возможно только если добавлено простое поле, если устраивает table scan по всем объектам класса и т.п. Ну или нужно создавать индексное поле - тогда поиск будет за разумное время.
По сложности организации - точно также, как и в реляционной БД.
И в любом случае придется разбираться, а как оно все устроено на нижнем уровне, без этого и данные будут теряться и тормозить все будет. Но только по РСУБД обычно документация лучше :)

можно ли от Н2 поиметь хоть треть этой гибкости?

А зачем H2? Глючно и малофункционально. БД нужно искать исходя из наличия DBA. Postgress/DB2/Oracle/MySQL и т.п. Но всякую экзотику на коммерческом продакшене - нафиг, нафиг.
22 ноя 12, 23:24    [13516393]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить