用于大型数据集的sqlite或mysql

Question

我正在处理大型数据集（数以百万计的记录，有时甚至是数百万），并且希望使用与R链接良好的数据库程序。我试图在mysql和sqlite。数据是静态的，但是我需要做很多查询。

在这种link to sqlite help，它指出：

“随着1024个字节的默认页面大小，SQLite数据库的大小限制为2个千兆字节（241个字节），即使它能够处理更大的数据库， SQLite将整个数据库存储在一个单独的磁盘文件中，许多文件系统将文件的最大大小限制为小于这个值，所以如果你正在考虑使用这种数据库，那么你最好考虑使用一个客户/服务器数据库引擎来传播其内容跨多个磁盘文件，也可能跨多个卷。“

我不确定这是什么意思。当我尝试使用mysql和sqlite时，似乎mysql更快，但我还没有构建非常严格的速度测试。我想知道，由于我的数据集的大小，对于我来说mysql是比sqlite更好的选择。上面的描述似乎表明，这可能是这种情况，但我的数据不在2TB附近。

有一个discussion on stackoverflow触及此并引用相同的SQLite信息页面，但它并没有完全解决这个问题。

我很感激任何洞察力来理解文件系统的最大文件大小的这种约束，以及这会如何影响索引表和运行查询的速度。这对我决定使用哪个数据库进行分析确实有帮助。

Answer 1

SQLite数据库引擎将整个数据库存储到一个文件中。这对于难以置信的大文件可能不是很有效（SQLite的限制是2TB，正如你在帮助中找到的那样）。另外，SQLite一次只能限制一个用户。如果你的应用程序是基于web的，或者最终可能是多线程的（比如Android上的AsyncTask），那么mysql可能是最好的选择。

就个人而言，由于您已经完成了测试，而且mysql更快，我只需要使用mysql。未来将会更具可扩展性，并可让您做更多。

Answer 2

SQL如果您主要将其用作Web服务。 SQLite，如果你希望它能够离线工作。

SQLite通常要快得多，因为大部分（或全部）数据/索引将被缓存在内存中。但是，在SQLite的情况下。如果根据我迄今的经验将数据分成多个表，甚至多个SQLite数据库文件。即使有数百万条记录（我还有百万的记录），它比SQL更有效（补偿延迟等）。但是，这是记录在不同表格中拆分时的情况，并且查询是特定于这些表格的（查询所有表格）。

一个例子是在简单游戏中使用的物品数据库。虽然听起来可能听起来不太多，但UID将发布甚至变化。因此，发电机很快就会迅速制定出更多的一百万套具有变化的“统计数据”。然而，这主要是由于每1000组记录被分成不同的表格。 （因为我们主要通过其UID拉取记录）。虽然分裂的表现没有得到适当的衡量。我们得到的查询比SQL快10倍（主要是由于网络延迟）。

虽然有趣，但我们最终将数据库减少到了1000个条目，并且有项目[pre-fix]/[suf-fix]确定变化。 （就像暗黑破坏神，只是它被隐藏起来）。事实证明，在一天结束时会更快。

虽然在一个侧面说明，我的情况主要是由于查询排队一个接一个（等待之前的一个）。但是，如果您能够同时对服务器执行多个连接/查询。 SQL中的性能下降，从您的客户端获得更多补偿。假设这个查询不会相互分支/交互（例如，如果得到的结果是查询这个，否则）

Answer 3

我不确定这是什么意思。当我尝试使用mysql和sqlite时，似乎mysql更快，但我还没有构建非常严格的速度测试。

在短短的版本是：

1. 如果您的应用需要适应一个电话或其他一些嵌入系统上，使用SQLite。这就是它的设计目的。

2. 如果你的应用程序也许需要不止一个并发连接，不使用SQLite。使用PostgreSQL，MySQL的InnoDB的带等

Answer 4

似乎（在R，至少），即SQLite是真棒为特设分析。通过RSQLite或sqldf包，加载数据和开始真的很容易。但对于一次又一次使用的数据，在我看来，MySQL（或SQL Server）是要走的路，因为它在修改数据库方面提供了更多功能（例如添加或更改密钥） 。