高效的MySQL模式,具有对大型数据集进行分区的功能(7.300.000.000行和大约80 GB的数据)
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了高效的MySQL模式,具有对大型数据集进行分区的功能(7.300.000.000行和大约80 GB的数据)，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2070字，纯文字阅读大概需要3分钟。
内容图文
这是我的问题“有效存储7.300.000.000行”(Efficiently storing 7.300.000.000 rows)的后续措施.
我决定将MySQL与分区配合使用,初步架构如下所示：
CREATE TABLE entity_values (
entity_id MEDIUMINT UNSIGNED DEFAULT 0 NOT NULL, # 3 bytes = [0 .. 16.777.215]
date_id SMALLINT UNSIGNED DEFAULT 0 NOT NULL, # 2 bytes = [0 .. 65.535]
value_1 MEDIUMINT UNSIGNED DEFAULT 0 NOT NULL, # 3 bytes = [0 .. 16.777.215]
value_2 MEDIUMINT UNSIGNED DEFAULT 0 NOT NULL, # 3 bytes = [0 .. 16.777.215]
UNIQUE KEY (entity_id, date_id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 PARTITION BY HASH(entity_id) PARTITIONS 25;
这给出：
>行= 7.300.000.000行(根据上一篇文章中所述的要求)
>大小/行= 11字节(3 2 3 3)
>总大小= 7.300.000.000行* 11字节= 80.300.000.000字节= 80.3 GB
>分区= 25(3.2 GB /分区,分区大小有些随意)
请注意,由于不使用“ id”列,因此我从原始设计中删除了主键.
现在,我的问题-鉴于我之前的文章中概述的要求和上面的架构,您对可以进行的进一步优化/调整有什么建议吗？还是鉴于我决定使用MySQL,以上架构是“最佳”的吗？
更新：我尝试将当前数据集加载到上面的架构中,而8.570.532行占用了价值212.000.000字节的磁盘空间,每行大约提供24.7字节.
更新：请注意,包含entity_id date_id的索引也将用于仅以entity_id为目标的查询.
解决方法:
我不太了解的一件事是您打算如何修剪数据.您每天有200万行,但尚未指定要保留多少数据.在某些时候,您将希望按年龄(完全有可能)使数据过期.
在这一点上,您将希望通过删除分区来实现,而不是通过执行删除操作来将每个分区锁定很长时间(因为它必须进行全表扫描以查找要删除的行),而不是执行删除操作由于分区上满是空洞,因此您的桌子不会变小.
按entity_id的散列进行分区对于搜索而言似乎是明智的,但是按时间进行分区可以简化修剪旧数据时的争用,这绝对是一件好事.
MyISAM具有一个称为“并发插入”的功能,您几乎肯定会一直使用它来实现并发和性能.这强制执行“禁止删除”规则,这意味着您只能通过删除分区来进行删除.
但是删除分区也很好,因为您可以收回磁盘空间.
综上所述,80G并没有那么大,我可能很想将它们全部存储在一个表中,并使用InnoDB启用并发访问.
哦,是的,如果您确实使用了InnoDB,则可以有一个主键object_id date_id,这意味着它将以相同的object_id聚集行.您可能希望在date_id上??使用二级索引来启用有效的修剪.
请使用您的生产数据大小对此进行测试,并让我们知道您的发现！
内容总结
以上是互联网集市为您收集整理的高效的MySQL模式,具有对大型数据集进行分区的功能(7.300.000.000行和大约80 GB的数据)全部内容，希望文章能够帮你解决高效的MySQL模式,具有对大型数据集进行分区的功能(7.300.000.000行和大约80 GB的数据)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。