Derby 或 MySQL 或...？答案

【问题标题】：Derby or MySQL or...?Derby 或 MySQL 或...？
【发布时间】：2011-06-25 22:11:47
【问题描述】：

对于什么类型的需求，您会选择 Apache Derby（或 Java DB）而不是 MySQL（反之亦然）？我环顾四周，人们只是比较两者，但没有人谈论何时考虑每一个。我正在使用 Glassfish + Java/Restlet + MySQL 开发一个基于 Web 的应用程序。

我预计该系统大约有 100-200 个用户，在给定时间大约有 30-50 个并发用户负载 - 大部分。

如果我想让网络应用程序可下载/可分发，我被告知要查看 Derby。但这是我使用它的唯一原因吗？它适用于网络应用程序吗？有人用过吗？你的经历是什么？你什么时候选择一个而不是另一个？（大多数关于比较的讨论早于 MySQL v5，当时它不支持存储过程、触发器等，但现在情况已不再如此。

我可以理解带有发送请求的网络服务器的独立数据库服务器模型，但是这个模型如何随着嵌入式数据库而改变？还是在网络配置中默认使用 Derby？

【问题讨论】：

根据经验：如果您的应用程序足够小，可以将整个系统包含到一台服务器/机器上：您可以使用其中任何一种，但嵌入式数据库可以让最终用户更轻松地分发您的应用程序.另一方面，如果您或您的用户可能需要将应用程序扩展到一台服务器之外，那么嵌入式不是正确的选择。话虽这么说，这个问题是题外话。

标签： mysql derby

【解决方案1】：

将产生影响的需求是所谓的“非功能性”需求：容量、可靠性、吞吐量（和响应时间）、可用性和安全性；这与软件自身的问题一起出现，例如它的易用性、维护基于它的软件的难度等等。

Oracle 非常快、非常健壮、得到很好的支持并且非常昂贵。

MySQL 是一个很好的通用选择，被广泛使用。它可以配置为高可用性和可靠性（通过镜像和主从），它被很多程序员很好地理解，并且很好地集成了很多平台软件，如 Grails、Rails 和 JBoss。

Derby 很好，因为它非常独立于平台，而且很多人很容易阅读 Java。

SQLite 快速、轻量级，并且或多或少是 Mac 上的原生。

...等等。

首先，弄清楚哪些非功能性需求是重要的，然后选择 DBMS。

更新

好的，跟进您的评论。

有了这些数字，让我先问一下，为什么要使用单独的 RDBMS？那是 1000 行 - 考虑将它们简单地存储在内存中，例如在您序列化的 Collections 集合中。

如果您真的需要数据库，比如说因为您使用的是 Rails，那么您就不会挑战任何 RDBMS —— 可能很难选择，因为您所在的域 all选择非常好。如果是这样，那就选择最容易使用和最容易支持的那个，可能但不一定是 MySQL，因为每个人都在使用它。

【讨论】：

同意。这就是我想知道的——对于哪种类型的 NFR，人们会选择 MySQL 而不是 Derby（反之亦然）。哪里是 Derby（或 MySQL）步履蹒跚，会迫使我为给定的场景和给定的约束做出选择 -> 最多 20 个表，每个表可以增长到 50 个条目，跨团队轻松且一致，“好”可靠性，中等响应时间是可以接受的（3-10 秒就可以了：），中等可用性（内网应用）
对不起。似乎我不清楚 - 数据是相关的，我有大约 15 个表，每个表预计会增加到 1000 行，并且会在一段时间内单调增加（每年？）。以前的数据需要作为历史记录来维护。简单的序列化不太适合这项任务——它只是关系方面和延迟加载的噩梦。我应该将我的问题重新表述为“将 Derby 用于（Intranet）企业应用程序时有哪些限制？”而不是 MySQL vs Derby

【解决方案2】：

为什么 Derby 和 MySQL 是您考虑的唯一 RDMBS？如果你说 Derby，你也应该看看 HSQLDB、H2、SQLite。如果你说 MySQL，你也应该看看 Postgres（它有更多的功能）。

这只是命名一些免费的 RDBMS。当然，正如查理已经说过的那样，还有很多其他的，也有很多理由去采取任何一种方式。查看 Wikipedia 上的这个（IMO 优秀）比较页面，您可以在其中找到任何 RDBMS 的优点和限制：

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

就您的 web 应用“可下载”的要求而言，您当然可以在 web 应用中嵌入 RDBMS（Derby、H2、HSQLDB 中的任何一种）。但你也可以让你的 MySQL 或 Postgres 或任何集成可配置，并为你的下载者提供有关如何自己设置 webapp 的说明。毕竟，当您为您的 webapp 使用容器配置的 DataSource 时，可以轻松完成此配置。

现在，即使您认为使用嵌入式数据库开发 Web 应用程序可能会更容易，您也应该始终提前考虑一步。像这样的问题：

您能否直接连接到该数据库，以便轻松更正数据不一致？（这会发生在我们所有人身上）
您能否轻松更改架构？
您能否轻松备份数据？
等等等等……还有更多维护问题

由于您的 cmets 建议您的数据随着时间的推移而增加，并且应该持续存在，因此我不会选择嵌入式版本，而是将数据与应用程序分开。请注意，这并不会将 Derby 从您的应用程序设计中排除。这只是意味着您必须将 Derby 作为独立服务器运行。

【讨论】：

太棒了！正是我正在寻找的信息。是的，我确实查看了维基百科页面，因此标题中的省略号 :) 自从发布问题后，这些担忧确实打击了我，我们决定暂时使用 MySQL，并提供“一个”基于嵌入式数据库的解决方案来下载和评估该工具可以在需要时切换到 MySQL。
听起来是个不错的解决方案。祝你好运！ :-)
恕我直言，我不同意这个答案。你可以让你的用户设置一个 MySQL 数据库，而不需要对它的工作原理有一些非常具体的基本了解，这种想法是愚蠢的。对于像你我这样的人来说这并不难，但对于普通用户来说——来吧。此外，鉴于提供的详细信息，您认为不断增长的数据和持久性需要像 MySQL 这样的企业级数据库解决方案的假设有点不公平。最后，这确实是一个关于嵌入式数据库与可扩展的客户端-服务器模型的问题。建议其他 RDBMS 对答案没有建设性。
@TomDworzanski：嗯，我不太确定“网络应用”在当时是什么意思。 OP没有说这将是什么样的用户。此外，您可以将一些可安装的数据库与您的交付物一起提供并自行安装（例如 Oracle XE、SQL Server Express 等），而无需真正“嵌入”。我们也许可以同意这个问题并不是很有意义
@Frankie：您的基准测试似乎证实 Derby 比 HSQLDB 慢得多。当然，这些基准测试结果似乎存在很大缺陷。在一项测试中，Hibernate/HSQLDB 的性能大大优于 JDBC/HSQLDB，而且 MongoDB 绝不会那么快得多……但无论如何。我已经删除了一个比另一个快的说法，因为我无法用数据支持这一点