Mysql一个大数据库或小许多表

Question

我们的应用程序将为每个用户创建动态表单。

我们正在考虑两种方法

a）我们将所有用户表单数据存储在单个表中作为键值对，然后使用数据透视表技术获取数据并进行过滤，但我觉得可能真的是巨大的资源消耗

b）为每个表单用户创建适合其设计的创建/设计表，这里我们没有必须转向，我们获得了mysql的所有好处，而且我们不会有多个表的连接

我们主要关注的是可伸缩性，在场景'a'中，如果表增长非常大（如果我考虑甚至1000个用户注册，这显然会发生），计划'b'如果明天我们的表随着它增长我们的流量我们可能必须使用mysql集群，但集群有表限制，因为我在这里阅读http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-limitations-database-objects.html

更新

一个新的想法让我们感到震惊，为什么不创建一个适合单个表单元素（文本字段，文本区域等）的单个表（作为键，值），使用基于由表创建的表单定义的连接（连接数=字段数）用户我们可以创建一个水平数据，而无需调整您对这个想法的所有想法。

2011年4月9日更新

我们测试了针对连接的转向

场景 - 我们有一个包含7个字段的表单，数据存储为（单个表单插入的示例数据）

------------------------------
|   Key       |    Value     |
------------------------------
|   Key1      |    Value1    |
|   Key2      |    Value2    |
|   Key3      |    Value3    |
|   Key4      |    Value4    |
|   Key5      |    Value5    |
|   Key6      |    Value6    |
|   Key7      |    Value7    |
------------------------------

对于数据透视查询，需要0.92秒将70000行转换为10000个表单插入对于连接，需要17.63秒（woof .....）来显示这些10000个表单插入

我的桌子

CREATE TABLE IF NOT EXISTS `vet` (
  `id` int(11) NOT NULL,
  `form_id` int(11) NOT NULL,
  `key` varchar(255) NOT NULL,
  `value` varchar(255) NOT NULL,
  KEY `id` (`id`),
  KEY `form_id` (`form_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

透视查询

SELECT id, 
       GROUP_CONCAT(if(`key` = 'k1', value, NULL)) as 'key1',
       GROUP_CONCAT(if(`key` = 'k2', value, NULL)) as 'key2',
       GROUP_CONCAT(if(`key` = 'k3', value, NULL)) as 'key3',
       GROUP_CONCAT(if(`key` = 'k4', value, NULL)) as 'key4',
       GROUP_CONCAT(if(`key` = 'k5', value, NULL)) as 'key5',
       GROUP_CONCAT(if(`key` = 'k6', value, NULL)) as 'key6',
       GROUP_CONCAT(if(`key` = 'k7', value, NULL)) as 'key7'
FROM vet
WHERE form_id = 2
GROUP BY id

加入查询

SELECT v.id, v1.value as key1, v2.value as key2, v3.value as key3, 
       v4.value as key4, v5.value as key5, v6.value as key6, v7.value as key7
FROM vet v
LEFT JOIN vet v1 ON v1.id = v.id AND v1.`key` = "k1"
LEFT JOIN vet v2 ON v2.id = v.id AND v2.`key` = "k2"
LEFT JOIN vet v3 ON v3.id = v.id AND v3.`key` = "k3"
LEFT JOIN vet v4 ON v4.id = v.id AND v4.`key` = "k4"
LEFT JOIN vet v5 ON v5.id = v.id AND v5.`key` = "k5"
LEFT JOIN vet v6 ON v6.id = v.id AND v6.`key` = "k6"
LEFT JOIN vet v7 ON v7.id = v.id AND v7.`key` = "k7"
WHERE v.form_id = 2
GROUP BY v.id

我认为我们现在会坚持转向，如果由于它们的巨大差异，也请查看我的疑问。

请建议哪种解决方案更好或是否有更好的解决方案

SUDESH

Answer 1

我建议使用一个数据库来设计它。 然后，您总是可以在需要时使用分片进行水平缩放。

Answer 2

您不希望为用户创建的每个表单创建新表。
但是，您也不希望将所有数据存储在一个大表中。
最好将东西存放在几张桌子中，这样你就不会重复这些东西了。

首先是一个包含用户数据的表：

Table user
id: integer autoincrement primary key
username: varchar(255)
other user data

Then a table that links the user to the form data (but does not actually hold any form data

Table UserForm
id: integer autoincrement primary key
user_id: integer index
... other fields for fixed data that always occurs only once in each form. Then the table with the Form data
Table FormProperties
id: integer autoincrement primary key
UserForm_id: integer index
PropertyName: varchar(255)
PropertyValue: varchar(255) Now when you want to access data from a form you use a query like

Table UserForm
id: integer autoincrement primary key
user_id: integer index
... other fields for fixed data that always occurs only once in each form. Then the table with the Form data
Table FormProperties
id: integer autoincrement primary key
UserForm_id: integer index
PropertyName: varchar(255)
PropertyValue: varchar(255) Now when you want to access data from a form you use a query like

Table UserForm
id: integer autoincrement primary key
user_id: integer index
... other fields for fixed data that always occurs only once in each form. Then the table with the Form data
Table FormProperties
id: integer autoincrement primary key
UserForm_id: integer index
PropertyName: varchar(255)
PropertyValue: varchar(255) Now when you want to access data from a form you use a query like

 select * from FormProperties inner join UserForm on (FormProperties.UserForm_id = UserForm.id) inner join User on (UserForm.User_id = user.id) where UserForm.id = 103 

这样您就不会存储冗余数据。 请注意，如果您永远不需要唯一访问单个属性，则可以删除属性表上的唯一ID。

并且不用担心MySQL集群，只需从带有MySAM表的vanilla MySQL（5.x）开始，如果这还不够快，那么你可以开始考虑技巧，但是我不会打扰一百万以下的记录。

Answer 3

有很多小型数据库的问题很清楚： - 当索引和表很小时，磁盘和内存的使用效率低 - 当#databases> 100和#tables> 10000 - 管理/管理噩梦时，mysql服务器的扩展性很差但是有些优点： - 隔离客户提供更好的安全性 - 转储/加载/锁定/更改单个客户的表而不影响其他人 - 更容易管理多个版本和自定义架构添加

有一个大型数据库，有分片，听起来不错但有缺点： - 所有客户都被锁定在同一架构中，必须同时进行升级 - 个别客户的安全性差 - 需要修改代码来管理分片 - 非常困难一旦它们建立就改变分片 - “坏邻居”效应：一个过度活跃的客户影响分片中邻居的SLA主要优点是它可以很好地扩展。

完全披露：我在ParElastic工作。 但我真诚地相信，我们拥有虚拟多租户数据库这个问题的唯一真正完整的解决方案： - 每个客户都可以看到他们自己的数据库的完整，独立的实例 - 他们的数据库独立的管理命令 - 封面可扩展的分片在用户之间和内部分发数据 - 每个客户架构管理支持滚动升级和自定义扩展 - 使用普通SQL的安全，跨客户查询

如果您有兴趣，可以在https://aws.amazon.com/marketplace (搜索“parelastic”）免费下载预先打包的ParElastic环境。 或者查看http://parelastic.com 。