mysql - 优化与数据库的工作

Question

有足够大的商品数据库，而且还在稳步增加。现在数据库中有超过 1000 万种商品。

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

起初我们只使用mysql，并通过为每个类别创建一个表来存储商品。通过这种方式，我们有大约 6-7 千张带商品的 table 。在选择时，我们向他们每个人发出请求，在运算符 UNION 的帮助下合并请求。随着 cargo 数量和类别的增加，选择开始需要很长时间并放下mysql服务器。 在此之后，我们将所有产品移动到一个表中。表结构如下[如下](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秒。我们试图将产品仅绑定(bind)到一个类别(属性 tids 变成了 sql_attr_uint)。采样时间减少到3~5秒，也不是很好。

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

Answer 1

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

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

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

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

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

您应该尝试经典方法:

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

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

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

还有其他几种方法可以应对大量的读写操作。研究 Twitter 或 Facebook 等顶级互联网公司的架构并了解他们如何处理类似问题是件好事。