2

我有一个问题，只是在这里寻找建议。

因此，我的应用程序通过将桌面应用程序转换为 Web 来“现代化”桌面应用程序，并使用 Java 编写的 ICEFaces UI 和服务器端。然而，他们保持着相同的 Oracle 数据库，目前该数据库有大约 700-900 个表，并且表中可能有 10 亿条记录。一些单独的表有 2.5 亿行，许多有超过 2500 万行。

不用说，数据库的扩展性不好。结果，应用程序的性能看起来很糟糕。架构师/未来的决策者要么拒绝要么不愿意重构持久性。因此，基本上我们正在为目前满足大多数用户需求并且相对轻松的功能性桌面应用程序涂上一层新油漆。现在桌面应用程序中的实际数据库性能非常慢。我之前提到的快速性能是与数据库无关的东西（对不起，我在那儿说错了）。我晚上难以入睡，想着这个应用程序的性能有多差，以及日常用户完成他们的工作会有多困难。

所以，我的问题是，我有哪些选择来减轻这场迫在眉睫的灾难？我可以在数据库和 Java 代码之间放置某种类型的中间层来提高性能，同时保持数据库结构完整吗？缓存显然是一种选择，但我不认为这是万灵药。是否可以在两者之间分层 NoSQL DB 或其他什么？

4

10 回答 10

4

我不明白如何调和你说的两件事。

不用说，数据库的伸缩性不好

和

目前满足大多数用户需求，并且相对容易和快速的性能。

您并没有说您正在添加新用户或新功能，只是让相同的功能可以通过 Web 界面访问。

那为什么会有问题。您的 Web 应用程序将执行或多或少与以前相同的数据库工作。

事实上，引入 Web 层可以很好地提供新的缓存机会，从而减少数据库的工作量。

如果您早期的 Web 应用程序开发表现不佳，那么我将首先尝试了解您在 Web 应用程序中执行的查询与现有应用程序执行的查询有何不同。您是否可能正在使用一些工具来生成查询？

于 2010-06-03T04:05:25.853 回答
3

如果当前应用程序运行良好而您的新 Java 应用程序没有，则问题不在数据库层，而在您的应用程序层。如果性能如您所说的那样糟糕，他们应该很早就注意到并可以选择返回桌面应用程序。

DBA 应该能够从您的应用程序中轻松识别数据库上的额外工作负载。假设逻辑没有改变，则不太可能进行更多写入。它可以是读取的，也可以是“chattier”（移动相同数量的信息但在较小的包裹中）。Chatty 应用程序会占用大量 CPU。许多架构师试图将处理从数据库层转移到应用程序层，因为“在数据库上的工作很昂贵”，但实际上由于“来回”的开销而使事情变得更糟。

PS。

一个表中有 2.5 亿行并没有什么“坏处”。通常，您通过索引访问表。从索引的顶部到底部通常有 2 或 3 个跃点（然后再到表）。我有一个 BLEVEL 为 2 的 2000 万行表和一个 BLEVEL 为 3 的 120+ 百万行表。

索引意味着您很少会访问超过一小部分的数据块。经常使用的索引块（和数据块）被缓存在数据库服务器的内存中。DBA 将能够查看此内存区域对于工作负载（即大量物理磁盘 IO）是否太小。

如果您的应用程序正在获取大量它并不真正需要的信息，这可能会给内存空间带来压力。不要贪心。如果您只需要一行中的三列，请不要抓取整行。

于 2010-06-03T04:51:44.033 回答
1

如果您有很多查找不在数据库中的项目，您可以使用布隆过滤器减少数量。将数据库中的所有内容添加到布隆过滤器中，然后在进行查找之前先检查布隆。只有当bloom 报告它存在时，您才需要打扰数据库。绽放会导致误报，但您可以将其设计为最适合您的“大小与误报”权衡。

谷歌在他们的大表数据库中使用了该策略，他们报告说它显着提高了性能。

http://en.wikipedia.org/wiki/Bloom_filter

祝你好运，做你不相信的任务很艰难。

于 2010-06-03T03:26:19.747 回答
1

因此，您在功能强大且快速的桌面应用程序上涂上一层新油漆，然后系统变得缓慢？

然后你说“不用说数据库的扩展性不好”？

我不明白。我认为你的新油漆有问题，而不是数据库。

于 2010-06-03T08:32:21.560 回答
1

如果您拥有正确的设备和数据库设计，您所描述的是 Oracle 应该能够非常轻松地处理的事情。如果您的团队中有人是大型应用程序性能调优方面的专家，那么它应该可以很好地扩展。

