В настоящее время я пытаюсь использовать db4o (версия java), и мне очень нравится то, что я вижу. Но я не могу не задаться вопросом, как это происходит в реальной живой (веб-среде) среде. Кто-нибудь имеет опыт (хороший или плохой), чтобы поделиться о запуске db4o?db4o опыта?
Мы запускаем версию DB40 .NET в крупном проекте клиент/сервер.
Наш опыт в том, что вы можете получить гораздо лучшую производительность, чем обычные реляционные базы данных.
Однако вам действительно нужно настроить свои объекты, чтобы получить такой вид производительности. Например, если у вас есть список, содержащий много объектов, активация этих списков DB4O выполняется медленно. Существует множество способов обойти эту проблему, например, путем инвертирования отношений.
Другая боль - это активация. Когда вы извлекаете или удаляете объект из DB4O, по умолчанию он активирует все дерево объектов. Например, загрузка Foo будет загружать Foo.Bar.Baz.Bat и т. Д., Пока загрузиться нечего. Хотя это хорошо с точки зрения программирования, производительность замедлит тем больше гнездования в ваших объектах. Чтобы повысить производительность, вы можете сообщить DB4O, сколько уровней нужно активировать. Это занимает много времени, если у вас много объектов.
Другая область боли - это поиск текста. Текстовый поиск DB4O далек, намного медленнее, чем полная индексация SQL. (Они расскажут вам об этом прямо на своем сайте.) Хорошей новостью является то, что легко установить текстовый поисковый движок поверх DB4O. В нашем проекте мы подключили Lucene.NET для индексации текстовых полей, которые мы хотим.
Некоторые API, похоже, не работают, такие как API-интерфейсы GetField, полезные при применении обновлений баз. (Например, вы переименовали свойство и хотите обновить существующие объекты в базе данных, вам нужно использовать эти «рефлексивные» API для поиска объектов в базе данных. Другие API, такие как атрибут [Index] t работают в стабильной версии 6.4, и вы должны указывать индексы с помощью Configure(). Index («someField»), который не сильно типизирован.
Мы стали свидетелями того, как производительность ухудшила вашу базу данных. 1GB базы данных прямо сейчас, и все по-прежнему быстро, но не так быстро, как когда мы начали с крошечной базы данных.
Мы обнаружили еще одну проблему, когда Db4O.GetByID закроет базу данных, если идентификатор не существует больше в базе данных.
Мы обнаружили, что синтаксис Native Query (самый естественный, интегрированный язык для синтаксиса запросов) намного медленнее, чем менее дружественные запросы 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, который обеспечивает лучший синтаксис. Тем не менее, пока неясно, будет ли производительность работать с уродливыми запросами SODA.
Поддержка DB4O была приличной: мы разговаривали с ними по телефону несколько раз и получали полезную информацию. Их пользовательские форумы находятся рядом с бесполезными, однако почти все вопросы остаются без ответа. Их JIRA-трекер-трекер получает много внимания, поэтому, если у вас есть ворчащая ошибка, файл на JIRA на ней часто исправляется. (У нас было 2 ошибки, которые были исправлены, и еще один, который был исправлен полузакрытым способом.)
Если все это вас не испугало, позвольте мне сказать, что мы очень довольны DB4O, несмотря на проблемы, с которыми мы столкнулись. Производительность, которую мы получили, сдула некоторые системы O/RM, которые мы пробовали. Я рекомендую это.
обновление июль 2015 г. Имейте в виду, что этот ответ был написан еще в 2008 году. Несмотря на то, что я ценю авансы, мир изменился с тех пор, и эта информация может быть не такой надежной, как была, когда она была написана.
Основная проблема, с которой я столкнулся, - это отчетность. Кажется, что нет никакого способа запуска эффективных отчетов против источника данных db4o.
Большинство собственных запросов могут и эффективно преобразуются в запросы SODA за кулисами, поэтому это не должно иметь значения. Использование NQ, конечно, предпочтительнее, поскольку вы остаетесь в сфере строгого языка. Если у вас возникли проблемы с получением NQ для использования индексов, не стесняйтесь сообщать о своей проблеме на db4o forums, и мы постараемся вам помочь.
Горан
Иуда, это звучит, как вы не используете прозрачные активации, которая является особенностью версии последней продукции (7.4)? Возможно, если вы указали версию, которую используете, поскольку могут возникнуть другие проблемы, которые теперь разрешены в последней версии?
Как вы смогли реализовать блокировку сервера при обработке запроса? Мы реализовали (я НАДЕЮСЬ!) Довольно наивный клиентский/серверный перфект, и мы заметили, что длительные запросы блокируют сервер от обработки других. Наши операции с первичным клиентом доступны только для чтения. – 2008-10-22 17:00:30
Пара вещей, которые вы можете попробовать: несколько баз данных, возможно, для каждого пользователя. Вы можете использовать режим клиента/сервера DB4O, а не встроенный режим, который обрабатывает потоки немного по-другому. – 2009-02-09 15:41:34
Привет, Иуда! По вопросам, о которых вы упомянули, глубина активации по умолчанию равна 5, поэтому db4o прекратит активировать объекты на глубине 5. Вы также можете попробовать прозрачную активацию (теперь db4o поддерживает собственные коллекции) и позволить db4o активировать ваши объекты только при необходимости (когда объект используется). Что касается Linq, Native Queries и SODA, в большинстве случаев вы не должны иметь ощутимой разницы в производительности (наиболее распространенный случай таких различий связан с db4o, не находящими необходимых сборок - такими Mono.Cecil.dll, Db4objects.Db4o.Instrumentation и Cecil .FlowAnalysis). – Vagaus 2010-06-05 16:20:30