search 2013 adfgs

在上一篇Oracle Sharding 介绍系列 III(横向对比) 对 Oracle Sharding 与其他产品进行了横向对比之后,这一篇我们再看看 Oracle Sharding 背后的技术实现 1、数据在分片之间如何分配?

Oracle Sharding使用水平分区来跨分片(离散物理数据库)分割数据库表,以便每个分片包含具有相同列但行的不同子集的表。 跨分片的分区的分布在表空间级别完成。分片表的每个分区驻留在单独的表空间中,每个表空间与特定分片相关联。每个分片上的表分区与非分片Oracle数据库中使用的常规分区没有区别。即使表的分区驻留在多个数据库中,对应用程序开发人员来说,表的外观和行为与单个数据库中的常规分区表完全相同。应用程序发出的SQL语句从不引用分片,也不依赖于分片数及其配置。 Oracle Sharding提供了几种可选的分区方法,可以自动或由用户确定数据的分布,或两者的组合。

2、Oracle Sharding支持哪些类型的Sharding方法呢?

Oracle Sharding支持三种分片方法:系统管理,用户定义和复合分片。

  • 系统管理的分片不要求用户指定数据到分片的映射。使用按照一致性哈希分区,自动在分片中分布数据。分区算法均匀且随机地在分片之间分布数据。这种分布旨在消除热点并在整个碎片上提供均匀的性能。当向SDB添加或从SDB中删除分片时,Oracle Sharding会自动维护平衡的数据分布。系统管理的分片使用为Oracle Sharding优化的一致性哈希分区策略。系统管理的分片是最常用的分片形式。
  • 用户定义的分片允许用户明确指定数据到各个分片的映射。当由于性能,法规或其他原因,某些数据需要存储在特定分片上,并且用户需要对分片之间的数据移动进行完全控制时使用。用户定义的分片的另一个优点是,在分片的计划或计划外中断的情况下,用户准确地知道什么数据不可用。用户定义的分片的缺点是用户需要监视和维护跨分片的数据和工作负载的平衡分布。用户定义的分片使用范围或列表分区策略。
  • 复合分片是用户定义和系统管理的分片的组合,在需要时提供这两种方法的优点。使用复合分片,数据首先按列表或范围分区,然后通过一致的散列进一步分区。这两个级别的分片使得可以将数据映射到一组分片,然后自动保持该组分片上的数据的平衡分布。

3、如何在单个分片上包含多个事务?

对于许多应用程序,可以通过将水平分区与跨所有分片的少量只读或读取主表的复制结合来实现高百分比的单分片操作。对于通常与分片表一起访问的相对较小的表,完整表的复制是一个不错的选择。在每个分片中具有相同内容的表称为重复表。 Oracle Sharding使用物化视图复制来同步重复表的内容。每个分片上的重复表由只读物化视图表示。物化视图的主表位于称为碎片目录的特殊数据库中。所有分片上的物化视图都将以可配置的频率自动刷新。 CREATE DUPLICATED TABLE自动创建主表,物化视图和物化视图复制所需的其他对象。

4、应用程序如何知道它在运行时必须连接到哪个分片?

应用程序必须指定一个分片键,以使用分片式数据库架构实现高性能。例如,网上银行应用程序可以设计为使用当用户作为分片键登录时生成的customer_id。 当处理数据库事务时,应用程序将分片键传递到连接层:

  • Oracle JDBC,OCI和ODP.net客户端能够识别连接字符串中指定的分段键,以实现高性能数据相关的路由。连接层中的分片路由缓存用于将请求直接路由到数据所在的分片。
  • 用于JDBC客户端的Oracle通用连接池(UCP)还能够识别连接URL中指定的分片键。分片路由缓存用于将连接直接路由到数据所在的分片。 Oracle UCP还支持非Oracle应用程序客户端(如Apache Tomcat,WebSphere等)与Oracle Sharding一起使用。

