数据库与fstream访问

Question

我有一个（本地）数据库（Ubuntu 10.10的MySQL 5.1），每个表有大约15000个表，平均行数约为1 000 000。每个表有6个DOUBLE列。存储引擎是MyISAM。我有一个C ++应用程序，一次加载一个表并执行一些计算。 我从数据库中检索数据的方法很简单：SELECT * FROM table ORDER BY timestamp; （timestamp是标记为UNIQUE的第一列（DOUBLE）） 到目前为止，大部分时间都用于加载和获取。加载和获取一个表中的所有行需要大约15秒（使用本机C API，C ++连接器和MySQL查询浏览器进行尝试）。 当我使用fstream从磁盘（纯文本文件）加载相同的数据集时，相同的操作只需要约4秒。

MySQL或任何其他数据库（SQLite？）是否可以获得接近此值的任何值？ 虽然，我有大多数简单的SELECTS和INSERTS（+一个简单的JOIN）我喜欢数据库的想法，因为它管理大型数据集要容易一些，所以即使以一些性能损失为代价，我也会坚持使用它，但15 / 4s考虑到表的数量，每个表太多了。虽然我很喜欢6 / 4s ......

感谢。 彼得

Answer 1

读取文件与使用SQL获取数据不同。只读取文件涉及从磁盘读取并将其放入内存。多数民众赞成。

现在，使用SQL来获取结构化数据，现在有所不同了。首先，MySQL必须解析查询并对其进行构造，以便它可以执行它并读取数据。执行查询时，MySQL打开数据库文件并读取与该数据库相关的一些元数据。

然后，完成后，它会解析文件并根据查询获取数据。还有一个很小的开销，因为客户端和服务器之间的通信是通过。套接字。

因此，文件访问与MySQL的作用之间存在巨大差异。使用MySQL，你会得到更多，更多，但代价是速度。

为什么你还需要15000张桌子？如果你需要这么多桌子，我会感觉你的设计存在缺陷......

Answer 2

所有记录的顺序扫描并不是关系数据库最有说服力的用例，但我绝对鼓励您对SQLite进行基准测试。它通常被认为是自定义文件I / O的高性能替代品。

Answer 3

如果性能是绝对值得关注的，您还可以尝试使用mmap。这允许您拥有磁盘支持的内存区域，利用非常优化的虚拟内存和缓存代码。

我见过一个应用程序（用于一个主要的社交网站），为了一个非常具体的需求，用一个刀片上运行的优化C ++代码替换了8个大型MySQL服务器集群，利用率约为5-10％ 。 （它计算了社交图和用户之间的最短路径）。

通常，您最终会为广义解决方案付费。仔细分析您的需求，应用算法知识，然后选择您的武器.. 许多设计师错误地选择他们所知道的东西，然后尝试将算法融入其中，最后照顾到需求。

Answer 4

首先，你通过拥有15,000个表来极其糟糕地淘汰数据库。这不是这些数据库的工作方式。

其次，任何客户端 - 服务器数据库都可能需要在内存中进行多次复制操作，即使数据已经在内存中，也会对速度施加上限。像sqlite这样的东西可以通过直接从缓冲区使用数据来避免（某些）这些副本。

您正在使用SQL数据库来处理它不适合的事情 - 并且滥用它。我不希望它做得很好。