从头开始重做数据库将花费一大笔钱，并且会引入新的错误，并且丢失关键信息的可能性是巨大的。在这一点上重写数据库几乎从来都不是一个更好的主意。通常这些项目在花费公司数千甚至数百万美元后会惨遭失败。您的建筑师做出了正确的选择。学会接受你想要的并不总是最好的方式。对公司而言，数据远比应用程序重要。人们学会不尝试从头开始重新设计数据库的原因有很多。

现在有一些方法可以提高数据库性能。对于这种大小的数据库，我首先要考虑的是对数据进行分区。我还会考虑将旧数据归档到数据仓库并从中进行大部分报告。其他要考虑的事情是将您的服务器改进为更高性能的模型，分析以查找运行最慢的查询并单独修复它们，查看索引，更新统计信息和索引（不确定这是否是您在 Oracle 上所做的，我是 SLQ服务器 gal 但您的 dbas 会知道）。有一些关于重构旧遗留数据库的好书。下面的不是特定于数据库的。 http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1275577997&sr=8-1 还有一些关于性能调优的好书（寻找特定于 Oracle 的书，适用于 SQL Server 或 mySQL 的不是最适合 Oracle 的书） 就我个人而言，我会得到这些并在设计计划之前从头到尾阅读它们您将修复性能不佳的问题。我还将 DBA 包括在您的所有计划中，他们知道您对数据库不了解的事情，以及为什么有些事情是按照它们的方式设计的。

于 2010-06-03T15:19:08.760 回答
0

不要被这样的事情放下。把它看作是一个挑战，而不是让你失眠的事情！我知道作为一名程序员，想要把所有东西都撕掉并重新开始是很诱人的，但从商业角度来看，这并不总是可行的。例如，通过使用相同的数据库，业务可以在开发新应用的同时继续使用旧应用程序并分组切换客户，而不必同时切换所有人。

至于您可以对性能做些什么，这在很大程度上取决于使用模式。缓存对大多数只读数据库有很大帮助。即使使用读/写数据库，如果设计正确，它仍然是一个福音。NoSQL 数据库可能有助于处理大量写入的内容，但如果数据无论如何都必须最终存储在常规数据库中，那么它也可能比它的价值更麻烦。

最后，这在很大程度上取决于您的应用程序的架构和使用模式。

祝你好运！

于 2010-06-03T03:38:50.450 回答
0

好吧，在不太了解大多数情况下完成的查询类型（我认为查找更常见）的情况下，也许您应该先尝试缓存。并缓存在不同的层，如果可能的话，在应用服务器之前的层，当然还有你建议在应用服务器和数据库之间的层缓存。

缓存适用于读取数据，它可能没有您想象的那么糟糕。

你看过兵马俑吗？他们确实有一些可能与您相关的缓存和缩放内容。

把它当作一个挑战！

于 2010-06-03T03:42:17.730 回答
0

“减轻这场迫在眉睫的灾难”的方法是做你应该做的事情。如果您遵循最佳实践，那么在后期切换持久层的痛苦将是最小的。

在您拥有有效的性能基准并确定系统性能瓶颈之前，还为时过早。无论如何，如果许多“中间层”策略还没有在数据库级别实现，我会感到惊讶。

于 2010-06-03T04:37:23.993 回答
0

如果数据库是遗留的且庞大的，那么

1）它不能以改变界面的方式改变，因为这会破坏太多现有的应用程序。或者，如果您更改界面，则必须与修改具有相关测试的多个应用程序相协调。

2）如果问题是性能，那么可能有很多改变可以在不改变接口的情况下优化数据库。

3) 视图可用于维护现有接口，同时重组表以获得更高的效率，或者将来可能允许更有效的访问。

4) 标准的数据库优化，如性能分析、索引、缓存，在不改变接口的情况下，可能会大大提高效率和性能。

还有很多事情可以做，但你明白了。它不能真正在一次重大更改中更新。更改必须是增量的，或者对使用它的应用程序是透明的。

于 2010-06-03T04:44:10.763 回答
0

数据库是应用程序的一部分。不要认为它们是分开的，事实并非如此。

作为开发人员，您需要根据需要自由地进行架构更改，并建议数据更改以提高生产中的性能/功能（例如存档旧数据）。

您的开发系统可能没有那么多数据，但具有完全相同的架构。

为了进行性能测试，您将需要一个与生产具有相同硬件和相同大小数据（如果可能，相同数据）的系统。您应该向管理层解释性能测试是绝对必要的，因为您认为应用程序不会执行。

当然，进行模式更改（添加/删除索引、拆分表等）可能会影响系统的其他部分——您应该将其视为 SYSTEM 的一部分——因此需要进行必要的回归测试和修复。

如果您需要修改数据库架构，并相应地更改桌面客户端，以使 Web 应用程序执行，这就是您必须做的 - 向管理层证明您的设计决策。

于 2010-06-04T12:56:56.933 回答