1

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

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

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

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

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。

4

1 回答 1

1

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

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

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

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

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

您应该尝试经典方法：

  1. 编写用例——哪些是我想在我的系统中优化的主要查询？
  2. 接受这些查询并优化您的表和索引

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

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

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

于 2013-09-25T20:10:21.403 回答