快速复制大型数据库表的方法

我们正在尝试解决性能问题。搜索数据并以分页方式显示的时间大约需要2-3分钟。快速复制大型数据库表的方法

经过进一步调查（并在几次sql调优之后），似乎由于数据量很大，搜索速度很慢。

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

我创建了一个概念证明，事实上，在我的缓存中搜索速度比在db中快。但是，初始完整复制需要很长时间才能完成。虽然完全复制只会发生一次，然后成功复制只会增加自上次复制以来发生更改的复制，但如果我可以加速初始完全复制，它仍然很棒。

但是，在完全复制期间，除了查询执行的缓慢之外，我还必须对抗网络延迟。事实上，我可以处理缓慢的查询执行时间。但网络延迟实际上确实降低了复制速度。

那么，这导致我的问题，我怎么能加快我的复制？我应该产生几个线程，每一个做一个查询？我应该使用可滚动吗？

来源

2010-07-15 Franz See

这是实时数据，还是事后报告？您可能想尝试查看nosql解决方案是否适用于此特定查询（s） – 2010-07-15 14:26:24

是的。我将在nosql存储中复制我们的RDBM（或其一些表）。 – 2010-07-16 06:37:11

SELECT * FROM YOUR_TABLE
地图结果转换成一个对象或数据结构
指定为每个对象或数据结构
加载密钥和对象或数据结构的唯一钥匙插入WeakHashMap中充当您的缓存。

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

一定要考虑线程安全性。

我假设这是一个只读缓存，并且这样做是为了避免不断的网络延迟。我还假设你在启动时会这样做。

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

来源

2010-07-15 00:19:58 duffymo

是不是12M记录真的没有那么多的DBMS？我的意思是索引和其他技巧... – hvgotcodes 2010-07-15 00:26:18

我只提到了关于sql分页和排序，以指出为什么我打算将它复制到我们的数据库之外并进入缓存。对困惑感到抱歉。另外，'select * from your_table'方法太慢了。我希望能够加速它的发展（而不是等待几个小时才能完成）。 – 2010-07-15 00:27:36

实际上，问题出在你何时加入其他表格并对分页进行排序。我们的DBA已经优化了可以优化的所有内容，但是要分类的数据量（分页）太大，每个查询仍需要2到3分钟。 – 2010-07-15 00:30:05

复制高速缓存中的数据看起来像复制数据库的功能。

从阅读其他评论，我看到你没有这样做，以避免网络往返，但由于昂贵的加入。在许多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。

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

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

来源

2010-07-15 01:13:35 emory

再次请谅解。我不是在重新创建缓存解决方案或搜索解决方案。我只需要从数据库中读取数据（足够快），并将它们存储在我正在使用的缓存中，并使用我的搜索解决方案将它们编入索引。另外，尽管我可以在数据库中进行缓存，但最好不管我使用的缓存是水平可伸缩的（这就是为什么我试图避免RDBM进行缓存的原因）。 – 2010-07-15 01:20:31

此外，如果我没有弄错，VIEW（与Materialized VIEW不同）就像查询的快捷方式，意味着与视图相关的查询仍将被执行。当然，由于内存中的缓存和更少的磁盘空间，它可能会更快，但我认为我们不能依靠它来获得一致的快速查询。 – 2010-07-15 01:21:43

快速复制大型数据库表的方法

回答

相关问题