复制巨大数据库表的快速方法答案

【问题标题】：Fast way to replicate a huge database table复制巨大数据库表的快速方法
【发布时间】：2010-07-15 00:14:31
【问题描述】：

我们目前正在尝试解决性能问题。搜索数据并以分页方式呈现数据大约需要 2-3 分钟。

经过进一步调查（并经过多次 sql 调整），搜索似乎很慢，只是因为数据量太大。

我目前正在研究的一种可能的解决方案是将数据复制到可搜索的缓存中。现在这个缓存可以在数据库中（即物化视图），也可以在数据库之外（nosql 方法）。但是，由于我希望缓存能够水平扩展，因此我倾向于将其缓存在数据库之外。

我已经创建了一个概念证明，实际上，在我的缓存中搜索比在数据库中搜索要快。但是，初始完整复制需要很长时间才能完成。尽管完全复制只会发生一次，然后后续复制将相对于自上次复制以来更改的那些进行增量复制，但如果我可以加快初始完全复制的速度仍然会很棒。

但是，在完全复制期间，除了查询执行缓慢之外，我还必须与网络延迟作斗争。事实上，我可以处理缓慢的查询执行时间。但是网络延迟确实会减慢复制速度。

这引出了我的问题，如何加快复制速度？我应该产生几个线程，每个线程都做一个查询吗？我应该使用可滚动的吗？

【问题讨论】：

【解决方案1】：

复制缓存中的数据就像复制数据库的功能。

通过阅读其他 cmets，我看到您这样做并不是为了避免网络往返，而是因为连接成本高昂。在许多 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 中。

如果您真的关心网络往返，那么您可以在本地计算机上复制部分数据库。

一个好的数据库管理系统应该能够处理您的数据需求。那么为什么要重新发明轮子呢？

【讨论】：

再次原谅我的困惑。我没有重新发明缓存解决方案或搜索解决方案。我只需要从数据库中读取数据（足够快）并将它们存储在我正在使用的缓存中，并使用我的搜索解决方案对它们进行索引。此外，虽然我可以在数据库中进行缓存，但最好是我使用的任何缓存都是水平可扩展的（这就是我试图避免使用 RDBM 进行缓存的原因）。
另外，如果我没记错的话，视图（与物化视图不同）就像查询的快捷方式，这意味着与视图关联的查询仍将被执行。当然，由于内存缓存和更少的磁盘命中，它可能会更快，但我认为我们不能依靠它来获得一致的快速查询。

【解决方案2】：

我不明白你为什么需要排序，因为你的缓存应该在 O(1) 时间内通过唯一键访问值。什么是排序买你？

一定要考虑线程安全。

我假设这是一个只读缓存，您这样做是为了避免持续的网络延迟。我还假设您将在启动时执行此操作。

每条记录有多少数据？ 12M 条记录，每条记录 1KB 意味着您需要 12GB 的 RAM 来保存缓存。

【讨论】：

对于一个 DBMS 来说，12M 的记录真的不多吗？我的意思是索引和其他技巧......
我只提到了 sql 分页和排序，以说明为什么我打算将它复制到我们的数据库之外并复制到缓存中。对困惑感到抱歉。此外，select * from your_table 方法太慢了。我希望加快它以简化开发（而不是等待几个小时才能完成）。
实际上，问题是当您将它与其他表连接并进行分页排序时。我们的 DBA 已经优化了所有可以优化的东西，但是要排序（用于分页）的数据量太大，每次查询仍然需要 2 到 3 分钟。
那么您是否也要复制缓存中的其他表？以及加入和排序的逻辑？听起来您在用 Java 实现自己的 DBMS 时正走在滑坡上……
我已经有了其他数据。我将使用 lucene 对它们进行索引（因为我需要搜索功能）。