例如,UCP分片路由缓存包含分片键范围到分片的映射。当应用程序通过分片键检出连接时,UCP从其路由缓存中查找其上存在此键的相应分片。如果池中有匹配的连接可用,则UCP通过应用其内部连接选择算法来返回到这些分片中的一个的连接。如果没有匹配的连接,则通过将具有分片关键字的请求转发到Shard Director来创建新的连接。在第一次连接到分片时,连接池检索分片中的所有键范围,并将它们添加到其路由缓存中,以便后续连接直接转到分片(即绕过Shard Director)。 如果分片不可用,客户端连接将自动重定向到HA的分片副本。

5、如果重新平衡数据或添加/删除碎片,则路由缓存如何更新?

所有重新平衡和添加/删除分片操作都由SDB管理层(Shard Catalog和Shard Director)执行。在所有这些操作期间,SDB保持可用并在线。一旦重新平衡完成,分片路由高速缓存将失效,并在下次将连接路由到分片时自动刷新。

6、如何在多个shard之间重新平衡工作负载?

在以下情况下需要跨分片的数据迁移:

  • 当一个或多个分片添加到SDB或从SDB中删除时
  • 当跨分片的数据或工作负载分布存在偏差时

在由分片数量变化触发的分片之间重新分布数据的过程称为重新分片。自动重新分片可以在SDB上提供统一的数据分布。要理解这是如何完成的,有必要了解如何在碎片上物理分区数据。 跨分片的分区分布通过在驻留在不同分片上的表空间中创建分区来实现。为了最小化多分片连接的数量,表族中所有表的相应分区总是存储在同一分片中。分片表的每个分区存储在单独的表空间中。 因此,表空间是SDB中的数据分布的物理单位。分片之间的数据迁移单位是块。块是一组表空间,用于存储表系列中所有表的相应分区。块包含来自表系列的每个表的单个分区。这保证来自不同分片表的相关数据一起移动。在创建SDB时指定每个分片中的块数。 当发生数据或工作负载倾斜时,特定块也可以从一个碎片移动到另一个碎片,而碎片数量没有任何变化。在这种情况下,块迁移由DBA启动以消除热点。或者,Oracle Sharding也支持在线拆分一个块。 当块变得太大时,或者只有一部分块必须迁移到另一个块时,需要拆分。 RMAN增量备份,可传输表空间和Oracle Notification Service技术用于将块迁移对应用程序可用性的影响降至最低。块在块迁移期间保持联机。当存储在块中的数据仅可用于只读访问时,有一段很短的时间(几秒钟)。迁移组块的过程由管理员自动启动。 启用FAN的客户端在块即将在源分片中变为只读时,以及在完成块迁移时在目标分片中完全可用时接收通知。当客户端接收到”chunk read-only”事件时,它们可以重复连接尝试,直到块移动完成,或访问源块中的只读块。在后一种情况下,尝试写入块将导致运行时错误。

7、分片如何提供线性可伸缩性?

线性可扩展性通过消除碎片之间的任何依赖性来实现。 每个分片是独立的Oracle数据库,不共享任何硬件或软件。 需要高性能和可扩展性的事务只访问单个分片中包含的数据。 设计用于Oracle分区的OLTP应用程序可以在任何平台上弹性扩展(数据,事务和用户)到任何级别,只需在额外的独立服务器上部署新的分片。 每个分片通常使用本地存储器,闪存和存储器,提供以相对低的成本进一步优化性能的机会。 通过应用程序提供的分片键和Oracle客户端(JDBC,OCI和ODP.net)及Oracle通用连接池(UCP)支持的高性能数据相关路由,将工作负载定向到相应的分片。 分片键的示例包括:customer_id,account_no,country_id等。

8、分片如何实现故障隔离?

根据定义,每个分片是独立的Oracle数据库,不与其他分片共享硬件或软件。一个或多个碎片的中断或减速不会影响其他碎片上应用程序的可用性。在分片级别用于HA的复制在分片经历中断时快速恢复可用性。同样,一个分片的计划维护不会影响其他分片的可用性。 另外,分片导向器和分片目录数据库的其他组件也有助于消除单点故障。碎片导向器是一个非常轻量级的进程,不包括Oracle数据库实例。冗余碎片引导器部署在每个区域内部署碎片,以确保对SDB的连续应用程序访问。分片目录数据库使用Oracle Data Guard复制和自动故障转移来提供高可用性。目录数据库对运行时连接的路由没有影响 – 客户端连接使用分片路由缓存来实现高性能数据相关的路由。在Data Guard自动故障转移期间,目录数据库的瞬时不可用性仅导致碎片维护操作或多分片查询的短暂中断。

