【问题标题】:Paginate large amount of data对大量数据进行分页
【发布时间】:2015-05-02 04:32:29
【问题描述】:

一些很常见的搜索结果,例如分页,通常显示的是总页数、结果等...

两个例子:

Google - https://www.google.com.br/?gfe_rd=cr&ei=h4PzVLy3JMiU8QeE3ICYBQ&gws_rd=ssl#safe=off&q=test - 大约 26.7 亿条结果(0.39 秒)

Stackoverflow - https://stackoverflow.com/search?q=test - 1,561,211 个结果

例如,Google 假设这 26.7 亿条结果是由数据库找到的要计数的。就像在不影响性能的情况下计算具有许多结果的查询的总结果一样?这是什么魔法?

【问题讨论】:

  • 您的问题是关于分页还是计数?这对我来说不是很清楚。需要记住的一件事:Google 使用 SQL 数据库进行查询,因此在这里很难谈论 Google。与非 SQL 或内存数据库相比,Google 的引擎更好(但有自己的设计)。
  • 全文搜索一般使用专门的全文搜索引擎,在普通SQL引擎之外实现(即使有些SQL数据库自带集成全文索引(这是在普通引擎之上实现的) )。
  • 我知道了。在MySQL中肯定没有如何做到这一点?我们需要像 ElasticSearch 这样的东西吗?就像在追求 stackoverflow 的过程中所做的那样?也和 Elastisearch 一起使用?
  • ElasticSearch 是一种进行全文搜索的工具,是的!谷歌当然有自己的高性能实现。这种实现的功能是 Google 优势的原因之一。

标签: mysql performance count pagination


【解决方案1】:

“大约 26.7 亿个结果(0.39 秒)”——注意“大约”这个词。这为允许它在几乎 0.00 秒内完成计数的技巧打开了大门。例子:

  • 每晚数数
  • 统计抽样
  • 有汇总表

“1,561,211 个结果”,另一方面,“听起来”是一个精确的计数。但这可能是一个“陈旧”的结果。我刷新了该页面几次;值没有改变。这让我相信他们真的计算过它,但随后将结果缓存了一段时间。 Memcached 可能是此类缓存的嫌疑人。

(毫无疑问还有其他的交易技巧。)

【讨论】:

  • 如果只有一张表,那就很容易分辨了,即使使用EXPLAIN,使用join或按表中的任何列过滤都会成为问题,那是不可能的。我想知道的是“没有人需要使用带有巨大桌子的网格吗?”。我们开发了两年的系统,现在只有更大的表和连接正在解决这个问题。在您看来,不存在作为绝对解决这个问题?谢谢。
猜你喜欢
  • 2012-08-04
  • 1970-01-01
  • 1970-01-01
  • 2014-04-05
  • 1970-01-01
  • 2020-02-15
  • 2015-09-08
  • 2010-09-25
  • 1970-01-01
相关资源
最近更新 更多