我正在研究新系统的架构来取代古老的大型机应用程序。大型机使用IBM IMS，并且使用大量数据时速度惊人。到目前为止，我们已经尝试了3个数据库 - MongoDB，SQL Server和Oracle，但它们在负载下表现不佳。我们聘请了Oracle顾问和128核服务器，Oracle仍然为旧系统提供了4倍的响应时间（与SQL Server相同）。
是否有任何现代分层数据库可以有效支持数十亿条记录？
答案 0 :(得分：3)
对于某些用例，大型机已经并且仍然非常快，因此第一部分不要假设大型机=坏。话虽如此，维护它们的成本非常高，特别是对于传统应用程序，技能开始消失。
如果您真的想要一个分层数据库，一个有效的选择是使您的应用程序现代化，但保留IMS的核心。 IMS是一个很好的分层数据库，我认为IBM不会很快进入EOL IMS，所以有没有真正的理由去一个不是IMS 的分层数据库？快速访问他们的网站给我的印象是，如果他们认为你要迁移到竞争产品，他们会打折产品，所以如果钱是问题，那么答案可能只是要求IBM打折产品你我已经满意了。本白皮书（ftp://public.dhe.ibm.com/software/data/ims/pdf/TCG2013015LI.pdf）建议他们将其作为一种选择，毫无疑问，IMS的后续版本具有许多功能，这些功能可能在您运行的版本中不可用（假设您已经没有升级到最新版本。）
我很惊讶你无法从甲骨文中获得你想要的性能，我目前正在研究的系统有十几个表，而我们肯定没有128个内核，但我们得到合理的表现。
我的第一个问题是你的Oracle顾问是否真的知道他们的东西。我的结果好坏参半，我想任何技能组合人都可以拥有不同的技能。我经常发现，当你遇到性能问题时，这是因为人们过度规范化或过度概括了数据库模式 - 所以你已经从IMS中的高度优化的层次结构转移到了3NF中非常抽象的结构，并且死了。但有时如果你在Oracle中使用相同的层次结构，并且只允许在IMS中使用相同类型的访问模式，那么你将获得所需的所有性能。
通过这个，我的意思是，如果在IMS中你有客户，客户有订单，订单有订单行，那么我认为这意味着没有在客户端启动就很难进行任何访问。它通常意味着您拥有大型批处理流程，每天处理所有客户，以找出哪些订单需要您执行某些操作。
所以，有些事情在这里。首先，如果在Oracle中，你要构建那个结构 - 所以我有一个客户端id，客户端id是订单主键中的第一个元素，而客户端id则订单id是前两个元素。订单行的主键，然后我使用客户端ID作为我的集群键，并将客户端ID放入每个索引......可能我所有基于客户端的访问路径都非常快。您还可以按客户端ID进行分区，如果需要，运行Oracle RAC集群，每个分区/客户端范围在单独的更多商品类计算机上有效地作为单独的数据库运行（例如，双插槽计算机=大约20个核心）。
其次，如果我以前必须每晚处理我的所有记录以找到需要某人处理它们的订单，那么在新的关系世界中我不再需要这样做了，我只需要查找状态为“待定”或其他的订单。因此，对于那种面向批处理的工作负载而言，Oracle可能并不那么快，但如果我更改逻辑并对挂单执行索引查询，那么我可以再次获得所需的所有性能。更重要的是，也许我将order_status放入分区键，因此我的“活动”记录都在一个分区中，所有旧命令都在其他分区中 - 然后我将该分区放在SSD支持的阵列上。
第三，看看你的存储设备。数据库中的性能问题总是存在IO问题 - 要么执行过多的IO（优化不佳的查询），要么IO子系统无法跟上您需要执行的IO。 128核是一个非常多的计算，我很少看到一个计算绑定的数据库。也许看一下大型SSD阵列，其中一些可以为您提供巨大的IO吞吐量。当然，如果您在RAID 5旋转磁盘阵列上运行Oracle，您的性能可能很糟糕。
这里的最后一个随机评论 - 很多人通过SAP HANA获得了良好的结果 - 一个完全内存的数据库。这真的过得很快，专门针对在其他数据库中运行速度不够快的工作负载而设计。我敢打赌，如果您愿意，SAP会免费向您演示。