9、如何为分片数据库实施高可用性和灾难恢复?

用于任何Oracle数据库的所有常用Oracle高可用性解决方案也用于为分片式数据库提供HA,备份和恢复以及灾难恢复。

  1. 具有自动数据库故障转移的Data Guard是用于计划外中断和计划维护的默认HA配置,并自动为每个分片部署;
  2. 管理员可以自动部署Active Data Guard(所有分片副本以只读方式打开)或Oracle GoldenGate双向复制用于分片HA;
  3. 管理员可以手动配置用于分片HA的Oracle RAC
  4. Oracle恢复管理器(RMAN)和闪回在提供分片级别的备份和基于时间点的恢复
  5. 零数据丢失恢复设备提供高效的企业备份和恢复。恢复设备可以执行实时备份,从而保护SDB中的每个事务。
  6. 每个分片的其他远程副本由Data Guard,Active Data Guard或Oracle GoldenGate维护,并为站点中断提供实时灾难恢复和数据保护。
  7. 基于版本的重新定义在部署修改后端数据库对象的应用程序的新版本时提供了对分片的在线修补。

上一片介绍了 Oracle Sharding 介绍系列II(特性优势),这里再介绍一下 Oracle Sharding 与其他产品进行一下横向对比。

1、Oracle Sharding 与RAC

  • Oracle RAC和Active Data Guard的组合为OLTP和分析应用程序提供了透明的横向扩展和可用性,并且可以满足99 +%的用例需求。 使用Oracle RAC,所有事务可以对数据库中的任何数据起作用,没有必要分区数据或关注多分片操作的性能,所有RAC实例共享对同一物理数据库的直接访问。
  • Oracle Sharding牺牲了透明性,为定制设计的OLTP应用程序提供了巨大的可扩展性和高可用性。 使用Oracle Sharding,应用程序被设计为使更新事务对单个分片中的数据起作用。 跨越多个分片的事务不会受益于与单分片事务相同的性能和可伸缩性。

问:在什么场景下使用Oracle Sharding 而不是RAC

答:有以下两种情况:

  1. 当Oracle Enterprise Architect或客户决定Oracle RAC无法解决当前或未来的可扩展性和可用性要求时,Oracle Sharding会成为首选解决方案;
  2. 当应用程序被明确地设计用于分片数据库时。

注意,分片和Oracle RAC不是互斥的。分片可以使用Oracle RAC或RAC One节点代替复制HA。第一个版本的Oracle Sharding的唯一注意事项是RAC必须手动配置; Oracle Sharding不提供使用DEPLOY命令自动部署RAC配置,就像Data Guard / Active Data Guard和Oracle GoldenGate一样。正在考虑在将来的版本中自动部署RAC配置。

2、Oracle Sharding 与多租户 Oracle多租户是SaaS和其他数据库应用程序的整合解决方案;

Oracle Sharding是高容量OLTP系统的可扩展性和高可用性解决方案。 Oracle Multitenant支持用于SaaS应用程序的DBaaS以及私有、公共和开发/测试云。它提供了将数据库联合在一起成为逻辑数据库的基础设施,以实现对应用程序透明的所有数据的高性能查询。 Oracle Multitenant通过为Oracle数据库提供最高的整合密度以及将多个集成为一体的简单性,为降低资本和运营成本提供了独特的优势。 Oracle Sharding为定制设计的OLTP应用程序提供了巨大的可扩展性和高可用性。更新事务必须指定分片密钥,并对单个分片中的数据执行操作,以便受益于分片式数据库架构承诺的高性能和可用性。支持多分片操作或非分片键访问,但性能降低。这样的事务包括简单的聚合,报告等 – 理想地小于分片数据库的总工作负载的10%。

问:Oracle Sharding是否支持多租户?

答:Oracle Sharding(12.2.0.1)的初始版本不支持Oracle Multitenant。 计划在将来的版本中支持单租户容器数据库,支持多租户容器数据库。

