Pull to refresh

Comments 17

Давно не работал с этой базой. Очень порадовали фичи: хранимые процедуры и dynamic objects. Было бы интересно сравнение Eloquera c другими ООБД.
Там еще много всего нового вводится. У команды релизы выходят теперь каждые 2 недели кажется и с каждым добавляется новый интересный функционал.
В последней версии 4.1 они добавили методы для эволюции/миграции типов данных.
Очень динамично все развивается. Детальный обзор в ближайшее время можно будет найти на моем личном блоге. Размер обзора не позволяет его выдать одной статьей — хотя сделаю единый PFD для удобства на 37 страниц.
Сравнение с другими базами легко выливается в эпик опус и развязыванию holywar. Всегда ведь будут нюансы которые можно пропустить, если не работаешь с базой каждый день. =)
UFO landed and left these words here
С форума результаты third-party теста — eloquera.com/content/eloquera-db-411-stored-procedures-schema-evolution:

Store 1e6 objects

Eloquera Time: 00:05:20.0892005 Records Created: 1000000 commit every: handled internal api

LINQ query, find single record (1e6 objects in the database)

Eloquera Time: 00:00:02.7924049 Linq Query FileID: 500000


Насколько понимаю, делали 500000 запросов по одному объекту. Но — лучше всего! — написать тест со своими объектами. Это займет буквально минуту-другую, особенно, если взять готовый проект с сайта и просто заполнить его своими объектами.
Вот в отношении всяких object databases есть такое соображение: оно либо внутри использует реляционную модель и как следствие реляционную теорию для оптимизации запросов (а посему имеет мерзкий ORM-слой внутри), либо не использует и оптимизирует запросы через Ж, либо я чего-то не знаю. Хотелось бы верить в третье.
Кроме реляционно-табличной модели, есть куча других: деревья, графы, списки, tries. В объектных базах могут использоваться всякие сложные сочетания подобных моделей. К примеру, в этой конкретной базе используются таблицы со списками (такой вот гибрид), деревья деревьев со списками (еще более гибридный вариант), и еще несколько других моделей хранения данных.

А оптимизатор заточен именно под эти модели — поэтому запросы быстрые. Там даже join'ы поддерживаются.
>Кроме реляционно-табличной модели, есть куча други

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

>А оптимизатор заточен именно под эти модели — поэтому запросы быстрые. Там даже join'ы поддерживаются.

То есть язык запросов все таки не такой мощный, как SQL? (Мощь SQL видимо обусловлена как раз реляционной моделью и целой теорией для таких моделей)
> То есть язык запросов все таки не такой мощный, как SQL?

Не совсем понял логического вывода, признаюсь. Там SQL — привычный, без дикостей типа Price > 3 (некоторые системы только так и работают) — но для объектов. Поэтому со своей спецификой, типа

SELECT Book WHERE Price < 10

(можно не использовать FROM) или специальной поддержкой массивов (включая объектные):

SELECT Author WHERE Books.PublishedYear > 2000

Этот запрос работает даже если Books — это массив Book[], a PublishedYear — это поле объекта Book.

Т.е. в реляционной базе тут нужен бы как минимум один JOIN (а то и 2 — ведь у книги может быть много авторов), а тут — запрос «в лоб».
>> Могу организовать цикл статей если будет интересно, материал готовый есть.
Очень даже не помешает!

Интерес велик. Очень радует текстовый язык запросов и обещание возможности встраивать ее в свои приложения в виде dll для использования, например, на хостинге.

Сравнение со всеми не нужно, но хотелось бы сравнения с db4o.
Сравнение с db4o было бы интересно, но может оказаться некорректным в плане производительности. К примеру, при вставке 100 MB объектов однопоточная db4o окажется быстрее многопоточной Eloquera, но при работе, к примеру, с 1 GB данных картина резко меняется.

Запросы в Eloquera работают в десятки раз быстрее, чем в db4o, и разница возрастает с объемом данных. Поэтому обычный «быстрый» тест с 10 000 объектов просто даст картину на 10 000 объектов. Попробуйте запустить запросы от 10 пользователей в обеих базах — получите параллельные запросы в Eloquera и последовательные в db4o.

Это как сравнивать автомобиль и велосипед — да, автомобиль заводится и заправляется дольше, но и едет в разы быстрее.
Настораживает вот такой код в Storage причем во всех методах (Seek, Read, Write и др.)
lock (this.StorageStream)
{
...
}

Вроде как для этого есть ReaderWriterLockSlim.
Чтения и записи буферизуются и кэшируются — поэтому происходят не так часто. К тому же, Monitor (тот же lock) в целом быстрее, чем ReaderWriterLockSlim, если операции чтения и записи происходят недетерминированно.
2. Any distribution of Eloquera database, including as a part of commercial and non-commercial software, requires written permission from Eloquera.
To obtain a written permission the following information will be required, but not limited to.
Печально.
А что именно печально? Written permission нынче — это несколько строчек по электронной почте. :-) Минуты 2 от силы.
Ну и зачем мне нужно подсаживаться на некий продукт, изучать его, продвигать в комьюнити, если в следующем проекте я могу письменное разрешение уже не получить? Я предпочту альтернативные open source решения или закрытые решения от более именитых производителей, которые не будут требовать от меня получения разрешений.
Вы неплохо изложили мысль, но, боюсь, не совсем по поводу Eloquera. Помогу с переводом:

Распространение базы данных Eloquera, в том числе — в составе коммерческих или некоммерческих продуктов — требует письменного разрешения из Eloquera.

Как видим, разрешение нужно именно на распространение, а не на использование. Или вы раздаете Oracle/MSSQL/DB2/MySql со своими программами?

Альтернативные системы (в том числе — open source) позволяют распространение — от $1500 за копию. Такова реальность.
Only those users with full accounts are able to leave comments. Log in, please.