我有一个问题，只是在这里寻找建议。
因此，我的应用程序通过将桌面应用程序转换为Web来“现代化”桌面应用程序，其中ICEFaces UI和服务器端用Java编写。但是，它们保留在同一个Oracle数据库中，该数据库目前有大约700-900个表，表中可能有10亿个记录。一些单独的表有2.5亿行，其中许多有超过2500万行。
毋庸置疑，数据库扩展性不佳。因此，该应用程序的性能看起来很糟糕。所有建筑师/决策者都拒绝或不愿意重建持久性。因此，基本上我们在功能性桌面应用程序上添加了一层新的涂料，这些应用程序目前可以满足大多数用户的需求，而且相对容易。现在桌面应用程序中的实际数据库性能相当慢。我之前提到的快速性能是非数据库相关的东西（抱歉，我错过了那里）。我在晚上睡觉时遇到困难，想知道这个应用程序的性能有多差，以及日常用户完成工作的难度。
所以，我的问题是，我有什么选择可以减轻这场迫在眉睫的灾难？我可以在数据库和Java代码之间放置某种类型的中间层来加速性能，同时保持数据库结构的完整性吗？缓存显然是一种选择，但我不认为这是一种治愈方法。是否可以在中间层层化NoSQL DB？
答案 0 :(得分：4)
我不明白如何调和你所说的两件事。
毋庸置疑，数据库扩展性不佳
和
目前满足大多数用户需求，并且相对容易且性能快。
您没有说您正在添加新用户或新功能，只是通过网络界面访问相同的功能。
那么为什么会出现问题呢。您的Web应用程序将执行与以前相同的数据库工作。
事实上，引入Web层可能会带来新的缓存机会，从而减少数据库正在进行的工作。
如果您早期的网络应用开发表现不佳，那么我首先要了解您在网络应用中所做的查询与现有应用的查询有何不同。您是否可能正在使用某种工具，这种工具采用了一种有点天真的方法来生成查询？
答案 1 :(得分：3)
如果当前的应用程序运行良好且您的新Java应用程序没有，则问题不在数据库层中，而是在您的应用程序层中。如果性能与您说的一样糟糕，他们应该很早就注意到并且可以选择返回桌面应用程序。
DBA应该能够从您的应用程序中轻松识别数据库上的额外工作负载。假设逻辑没有改变，则不太可能进行更多写操作。它可能是读取或它可能是“更加可怕”（移动相同数量的信息，但在较小的包裹中）。 Chatty应用程序可以使用大量CPU。许多架构师试图将处理从数据库层转移到应用程序层，因为“在数据库上工作很昂贵”但实际上由于“来回”的开销使事情变得更糟。
PS。
表中有2.5亿行没什么“坏”的。通常，您通过索引访问表。从索引顶部到底部通常有2或3个跃点（然后再一个到表格）。我有一张2000万行表，BLEVEL为2，行表为120多万，BLEVEL为3。
索引意味着您很少会遇到超过一小部分数据块。经常使用的索引块（和数据块）缓存在数据库服务器的内存中。 DBA能够看到这个内存区域是否对于工作负载来说太小（即很多物理磁盘IO）。
如果您的应用获得了大量不需要的信息，这会给内存空间带来压力。不要贪心。如果您只需要一行中的三列，请不要抓住整行。
答案 2 :(得分：1)
如果您有大量不在数据库中的项目的查找，则可以使用bloom过滤器减少数量。将数据库中的所有内容添加到bloom过滤器，然后在执行查找之前先检查bloom。只有当Bloom报告它时，您才需要打扰数据库。绽放将导致误报，但您可以将其设计为最适合您的“大小与误报”交易。
谷歌在其大表数据库中使用该策略，他们报告说它显着提高了性能。
祝你好运，从事你不相信的任务很艰难。答案 3 :(得分：1)
因此，您在功能快速的桌面应用程序上涂上一层新油漆，然后系统会变慢？
然后你说“不用说数据库不能很好地扩展”？
我不明白。我认为你的新涂料有问题，而不是数据库。
答案 4 :(得分：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，他们知道您不了解数据库的事情以及为什么有些事情按照它们的方式设计。
答案 5 :(得分：0)
不要被这种事情搞砸。把它视为挑战，而不是失去睡眠的东西！我知道作为程序员想要将所有东西都撕掉并重新开始是很诱人的，但从业务角度来看，它并不总是可行的。例如，通过使用相同的数据库，企业可以在开发新应用程序时继续使用旧应用程序，并在组中切换客户，而不必同时切换所有人。
至于你可以对性能做些什么，它在很大程度上取决于使用模式。对于大多数只读数据库，缓存可以提供很大帮助。即使使用读/写数据库，如果设计正确，它仍然可以是一个福音。 NoSQL数据库可能有助于解决这些问题，但如果数据最终必须以常规数据库结束，那么它可能也会比它的价值更麻烦。
最后，这完全取决于应用程序的体系结构和使用模式。
祝你好运！答案 6 :(得分：0)
在不太了解大多数类型的查询主要完成的情况下（我会说查找更常见）也许你应该首先尝试缓存。如果可能的话，在应用服务器之前的层上缓存不同的层，当然还有你建议在应用服务器和数据库之间的层缓存。
缓存适用于读取数据，可能没有您想象的那么糟糕。
你看过Terracotta了吗？他们确实有一些可能与你相关的缓存和缩放。
把它作为挑战！
答案 7 :(得分：0)
“缓解即将发生的灾难”的方法是做你应该做的事情。如果您遵循最佳实践，那么在稍后阶段切换持久层的痛苦将是微乎其微的。
直到您拥有有效的性能基准并确定系统中存在瓶颈的时候谈论性能还为时过早。无论如何，如果许多“中间层”策略尚未在数据库级别实现，我会感到惊讶。
答案 8 :(得分：0)
如果数据库是遗留的和巨大的，那么
1）它不能以改变界面的方式改变，因为这会破坏太多现有的应用程序。或者，如果您更改界面，则必须与修改多个应用程序以及相关测试进行协调。
2）如果问题是性能问题，那么可能会在不改变界面的情况下对优化数据库进行许多更改。
3）视图可用于维护现有接口，同时重组表以提高效率，或者可能允许将来更高效的访问。
4）标准数据库优化，例如性能分析，索引，缓存，可以在不改变界面的情况下大大提高效率和性能。
还有很多事情可以做，但你明白了。它无法在一次重大改变中真正更新。更改必须是增量的，或对使用它的应用程序透明。
答案 9 :(得分：0)
数据库是应用程序的一部分。不要认为它们是分开的，它不是。
作为开发人员，您需要根据需要随意进行架构更改，并建议更改数据以提高生产中的性能/功能（例如归档旧数据）。
您的开发系统可能没有那么多数据，但具有完全相同的模式。
为了进行性能测试，您需要一个具有相同硬件和相同大小数据（尽可能使用相同数据）的系统作为生产。您应该向管理层解释，当您认为应用程序无法执行时，性能测试是绝对必要的。
当然，进行架构更改（添加/删除索引，拆分表等）可能会影响系统的其他部分 - 您应该将其视为系统的一部分 - 从而进行必要的回归测试和修复。
如果您需要修改数据库架构，并相应地更改桌面客户端，以使Web应用程序正常运行，那么您需要做的事情 - 向管理层证明您的设计决策。