问:有同时包含Oracle Sharding和多租户的场景案例吗?

答:有, 当提供对Oracle Multitenant的分区支持时,每个分片将是一个PDB,并且将受益于Multitenant提供任何其他PDB的敏捷性的相同优势。

示例包括:

  • 简单地通过从其当前CDB拔出并将其插入到更高版本的CDB中来简化多租户架构中的分片。
  • 迁移到Oracle Cloud和从Oracle Cloud迁移的简单性。 可以拔除作为PDB的内部部署分片,然后插入Oracle云。
  • 碎片的PDB克隆。

3、Oracle Sharding 与Oracle MAA

Oracle Sharding是Oracle MAA的自然演进,旨在解决针对定制开发的OLTP应用程序的大规模可扩展性和完全故障隔离的特殊用例。 适用于Oracle数据库的所有Oracle MAA原则也适用于包含SDB的各个分片。 将扩展Oracle MAA最佳实践,以解决SDB配置和管理的任何独特注意事项。

4、Oracle Sharding 如何与Oracle集成系统相关? Oracle Sharding是与大多数其他功能一样的硬件平台,属于Oracle MAA可扩展性和可用性解决方案的保护范围。 Oracle Sharding将受益于底层硬件平台提供的数据库工作负载的任何优势。 这意味着Oracle集成系统提供的数据库性能,可用性和可管理性的所有常见优点也会使在此类系统上运行的分片数据库受益。

 

承接上一篇文章Oracle Sharding 介绍系列I(什么是Oracle Sharding)

这里再介绍下 Oracle Sharding 更多的特性,为什么会受到如此多的关注

Oracle Sharding是响应客户对数据库架构的需求,可以提供线性可扩展性和完全故障隔离的组合,而无需共享存储或损害Oracle数据库的企业质量:严格的一致性,SQL的全部功能,开发人员敏捷性 具有JSON,安全性,高可用性,备份和恢复,生命周期管理等。

Oracle Sharding不仅仅将Oracle的企业质量扩展到分片式数据库架构, 并且通过使用自动化来简化生命周期管理,高级分区方法来解决各种各样的场景案例以及数据相关的路由,以实现卓越的运行时性能。 与竞争性分片解决方案或定制部署相比,这些功能为客户提供了显着的优势。

1、Oracle Sharding 在12.2版本中的新特性

Oracle 12.2在Sharding方面增加了许多新的优势:

  • 具有完全故障隔离的线性可扩展性。用于Oracle分区的OLTP应用程序可以在任何平台上弹性扩展(数据,事务和用户)到任何级别,只需在额外的独立服务器上部署新的分片。由于计划外中断或计划维护而导致的碎片不可用或减速只影响该碎片的用户,但不会影响其他碎片用户的应用程序的可用性或性能。每个分片可以运行不同版本的Oracle数据库,只要应用程序与最早运行的版本向后兼容即可 – 从而在执行数据库维护时轻松维护应用程序的可用性。
  • 全球数据分布,为消费者带来数据和数据主权,以满足数据隐私法规。
  • 多生命周期管理任务的自动化简化,这些任务包括:自动创建分片和复制,系统管理分区,单一命令部署和细粒度重新平衡。
  • 使用智能、数据相关的路由,实现卓越的运行时性能。
  • 在不牺牲企业RDBMS功能的情况下实现分片的所有优点。包括:关系模式,SQL和其他编程接口,复杂数据类型,在线模式更改,多核可扩展性,高级安全性,压缩,高可用性, ACID属性,一致性读取,开发人员与JSON的敏捷性等。

2、设计Oracle Sharding 的意义

Oracle Sharding使用用于部署和管理分片式数据库架构的全面解决方案来替代本地的分片方法。
Oracle分片提供了跨分片分布表分区的新自动化,自动部署分片式数据库,包括HA和数据保护的复制,高性能路由,负载平衡和完整的生命周期管理。

Oracle Sharding还针对分片用例显式优化了Oracle数据库经过时间验证的企业功能。 包括Oracle分区、Data Guard、Active Data Guard、GoldenGate、JDBC / OCI / ODP.NET连接池、DBCA、OEM、Oracle RAC等。

