我们目前正在尝试解决性能问题。哪个搜索数据并以分页方式呈现它需要大约2-3分钟。
经过进一步调查（以及几次sql调整之后），由于数据量庞大，搜索速度似乎很慢。
我正在研究的一个可能的解决方案是在可搜索的缓存中复制数据。现在这个缓存可以在数据库中（即物化视图），也可以在db（nosql方法）之外。但是，由于我希望缓存可以横向扩展，我倾向于将其缓存在数据库之外。
我已经创建了一个概念验证，实际上，在我的缓存中搜索比在db中更快。但是，初始完整复制需要很长时间才能完成。虽然完全复制只会发生一次，然后成功复制将只是针对自上次复制后更改的复制，但如果我可以加速初始完全复制，那么它仍然会很好。
但是，在完全复制期间，除了查询执行缓慢之外，我还必须对抗网络延迟。实际上，我可以处理慢查询执行时间。但网络延迟实际上确实减慢了复制速度。
所以这引出了我的问题，我怎样才能加快复制速度？我应该生成几个执行查询的线程吗？我应该使用可滚动的吗？
答案 0 :(得分：0)
SELECT * FROM YOUR_TABLE 我不明白为什么需要排序，因为你的缓存应该在O（1）时间内通过唯一键访问值。什么是分类购买你？
务必考虑线程安全性。
我假设这是一个只读缓存，你这样做是为了避免不断的网络延迟。我也假设你在启动时会这样做一次。
每条记录有多少数据？每条记录1KB的12M记录意味着您只需要12GB的RAM来保存缓存。
答案 1 :(得分：0)
复制缓存中的数据似乎复制了数据库的功能。
通过阅读其他评论，我发现你不是为了避免网络往返，而是因为代价高昂的联接。在许多DBMS中，您可以创建临时表 - 如下所示：
CREATE TEMPORARY TABLE abTable AS SELECT * FROM a , b ;
如果a和b是大型（相对永久性）表，那么创建临时表的一次性成本为2-3分钟。但是，如果对许多查询使用abTable，则后续的每个查询成本将远小于
SELECT name, city, ... , FROM a , b ;
其他数据库系统有一个视图概念，可以让你做这样的事情
CREATE VIEW abView AS SELECT * FROM a , b ;
底层a和b表的变化将反映在abView中。
如果您真的担心网络往返，那么您可以在本地计算机上复制部分数据库。
良好的数据库管理系统应该能够处理您的数据需求。为什么要重新发明轮子？