优化数据库工作答案

【问题标题】：Optimization of the work with the database优化数据库工作
【发布时间】：2013-09-26 04:10:21
【问题描述】：

有一个足够大的商品数据库并在稳步增加。现在数据库中有超过1000万件商品。

有一个好，有它的类别。每种商品都具有以下属性：名称、价格、售出商品数量、保证标志和质量等。产品的特征仅针对特定类别。货物的属性具有下一个格式 - 2000:10000（属性类别：属性值）。某些类别的属性和属性本身可能在各种类别中重叠，例如品牌。标题和属性的过滤、排序和搜索由这些类别和属性执行。产品可以链接到一个或多个类别。

起初我们只使用mysql，并通过为每个类别创建一个表来存储商品。这样，我们就有了大约 6-7 千张带商品的桌子。在选择时，我们向他们每个人提出请求，在操作员 UNION 的帮助下合并请求。随着商品数量和类别的增加，选择开始花费很长时间，并且铺设了mysql服务器。在此之后，我们将所有产品移动到一个表中。表结构如下[follows](http://clip2net.com/s/5OUKXm.

1000万个产品的表，让mysql现在很难用了。从中选择是不太可能的，不谈论排序。我们使用了狮身人面像，索引狮身人面像：

sql_query = SELECT \
ti.item_id, \
ti.item_id AS iid, \
crc32(ti.item_nick) AS nick, \
ti.item_title AS title, \
ti.item_sold AS sold, \
ti.item_rating AS rating, \
ti.item_popular AS popular, \
ti.item_warranty AS warranty, \
ROUND(ti.item_price*100, 0) AS price, \
ti.item_props AS props, \
COUNT(c.comment_iid) AS comments, \
GROUP_CONCAT(tcir.category_item_ref_tid) AS tids \
FROM item AS ti \
LEFT JOIN comment AS c ON ti.item_id = c.comment_iid \
INNER JOIN category_item_ref AS tcir ON ti.item_id = tcir.category_item_ref_iid \
WHERE ti.item_id >= $start AND ti.item_id <= $end \
GROUP BY ti.item_id

sql_attr_uint = sold
sql_attr_uint = rating
sql_attr_uint = comments
sql_attr_uint = warranty
sql_attr_bigint = iid
sql_attr_bigint = nick
sql_attr_bigint = price
sql_attr_bigint = popular
sql_attr_multi = uint tids from field;

通过 Sphinx 搜索更快，但有许多属性，特别是 sql_attr_multi tids 会减慢搜索和排序。 60万件商品的采样时间约为18~19秒。我们试图将产品仅与一个类别联系起来（属性 tids 变为 sql_attr_uint）。采样时间减少到3~5秒，也不是很好。

你能告诉我我做错了什么吗，以另一种方式为狮身人面像建立索引可能是值得的，因为我认为它应该工作得更快。也许，我需要用另一种方式构建表结构，或者使用不同的数据库平台，例如 MySQL、MongoDB、PostgreSQL、MariaDB。

【问题讨论】：

标签： mysql database postgresql optimization

【解决方案1】：

您与许多其他遇到大型数据集的公司一样面临问题。您很幸运，因为您的用例似乎阅读量很大，但写作量很小，因为这两个问题一起变得更糟:-) 重要的是要了解，数据库系统只不过是允许索引和锁定以及优化快速搜索（在数据和索引中）的虚拟化文件系统。

没有理由使用适当的查询来快速处理表中近 1000 万个项目。但是您需要优化系统和查询。什么意思？

您说要支持对某一类别的商品进行快速排序。应该怎么设计？

假设有 1000 万个项目，10k 个类别，所以每个类别都有 100 个好项目
按值排序在一个类别中意味着存在重复的数据，包括类别和价格，以排序方式 - 以索引的形式，包括类别 id 和价格值
以适当的方式执行查询只需使用此索引。首先，它搜索快速的类别，因为它是使用某种索引形式的哈希表来表示的 - 说到 10m 行的索引可能会在一次提取中被读取，例如MS SQL 在硬盘（驱动器）读取中缓存 512kb。在索引中找到所需的类别后，您对 100 个项目进行了排序，因此您获得了需要在驱动器上找到的物理行 ID 的集合。最后一步是物理读取 100 个数据库行 id 他们的 id，即使在随机选择的标识符中也可能需要几毫秒。

我写这一部分是为了表明，即使是一个大型数据库表也可以快速处理您的查询，但您需要调整查询并提供特定的适当索引。

你应该尝试经典的方法：

编写用例 - 我想在我的系统中优化哪些最重要的查询？
接受这些查询并优化您的表和索引

在我看来，没有必要在更多表中切割数据，您应该使用上述方法消除查询需要搜索的数据量 - 只需使用正确的索引。

您提到了表格的连接。大数据的操作可能会很长，所以流行的系统是复制数据，只提供一个表（最快的方法）从其他表中搜索重复数据。明显的问题是更新此数据，因为您需要以原子方式更新两个表。一旦您谈到只读，这对您来说似乎不是一个真正的问题 - 您可以在更新原始数据时更新重复数据。

还有其他几种方法可以应对大量阅读和写作。很高兴研究 twitter 或 facebook 等顶级互联网公司的架构，并了解他们如何应对类似问题。

【讨论】：