使用MySQL处理大型数据集

我正在尝试申请一项工作,该工作要求使用关系数据库(如mySQL)处理大规模数据集的经验.

我想知道使用MySQL处理大规模数据需要哪些特定的技能.

使用MySQL处理大规模数据不仅仅是一组特定的技能,因为有大量的方法可以处理大型数据集.一些基本的事情要理解:

列索引,它们的使用方式,原因和时间,以及使用它们的优缺点.

良好的数据库结构,可在快速写入和轻松读取之间取

缓存,利用多层缓存和不同的缓存技术(memcached,redis等)

检查MySQL查询以识别瓶颈并理解MySQL内部,以查看数据库服务器如何计划查询以提高查询性能

配置MySQL服务器以便能够处理大量并发连接,并快速访问它的数据.硬件瓶颈,以及使用不同技术加速硬件的优势(例如,将MySQL数据存储在RAID5阵列上以提高IO性能))

利用内置的MySQL技术(如复制)来卸载读取流量

这些只是关于MySQL中大数据的一些考虑因素.还有一个TON,这就是为什么公司正在寻找该地区的经验.知道该做什么,或者对已经工作或失败的事物有经验,这对于为处理高流量,高可用性和高容量服务的公司带来绝对宝贵的资产.

编辑
如果我没有提供更多信息的来源,我将是remis.查看高性能MySQL.这是一本令人难以置信的书,并且有很多关于如何在所有场景中使MySQL运行的信息.绝对物有所值,以及阅读时间.

编辑 - 平衡写入和读取的良好结构关于
这一点,我指的是规范化/反规范化的主题.如果您熟悉数据库设计,您就会知道规范化是数据的分离,以减少(消除)您对任何单个记录的重复数据量.这通常是一个奇妙的想法,因为它使表更小,查询更快,更容易索引(单独)并减少为创建/更新新记录必须执行的写入次数.

有不同程度的标准化(正如@Adam Robinson在下面的评论中指出的那样)被称为正常形式.几乎我使用的每个Web应用程序都没有超出3NF(第3范式)的好处.如果您阅读上面的维基百科链接,其中的定义可能会让您头疼.因此,在拉门管中(冒着将其拖得太远的风险......)3NF结构满足以下规则:

同一个表中没有重复的列.

为每个集合相关数据创建不同的表.(示例:包含Companies公司列表的Employees表格,以及包含每个公司员工列表的表格)

没有适用于表中多行的列子集.(实施例:zip_code,state,和city的一个子集,其可以唯一地识别数据的zip_code这些3列可以放在它们自己的表,并参照由.Employees由表(在前面的示例中)zip_code).这消除了表中的大量重复,因此对于任何邮政编码,城市/州所需的任何更改都是单个写操作,而不是对于居住在该邮政编码中的每个员工的1次写操作.

每个数据子集都移动到它自己的表中,并由它自己的主键标识(在#3的例子中触及/解释).

删除不完全依赖主键的列.(这里有一个例子可能是,如果你的Employees表有start_date,end_date和years_employed列.的start_date和end_date是既独特又依赖于任何单个员工行,但years_employed可以通过减去衍生start_date自end_date这很重要,因为结束日期的增加,所以确实years_employed如此如果您要更新,end_date您还必须更新years_employed(2次写入而不是1次)

如果你有很大的写入负载,那么完全规范化的(3NF)数据库表结构很棒.如果您的服务器正在进行大量写操作,那么编写少量数据非常容易,尤其是当您运行较少的数据时.缺点是,所有读取都变得更加昂贵,因为JOIN当您将数据拉出时,您必须(通常)运行大量查询. JOIN当您使用WHERE跨越关系的子句以及对结果集进行排序时,s通常很昂贵且难以创建适当的索引如果必须对SELECT数据集执行大量读取,则使用3NF结构可能会导致一些性能问题.这是因为随着您的表的增长,您要求MySQL将越来越多的表数据(和索引)塞入内存.理想情况下,这就是你想要的,但是对于大数据集,你只是没有足够的内存来同时适应所有这些.这是MySQL开始创建临时表时,必须使用磁盘加载数据并对其进行操作.一旦MySQL变得依赖硬盘来提供查询结果,您将看到显着的性能下降.这与固态磁盘的情况相差不大,但是它们非常昂贵,并且(imo)还不够成熟,无法在关键任务数据集上使用(我的意思是,除非你已经准备好让它们失败并拥有一个非常快速的备份恢复系统...然后使用它们和gonuts!).

这是平衡部分.您必须决定您正在读/写的数据将为更多服务提供哪种流量,并将其设计为快速.在某些情况下,人们不介意写入速度慢,因为它们发生频率较低.在其他情况下,写入必须非常快,并且读取不必非常快,因为不经常(或者根本或甚至实时)访问数据.

需要大量读取的工作负载从中间层缓存层中受益最多.这个想法是你的写入速度仍然很快(因为你是'正常的')并且你的读取速度很慢,因为你要缓存它(在memcached中或者与它竞争的东西),所以你没有命中数据库非常频繁.这里的缺点是,如果您的缓存快速失效,那么缓存不会将读取负载减少一个有意义的数量,并且不会导致额外的性能(可能甚至会增加检查/使缓存无效的开销).

对于需要在写入时具有高吞吐量的工作负载,以及经常读取且无法缓存(不断更改)的数据,您必须提出另一种策略.这可能意味着您开始对表进行去规范化,方法是删除您选择满足的一些规范化要求或其他要求.您可以使用更多重复/冗余数据制作更大的表,而不是使用较少重复数据的较小表.这里的优点是您的数据都在同一个表中,因此您不必执行尽可能多的(或任何)JOIN数据来提取数据.缺点...写入更昂贵,因为你必须在多个地方写.

因此,在任何给定情况下,开发人员必须确定数据结构将要服务的用途,并在任意数量的技术和范例之间进行平衡,以实现满足其需求的可接受解决方案.没有两个系统或解决方案是相同的,这就是为什么雇主正在寻找具有如何处理这些大型数据集的经验的人.找到这些解决方案并不是真正可以从书中学到的东西,它通常需要在该领域的一些经验和经验与不同的解决方案如何执行.

我希望有所帮助.我知道我有点絮絮叨叨,但这确实是很多信息.这就是DBA赚大钱的原因(: