mysql - 使用MySQL处理大型数据集

Question

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

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

Answer 1

使用MySQL处理大规模数据不仅仅是一组特定的技能，因为有无数种处理大型数据集的方法。需要了解的一些基本知识:

Column Indexes，使用方式，原因和时间，以及使用它们的利弊。

良好的数据库结构，可在快速写入和轻松读取之间取得平衡。

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

检查MySQL查询以识别瓶颈，并了解MySQL内部结构，以了解如何计划查询并由数据库服务器执行以提高查询性能

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

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

这些只是有关MySQL中大数据的一些考虑事项。还有更多，这就是为什么该公司正在寻找该地区的经验。知道该怎么做，或者对已经成功或失败的事情有经验，这绝对是将宝贵的资产带给处理高流量，高可用性和高容量服务的公司的。

编辑
如果我不提及更多信息的来源，那我将是remis。 checkout High Performance MySQL。这是一本令人难以置信的书，并且提供了大量有关如何使MySQL在所有情况下均能执行的信息。绝对值得花这笔钱，以及花在阅读上面的时间。

编辑-平衡读写的良好结构

关于这一点，我指的是规范化/非规范化的主题。如果您熟悉数据库设计，那么您就会知道标准化是数据的分离，以减少(消除)关于任何一条记录的重复数据量。这通常是一个很棒的主意，因为它使表更小，查询更快，更易于索引(单独)并减少了创建/更新新记录所需的写入次数。

有不同级别的规范化(如@Adam Robinson在下面的注释中指出的)，称为 normal forms。除了3NF(第三范式)之外，几乎与我合作的每个Web应用程序都没有太多好处。如果您要阅读上面的Wikipedia链接，其中的定义可能会使您的头部受伤。因此，在拉曼纤维中(有将其弄得太深的危险...)，3NF结构满足以下规则:

同一表中没有重复的列。

为每个集合相关数据创建不同的表。 (示例:一个包含公司列表的Companies表和一个包含每个公司雇员的列表的Employees表)

没有适用于表中多行的列子集。 (示例:zip_code，state和city是可以由zip_code唯一标识的数据子集。这3列可以放在自己的表中，并由Employees由zip_code表(在前面的示例中)引用)。这消除了表内的大量重复，因此任何邮政编码对城市/州所做的任何更改都是一次写入操作，而不是为居住在该邮政编码中的每位员工进行一次写入操作。

每个数据子集都移到其自己的表中，并由其自己的主键标识(在＃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子句以及对结果集进行排序时，创建适当的索引通常比较困难。如果必须对数据集执行大量读取操作( SELECT s)，请使用3NF结构可能会导致一些性能问题。这是因为随着表的增长，您正在要求MySQL将越来越多的表数据(和索引)填充到内存中。理想情况下，这就是您想要的，但是对于大数据集，您将只是没有足够的内存来一次容纳所有这些。这是MySQL开始创建临时表并必须使用磁盘加载数据并对其进行操作的时候。一旦MySQL依靠硬盘提供查询结果，您将看到性能显着下降。这种情况较少-固态磁盘的情况如此，但是它们非常昂贵，并且(imo)还不够成熟，无法在关键任务数据集上使用(我的意思是，除非您准备让它们失败并有一个问题，非常快速的备份恢复系统...然后使用它们和甜甜圈!)。

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

需要大量读取的工作负载从中间层缓存层中受益最大。这个想法是您的写入仍然很快(因为您是“正常”)，并且读取可能会很慢，因为您将要对其进行缓存(以memcached或与其竞争的某种方式)，因此您不必访问数据库非常频繁。此处的缺点是，如果您的缓存快速失效，则缓存不会将读取负载降低有意义的数量，并且不会导致性能提升(检查缓存或使缓存无效的开销可能更大)。

对于需要高吞吐量写入的工作负载，需要频繁读取且无法缓存(不断更改)的数据，您必须提出另一种策略。这可能意味着您将通过删除选择满足的某些规范化要求或其他方法开始对表进行非规范化。您可以使用较大的重复/冗余数据来制作较大的表，而不是使用较小的重复数据来创建较小的表。这样做的好处是您的数据都在同一个表中，因此您无需执行那么多(或任何) JOIN即可提取数据。缺点是...写入更加昂贵，因为您必须在多个位置进行写入。

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

希望对您有所帮助。我知道我徘徊了一点，但这确实是很多信息。这就是DBA赚大钱的原因(: