软件运行速度太慢，这往往是用户难以忍受的。 根据客户体验供应商 Emplifi 对 2,000 名消费者进行的一项全球调查显示，仅 遇到 两到三次不好的客户体验，86% 的消费者就会离开他们曾经信任的品牌。 要想留住用户，必须要解决三个数据库性能问题。

一、问题一：大规模数据降低了查询性能

客户数据库的容量和表格大小不断增长，传统数据管理方法无法 应对 数据库 的 增长 趋势 。 开发人员发现 ， 大规模数据集 —— 无论是通过容量、速度还是可变性来衡量 —— 需要一个可扩展的架构，以便进行高效的存储、操作和分析。

随着客户数据库的增长，在数据库中查询单个标识符（Universally Unique Identifier, UUID ）愈加困难，缓慢的查询 速度使得 客户服务 质量下降 。缓慢的数据库查询 使用于 创建聚合数据视图 的实时数据操作难以执行，也就不能从实时数据中获得启发 。

解决方法 ： 将客户 查询 表和其他与客户相关的数据表移至内存数据库中。

内存数据库的工作方式与其他数据库类似，只是所有数据都存储在DRAM 中而不是传统磁盘上。 且内存数据库也会 定期 将 数据存储在磁盘上， 从而 实现持久性和数据恢复。

因为无需花费时间写入磁盘或从磁盘检索，所以内存数据库的性能得到显著增强。 内存操作的执行速度比基于磁盘的驱动器快很多倍，也比NVMe 或 SATA 固态磁盘驱动器快得多 。 这意味着应用程序可以搜索数千万条客户记录，以查找与单个客户相关的信息并实时获取结果。

二、问题二： 查询速度太慢，无法立即分析

数据库性能不仅限于提取数据以提供客户记录或存储交易， 实时数据库查询 还可用 来支持业务指标背后的分析，如项目仪表板和故障排除警报。

对于分析而言，数据的质量与其年龄直接相关。较旧的和非常旧的数据对于实时分析和决策制定来说价值较低。

导致查询性能问题的瓶颈可能出现在数据操作流程中的任何 环节 。数据库搜索和查询操作在计算方面成本高昂，索引和提供搜索结果需要大量资源。

同时摄取数据 并 查询不同的数据结构（如哈希和JSON 文档） 是具有挑战性的 。这对于基于磁盘的SQL 数据库，如 Oracle 和 SQL Server ，尤其如此。通常的解决方案是 进行 数据库性能调优，但由于底层数据库架构和数据库工作负载 类型 的 限制 ， 这种方法只能有限地提升性能。

解决方法：使用实时搜索引擎提供快速的数据分析结果。

实时搜索引擎查询并聚合大规模数据集，立即生成 实时 的数据。数据 分析师 随后可以在仪表板、图表或其他应用程序中使用和分析数据。

实时搜索引擎提供：

l 提供亚毫秒级搜索和查询结果的性能以进行精确分析

l 可对海量数据集进行大规模搜索和查询，并提供即时结果

l 占用资源少，对微服务框架友好

下图是 将来自多个记录来源的数据合并到一个实时搜索引擎中，以提供及时的数据供分析和新业务 理解 ：

Redis Enterprise 将数据整合到实时搜索引擎中

三、问题三：主数据表数量增长，在线搜索太慢

另一个常见的数据库问题是在庞大的主数据表上执行重复查找。主数据表有助于定义数据库中的重要数据库实体，通常代表：产品、合作伙伴、供应商和订单。与任何其他数据管理元素一样，随着公司的增长，这些数据表也会增长。

当主数据表中的主键或 辅助键 值达到数百万个时，数据库重复执行大型主数据表查找时会出现性能问题。常见症状是用户搜索明显变慢或应用程序页面出现延迟，特别是在为电子商务网站搜索庞大的产品数据库时。

解决方法：将数据 导入 、索引和查询负载分布到数据库分区或分片中，并使用二级索引。

地理分布式数据库拓扑 结构 可以将主数据表扩展到数千万个主键和 辅助键 。 这使得可以进行强大的搜索自动建议和灵活的基于类别的搜索，为在线客户和企业用户提供即时搜索结果。 通过将读取和写入操作分布在 在多个数据库分区或分片上，可以实现主数据表 的 大规模 扩展 和高性能结果搜索。

二级索引是为提供快速数据查找而创建的非主键索引。 它们的搜索结果可能包含重复值，例如查找所有制造商列为 “Apple” 的产品。 数据库的二级索引允许在任何数据库字段中灵活快速地搜索主数据表。您可以为单个记录创建成千上万个索引，或者在整个数据库中创建数十万个索引。一旦创建索引，数据库会提供自动索引管理。

四、 Redis Enterprise 可以满足您的实时搜索需求

针对以上常见的三个数据性能问题， Redis Enterprise 提供了解决方案。 Redis Enterprise 能 为实时数据提供强大的索引、查询和全文搜索引擎。Redis 搜索引擎可用于实时客户聚合，作为 Redis 中托管数据的二级索引，整合其他数据存储中的数据进行分析，并充当快速全文搜索或自动完成引擎。