问题 方式(客户端或服务器端)去分页/排序列?


我在employee表中有3000条记录,我从一个查询中从数据库中获取了这些记录。我每页可以显示20条记录。因此每页有150页,显示20条记录。关于分页和可排序列方法,我有两个问题:

1)如果我实现一个没有可排序列的简单分页,我应该将所有3000条记录发送到客户端并使用javascript或jquery进行分页客户端。因此,如果用户点击第二页,则呼叫将不会转到服务器端,而且速度会更快。 虽然我不确定在浏览器/客户端发送3000条或更多记录会产生什么影响?那么什么是最好的方法是将所有记录一次性发送到客户端并在那里进行排序或点击页面将调用发送到服务器端然后只返回特定的页面结果?

2)在这种情况下,我需要提供分页以及可排序列(6列)。所以这里用户可以点击任何列,如员工姓名或部门名称,然后名称应按升序或降序排列。 我想再次了解时间响应/内存方面的最佳方法吗?


4995
2018-04-01 07:01


起源

发送任何有意义数据的3000条记录的效果将大大降低客户端浏览器的速度。我将服务器端分页。 - Brad
我不知道大数据集如何影响浏览器性能。看起来喜欢形成您的答案3000或更多记录将难以被浏览器处理。是吗? - M Sach
问题:看到“下一个”20个结果的概率/频率是多少?如果它很低,则分页服务器端。如果温和,仍然服务器方面,值得惩罚。如果高,STILL服务器端因为瓶颈和客户端处理可能不值得:)你可以随时使用OFFSET和LIMIT来知道要获取哪个页面:) - PhD
PS:除非您发回的数据非常小,即只是员工姓名,身份证,一些细节我猜3000记录不会那么多,所以发送它们可能是值得的 - 但要确保这不是过早的优化w.r.t.我上面的评论 - PhD
Nupul感谢您的回复。从所有答案看起来,服务器端分页是更好的选择。但仍然要完全澄清,想知道如果在客户端而不是服务器端进行分页和排序将会产生什么影响。我的意思是为什么它不是很好的选择。是因为在网络上传输如此庞大的数据需要更长的时间吗? - M Sach


答案:


向您的客户端发送数据几乎肯定是您的瓶颈(特别是对于移动客户端),因此您应该始终尽可能少地发送数据。话虽如此,在服务器端进行分页几乎肯定更好。这是一个更具伸缩性的解决方案。数据量可能会增长,因此对于未来在服务器上进行分页是一个更安全的选择。

此外,请记住,任何用户都不太可能会费心查看数百个结果页面,因此传输所有数据也可能会造成浪费。 这个 可能是您的相关阅读。


7
2018-04-02 04:16



我不知道大数据集如何影响浏览器性能。看起来喜欢形成您的答案3000或更多记录将难以被浏览器处理。是吗?还考虑我基本上只考虑Deskop /笔记本电脑客户端,现在不是移动客户端 - M Sach
浏览器将能够处理数据(可能),但请记住,网络速度通常是应用程序中最慢的部分,通常是几个数量级。照这样说, 任何 您发送的额外数据非常昂贵。 - Oleksi
在那种情况下请求,respose只会在第一次变慢(当我一起发送3000条记录时)。但是当用户访问更多页面时它会更快,因为我们可以在客户端本身播放数据(无需转到服务器)。同样的问题:)。哪一个是更好的客户端或服务器端(可能它将取决于用户不太可能通过几页我们可以去服务器端的情况,但如果他可能通过大量页面,我们可以去客户端)。实际上我正在寻找这种详细的分析。 - M Sach
任何用户都不太可能真正查看3000条记录。你是对的,客户端只会在第一次请求时变慢,但是很容易这么慢,以至于阻止用户访问你的网站。由于这一大的等待期,您的应用程序的整体响应能力将更差。对于用户而言,一个较大的等待时间可能比几个较小的等待时间更加明显。如果要传输小块数据,用户可能甚至看不到性能损失,但他们几乎肯定会在开始时注意到大量数据传输。 - Oleksi
另外,请记住移动平台。由于启动时间很长,在移动浏览器上传输大量数据几乎肯定会使应用程序无法使用。 - Oleksi


我假设您有一个表示此表中记录的bean类,实例从您拥有的任何ORM加载。

如果您还没有,则应在应用程序中实现这些bean的缓存。这可以在本地完成,也许使用Guava CacheBuilder,或远程使用呼叫 Memcached的 例如(后者对于多个app服务器/负载平衡是必要的)。这些bean的缓存应该键入唯一的id,很可能是映射到相应表的主键列。

进入分页:只需编写查询以仅返回所选记录的ID。包括 LIMIT 和 OFFSET 或者你的DB语言相当于paginate。查询的调用者也可以随意过滤/排序 WHEREORDER BY 等等

回到Java层,遍历这些查询的结果ID并构建您的 List 通过调用缓存来控制bean。如果缓存未命中,它将调用您的ORM单独查询并加载该bean。一旦 List 构建后,可以对其进行处理/序列化并发送到UI。


1
2018-04-02 04:12





我知道这不会直接回答客户端与服务器端的分页,但我建议使用DataTables.net来显示和分页数据。它提供了非常好的显示,允许排序和分页,内置搜索功能,以及更多。我第一次使用它是为了我工作的第一个Web项目,作为一个完整的noobie,我能够让它工作。论坛还提供非常好的信息/帮助,创作者将回答您的问题。 DataTable可以在客户端和服务器端使用,并且可以支持数千行。 至于速度,我只有几百行,但使用客户端处理,从未注意到延迟。


1
2018-04-02 04:54



固体产品。即使没有使用DT,也可以学习各种用例和演示 - 直接回答主题问题:“......如果您正在使用认真的大型数据库,您可能需要考虑使用服务器端选项DataTables提供。“我依靠大数理论来解决扩展问题。否则,请查看客户端演示。 - XO.


使用服务器PAGINATION!

当然,你可能会发送一个包含3000个元素的JSON数组并使用JavaScript在客户端上进行分页/排序。但是一个优秀的网络程序员应该知道如何在服务器上分页和排序记录。 (他们应该知道几种方式)。所以,把它想象为好的做法:)

如果您想要一个灵活的用户界面,请考虑使用 JavaScript网格组件 使用AJAX获取数据。通常,这些组件会传回以下参数(或其中的一些变体):

  • 开始记录索引
  • 要返回的记录数
  • 排序列
  • 排序方向
  • 要获取的列(有时)

开发人员可以实现基于这些输入参数返回结果集的处理程序或接口。


1
2018-04-03 04:58



达娜,谢谢你的回复。从所有答案看起来,服务器端分页是更好的选择。但是仍然想澄清为什么服务器端是一个好的做法,想知道如果在客户端而不是服务器端进行分页和排序会有什么影响。我的意思是为什么它不是很好的选择。是因为由于如此巨大的数据,在网络或浏览器上传输如此庞大的数据需要更长的时间吗? - M Sach
我认为某处存在平衡。想想哈希表与链表。对于小型记录集,链表可以正常工作。但随着记录集的大小增加,哈希表将赢得胜利。分页也是如此。客户端工作将用于小记录集,但随着记录集的大小增加,您发送的数据量越来越大,只显示几条记录。 - dana
底线是服务器端分页 秤。您的应用程序可能正常工作,但随着时间的推移,当您的数据库获取更多记录时,将整个记录集流式传输到客户端需要更长的时间。也就是说,当然有一些情况,你可能永远不会得到太多的记录,客户端分页将始终执行。但是,如果您在服务器端分页方面开发适合您的模式,那么从长远来看,这将更加灵活。 - dana