My<cod/>.net
опыт db4o?
В настоящее время я пробую db4o (версия java), и мне очень нравится то, что я вижу. Но я не могу не задаться вопросом, как он работает в реальной живой (web-)среде. Есть ли у кого-нибудь опыт (хороший или плохой), чтобы поделиться им о запуске db4o?
Мы запускаем версию DB40 .NET в большом клиент-серверном проекте.
Наш опыт показывает, что вы потенциально можете получить гораздо лучшую производительность, чем обычные реляционные базы данных.
Однако вам действительно нужно настроить свои объекты, чтобы получить такую производительность. Например, если у вас есть список, содержащий много объектов, DB4O активация этих списков происходит медленно. Существует несколько способов обойти эту проблему, например, перевернув отношения.
Другая боль-это активация. Когда вы извлекаете или удаляете объект из DB4O,по умолчанию он активирует все дерево объектов. Например, загрузка Foo будет загружать Foo.Bar.Baz.Bat и т. д. до тех пор, пока не останется ничего для загрузки. Хотя это хорошо с точки зрения программирования, производительность будет замедляться тем больше вложенности в ваши объекты. Чтобы повысить производительность, вы можете указать DB4O, сколько уровней глубины нужно активировать. Это отнимает много времени, если у вас есть много объектов.
Еще одной областью боли был поиск текста. Текстовый поиск DB4O намного медленнее, чем полнотекстовая индексация SQL. (Они скажут вам об этом прямо на своем сайте.) Хорошая новость заключается в том, что на DB4O легко настроить текстовую поисковую систему. в нашем проекте мы подключили Lucene.NET для индексирования текстовых полей, которые мы хотим.
Некоторые APIs, похоже, не работают, например GetField APIs, полезные при применении обновлений базы данных. (Например, вы переименовали свойство и хотите обновить существующие объекты в базе данных, вам нужно использовать эти "reflection" APIs для поиска объектов в базе данных. Другие APIs, такие как атрибут [Index], не работают в стабильной версии 6.4, и вместо этого необходимо указать индексы с помощью Configure().Индекс("someField"), который не является строго типизированным.
Мы наблюдали снижение производительности по мере увеличения вашей базы данных. Сейчас у нас есть база данных объемом 1 ГБ, и все по-прежнему быстро, но не так быстро, как когда мы начинали с крошечной базы данных.
Мы нашли еще одну проблему, когда Db4O.GetByID закроет базу данных, если ID больше не существует в базе данных.
Мы обнаружили, что собственный синтаксис запросов (самый естественный, интегрированный в язык синтаксис для запросов) намного медленнее, чем менее дружественные запросы SODA. Так что вместо набора текста:
// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);
Вместо этого хорошего кода запроса вы должны получить уродливый запрос SODA, который строковый и не сильно типизированный.
Для людей .NET они недавно представили провайдер LINQ-to-DB4O, который обеспечивает лучший синтаксис на данный момент. Однако еще предстоит выяснить, будет ли производительность up-to-par с уродливыми SODA запросами.
Поддержка DB4O была неплохой: мы несколько раз говорили с ними по телефону и получили полезную информацию. Их форумы пользователей почти ничего не стоят, однако почти все вопросы остаются без ответа. Их трекер ошибок JIRA получает много внимания, поэтому, если у вас есть назойливый баг, файл его на JIRA на нем часто будет исправляться. (У нас было 2 ошибки, которые были исправлены, и еще одна, которая была исправлена наполовину.)
Если все это не отпугнуло вас, позвольте мне сказать, что мы очень довольны DB4O, несмотря на проблемы, с которыми мы столкнулись. Производительность у нас уже сдулся некоторые объектно-реляционного сопоставления структур мы попытались. Я вам это рекомендую.
обновление июль 2015 имейте в виду, этот ответ был написан еще в 2008 году. Хотя я ценю апвоты, мир с тех пор изменился, и эта информация может быть не такой надежной, как тогда, когда она была написана.
Большинство собственных запросов могут и эффективно преобразуются в SODA запросов за кулисами, так что это не должно иметь значения. Использование NQ, конечно, предпочтительнее, поскольку вы остаетесь в области сильного типизированного языка. Если у вас есть проблемы с получением NQ для использования индексов, пожалуйста, не стесняйтесь размещать свою проблему на форумах db4o , и мы постараемся вам помочь.
Горан