应用程序使用Oracle Sharding需要有哪些前提呢?

并非所有应用程序都可以利用分片数据库。 Oracle Sharding适用于为分片式数据库架构显式设计的OLTP应用程序。需满足以下条件:

  • 应用程序必须有一个明确定义的数据模型和数据分布策略(散列,范围,列表或复合),主要通过某个键访问数据。 密钥的示例包括客户ID,帐户号,country_id等。
  • 所有需要高性能的事务必须是单分片事务。 这些事务为高性能路由提供了一个分片键,通常访问10或100行。 例如,查找和更新客户的记帐记录,查找和更新订户的文档等
  • 支持多分片操作或非分片键访问,但性能会降低。 这种交易包括简单的聚合,报告等 – 通常小于总工作量的10%

这是关于 Oracle Sharding 方面系列文章的第一篇,从 Oracle 12.2 开始,不仅有多租户场景,多数据中心架构,还有云部署模型。下面就是关于 Oracle Sharding介绍系列第一篇,大部分内容来自 Oracle 文档。

这篇文站首先介绍下什么是 Oracle Sharding。

Oracle Sharding是Oracle数据库为在线交易类型的应用程序定制设计的一种可扩展、支持高可用功能的架构,可以在不具有共享硬件或软件的数据库池中分发和复制数据。 数据库池作为单个逻辑数据库展现给应用程序,应用程序通过在池中添加额外的数据库(分片),可以在任何平台上弹性扩展(数据,事务和用户)到任何级别, 使用Oracle数据库12.2.0.1的第一个版本支持扩展到1000个分片。

1、Oracle Sharding 的优点

与使用类似的可伸缩性方法的本地部署相比,Oracle Sharding提供了卓越的运行时性能和更简单的生命周期管理;还提供了企业DBMS的优势,包括:关系模式,SQL和其他编程接口,支持复杂数据类型,在线模式更改,多核可扩展性,高级安全性,压缩,高可用性,ACID属性,一致性 阅读,使用JSON的开发人员敏捷性等等。

Oracle分片使用水平分区在分片之间分布数据,通过分片分割数据库表,以便每个分片包含具有相同列但行的不同子集的表。

  • 从数据库管理员的角度来看,SDB由可以集中或单独管理的多个数据库组成。
  • 从应用程序开发人员的角度来看,SDB看起来像一个单一的数据库:分片的数量和跨越它们的数据的分布对数据库应用程序是完全透明的。 应用程序发出的SQL语句不引用分片,也不取决于分片数及其配置。

2、Oracle Sharding 的架构设计

OLTP应用程序必须从最初就设计好使用Sharding的架构方案,才能体现扩展性和可用性的优势。 因为者完全不同于基于Oracle RAC的高可用架构,RAC的实现对于应用程序来说是完全透明的。 但分片数据库的应用程序必须具有明确定义的数据模型和数据分发策略(一致的哈希,范围,列表或组合),主要通过分片键访问数据。 分片键的示例包括customer_id,account_no,country_id等。Oracle Sharding还支持数据放置策略(机架和地理位置感知)以及所有部署模型:内部部署模式和公共云或混合云。

有极高性能要求的事务必须是通常访问10行或100行的单分片事务。例如,查找和更新客户的记帐记录,查找和更新订户的文档等。在用于高性能事务的分片之间没有通信或协调。

当然还支持多分片操作和非分片键访问,但可能会对性能产生影响。这种交易包括简单的聚合,报告等 – 通常小于总工作量的10%。

3、Oracle Sharding 在高可用、可扩展性方面的实现

在上述的设计考虑的基础上,在分片数据库架构上运行的应用程序可以实现更高级别的可伸缩性和可用性。Sharding 数据库的性能会随着池中分片的增加而线性增长,因为每个分片之间是彼此独立的。每个分片通常使用本地存储、闪存和内存,为客户进行性能优化提供了相对低的成本。第一个版本的Oracle Sharding旨在扩展到1,000个分片。分片之间彼此独立意味着一个分片的中断或性能较差不会影响在其他分片上执行的事务的可用性或性能。

