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

Question

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

我对此只读功能有疑问。它必须非常快速。用户必须得到答案的时间少于一秒。 假设我们有一个名为“object”的索引良好的表格，其行数不超过1000万行，另一个名为“element”的行大约有150百万行。 我们也有一个名为“element_object”包含的信息从连接表“element”对象与表“object”（亿万行）

所以，我们要做的表上“element”分区和表“element_object “并且具有8192个表”element_hash_n{0..8191}a“和表”element_object_hash_n{0..8191}_m{0..2}“的24576个表。

用户的问题的答案将是一个2步搜索：从表元素的

1. 查找ID“element_hash_n”
2. 做主要SQL SELECT对表“对象”，并与表加入“element_object ..hash_n_m”过滤与搜寻（来自第一步）ID

我想知道第一步结果： 什么会更好：

1. 店（全部）超过32K表中的MySQL
2. 创建一个SQLite数据库和存储有8192台的第一步目的
3. 创造8192个不同的sqlite的文件（数据库）
4. 在文件系统中创建8192个文件，并自己的二进制解决方案来查找ID

我很抱歉我的英语。它不是我的母语。

Answer 1

我认为你让路给很多分区。如果你有超过32000个分区，你的管理开销会很大。鉴于名称element_hash_ *，它会像接下来一样对您的元素进行散列并对其进行分区。但散列会给你（最有可能）在所有分区上的数据均匀分布。我看不出这应该如何提高性能。如果你的数据是通过所有这些分区进行访问的，那么通过将分区大小分配给内存不会获得任何收益 - 你需要为来自另一个分区的每个查询数据加载。

我们在事务系统中使用了分区，其中超过90％的查询使用当前日期作为条件。在这种情况下，基于日期的分区工作得很好。但我们只有8个分区，然后将数据移到另一个数据库进行长时间存储。

我的建议：尝试找出需要哪些数据，然后尝试将它们组合在一起。你需要进行自己的性能测试。如果提供数据的速度非常重要，那么应该有足够的管理支持来构建体面的测试环境。 也许你的测试结果会显示你无法用关系数据库系统快速传递数据。如果是这样，你应该看看NoSQL（不仅仅是SQL）解决方案。

在你建立了什么技术，让您的网络系统？你也应该测试这个部分。如果你在一个表现不佳的Web应用程序失去的时候一个超快速的数据库不会帮助你多少。