只有Mysql OR mysql+sqlite OR mysql+自己的解决方案答案

【问题标题】：Only Mysql OR mysql+sqlite OR mysql+own solution只有Mysql OR mysql+sqlite OR mysql+自己的解决方案
【发布时间】：2012-01-27 00:41:18
【问题描述】：

目前我正在构建相当大的网络系统，我需要强大的 SQL 数据库解决方案。我选择了 Mysql 而不是 Postgres，因为一些任务需要是只读的（MyISAM 引擎），而另一些需要大量写入（InnoDB）。

我对此只读功能有疑问。它必须非常快。用户必须在不到一秒的时间内得到答案。假设我们有一个索引良好的表，名为“object”，行数不超过 1000 万行，另一个名为“element”，行数约为 1.5 亿行。我们还有名为“element_object”的表，其中包含将表“element”与表“object”中的对象连接起来的信息（数亿行）

所以我们要对表“element”和“element_object”进行分区，并有 8192 个表“element_hash_n{0..8191}a”和 24576 个表“element_object_hash_n{0..8191}_m{0..2}”。

用户问题的答案是两步搜索：

从表“element_hash_n”中查找元素的 ID
在表“object”上执行主 sql 选择并与表“element_object..hash_n_m”连接以过滤具有找到（来自第一步）ID 的结果

我想知道第一步：有什么更好的：

在 mysql 中存储（全部）超过 32k 表
创建一个 sqlite 数据库并在其中存储 8192 个表以供第一步使用
创建 8192 个不同的 sqlite 文件（数据库）
在文件系统中创建8192个文件，并制作自己的二进制解决方案来查找ID。

对不起我的英语。它不是我的母语。

【问题讨论】：

为什么你认为拥有数千张桌子比只有 3 张桌子更好？
我认为分区优于 3 个表，因为表比可用 RAM 大得多。当然有一个问题应该是多少张桌子。
您为什么认为数据库必须同时在内存中保存一个完整的表（或者——也许更相关地——一个完整的索引）？那将是……限制……
嗯，分区在 postgresql 中很重要。请看这里postgresql.org/docs/9.1/static/ddl-partitioning.html

标签： mysql sqlite store myisam

【解决方案1】：

我认为您为许多分区让路。如果您有超过 32000 个分区，那么您的管理开销就会很大。给定名称 element_hash_* 它看起来好像您想对元素进行哈希并以这种方式对其进行分区。但是哈希会给你一个（最有可能的）数据在所有分区上的均匀分布。我看不出这应该如何提高性能。如果您的数据是通过所有这些分区访问的，那么您不会因为分区的内存大小而获得任何收益 - 您将需要从另一个分区加载每个查询数据。

我们在事务系统上使用分区，其中超过 90% 的查询使用当天作为标准。在这种情况下，基于天数的分区效果很好。但是我们只有 8 个分区，然后将数据移到另一个数据库进行长时间存储。

我的建议：尝试快速找出需要哪些数据，然后尝试将它们组合在一起。您需要进行自己的性能测试。如果快速交付数据如此重要，那么应该有足够的管理支持来构建一个体面的测试环境。也许您的测试结果会表明您根本无法使用关系数据库系统以足够快的速度交付数据。如果是这样，您应该查看 NoSQL（如 Not only SQL）解决方案。

您使用什么技术构建您的网络系统？你也应该测试这部分。如果您在性能不佳的 Web 应用程序上浪费时间，那么超快速的数据库对您没有多大帮助。

【讨论】：