单个分片的高可用性(HA)由数据库复制的自动部署提供。默认配置是具有自动数据库故障转移的单向Data Guard物理复制,其实现起来非常简单。还可以自动部署Active Data Guard(复制打开只读)或Oracle GoldenGate(双向复制,所有副本均为打开读写)。碎片可以在数据中心内和跨数据中心进行复制,复制是使用Oracle Sharding支持的数据放置策略的数据中心和机架感知实现的,当然也可以手动配置Oracle RAC以提供Shard HA。

碎片是由一组称为Shard Director的复制侦听器作为路由器的前端。 Oracle客户端(JDBC,OCI和ODP.net)和Oracle通用连接池(UCP)已得到增强,可识别连接字符串中指定的分片键,并通过控制每个分片允许的最大连接数确保可用性。连接层中的分片路由缓存(由分片的初始请求填充)用于将请求直接路由到数据所在的分片,以实现最佳运行时性能。如果对分片数据库进行任何更改(例如自动重新平衡或添加/删除分片),则会自动刷新分片路由缓存。

接着上一篇 MySQL 数据库性能优化之SQL优化,这是 MySQL数据库性能优化专题 系列的第五篇文章:MySQL数据库性能优化之存储引擎选择

离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。

由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。

  • MyISAM
    • 特性
      1. 不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用
      2. 表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能
      3. 读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读
      4. 只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据
    • 适用场景
      1. 不需要事务支持(不支持)
      2. 并发相对较低(锁定机制问题)
      3. 数据修改相对较少(阻塞问题)
      4. 以读为主
      5. 数据一致性要求不是非常高
    • 最佳实践
      1. 尽量索引(缓存机制)
      2. 调整读写优先级,根据实际需求确保重要操作更优先
      3. 启用延迟插入改善大批量写入性能
      4. 尽量顺序操作让insert数据都写入到尾部,减少阻塞
      5. 分解大的操作,降低单个操作的阻塞时间
      6. 降低并发数,某些高并发场景通过应用来进行排队机制
      7. 对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率
      8. MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问
  • InnoDB
    • 特性
      1. 具有较好的事务支持:支持4个事务隔离级别,支持多版本读
      2. 行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响
      3. 读写阻塞与事务隔离级别相关
      4. 具有非常高效的缓存特性:能缓存索引,也能缓存数据
      5. 整个表和主键以Cluster方式存储,组成一颗平衡树
      6. 所有Secondary Index都会保存主键信息
    • 适用场景
      1. 需要事务支持(具有较好的事务特性)
      2. 行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成
      3. 数据更新较为频繁的场景
      4. 数据一致性要求较高
      5. 硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO
    • 最佳实践
      1. 主键尽可能小,避免给Secondary index带来过大的空间负担
      2. 避免全表扫描,因为会使用表锁
      3. 尽可能缓存所有的索引和数据,提高响应速度
      4. 在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交
      5. 合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性
      6. 避免主键更新,因为这会带来大量的数据移动
  • NDBCluster
    • 特性
      1. 分布式:分布式存储引擎,可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
      2. 支持事务:和Innodb一样,支持事务
      3. 可与mysqld不在一台主机:可以和mysqld分开存在于独立的主机上,然后通过网络和mysqld通信交互
      4. 内存需求量巨大:新版本索引以及被索引的数据必须存放在内存中,老版本所有数据和索引必须存在与内存中
    • 适用场景
      1. 具有非常高的并发需求
      2. 对单个请求的响应并不是非常的critical
      3. 查询简单,过滤条件较为固定,每次请求数据量较少,又不希望自己进行水平Sharding
    • 最佳实践
      1. 尽可能让查询简单,避免数据的跨节点传输
      2. 尽可能满足SQL节点的计算性能,大一点的集群SQL节点会明显多余Data节点
      3. 在各节点之间尽可能使用万兆网络环境互联,以减少数据在网络层传输过程中的延时

注:以上三个存储引擎是目前相对主流的存储引擎,还有其他类似如:Memory,Merge,CSV,Archive等存储引擎的使用场景都相对较少,这里就不一一分析了,如果有朋友感兴趣,后面再补充吧。

, , ,