Я знаю, что опоздал, чтобы опубликовать здесь ответ, но я хочу убедиться, что никто не сделает ошибку, используя Derby в будущем для любой базы данных производственного качества. Заранее извиняюсь за то, насколько отрицательным является этот ответ - я пытаюсь уловить дурные чувства всей команды инженеров в кратком ответе на вопросы и ответы.
Наш опыт использования Derby во многих небольших клиентских развертываниях заставил нас серьезно усомниться в том, насколько он полезен для чего-либо, кроме тестовых сред. У нас были некоторые проблемы:
- Дедлоки, вызванные эскалацией блокировок - это самая большая проблема, которая случается с одним клиентом примерно раз в неделю или две
- Прерванные операции ввода-вывода приводят к тому, что Derby сразу выходит из строя на Solaris (возможно, это не проблема на других платформах) - нам пришлось создать прокладку для защиты от этих сбоев
- Не может обрабатывать сложные запросы, которые MySQL / PostgreSQL легко обрабатывает
- Ошибка в журнале транзакций привела к повреждению таблицы, что потребовало от нас экспорта базы данных и ее повторного импорта (не удалось просто удалить поврежденную таблицу), и мы все еще потеряли таблицу в процессе - слава богу, у нас была резервное копирование
- Нет
LIMIT Синтаксис
- Низкая производительность для сложных запросов
- Низкая производительность для больших наборов данных
Из-за того, что он встроен, Derby является более конкурентом SQLite, чем PostgreSQL, который является чрезвычайно зрелой базой данных производственного качества, которая используется для хранения многопетабайтных наборов данных некоторыми из крупнейших веб-сайтов в мир. Если вы хотите быть готовыми к росту и не хотите, чтобы вас отлавливали при отладке чужого кода базы данных, я бы рекомендовал не использовать Derby. У меня нет никакого опыта работы с SQLite, но я не могу себе представить, что он гораздо менее надежен, чем Дерби, для нас, и все еще так же популярен, как и он.
Фактически, мы сейчас находимся в процессе портирования на PostgreSQL.