cache数据库能建立视图嘛

cache数据库能建立视图。在cache中，当用户请求到达视图后，建立视图会先从数据库提取数据放到模板中进行动态渲染，渲染后的结果就是用户看到的网页。cache数据库是美国Intersystems公司产品，后关系型数据库(PostRelationaldatabase)中的领头羊。

日志缓冲区Log_buffer是Oracle专门用于存入重做日志的内存区域。

数据库启动时，可以看到：

SQL> startup

ORACLE 例程已经启动。

Total System Global Area 85006980 bytes

Fixed Size 453252 bytes

Variable Size 46137344 bytes

Database Buffers 37748736 bytes

Redo Buffers 667648 bytes

数据库装载完毕。

数据库已经打开。

Redo Buffers就是分配给Log_buffer的内存大小。

对日志缓冲区的大小，可以从下面的视图中查询的到：

SQL> select from v$parameter;

也可以

SQL> show parameter log_buffer

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

log_buffer integer 524288

从这儿查询出的数据，是在配置文件中配置的数据，配置文件有：SPFILEORA92ORA，INITora92ORA等。

这个值和真实的日志缓冲区的大小不同。如果要知道真实的Log_buffer的大小，可以用下面的方法查询：

SQL> select from v$sgastat where name ='log_buffer';

POOL NAME BYTES

----------- -------------------------- ----------

log_buffer 656384

上面的这个值，是Oracle的SGA实际分配给Log_buffer的大小。

另外，还可以从 v$sga中查询：

SQL> select from v$sga;

NAME VALUE

-------------------- ----------

Fixed Size 453252

Variable Size 46137344

Database Buffers 37748736

Redo Buffers 667648

这个值也就是Oracle启动时分配给Log_buffer的大小。

那这个值为什么和实际的大小有差别呢？

SQL> select (667648-656384)/1024 ||'K' from dual;

(66

---

11K

相差11K，那这11K干什么用呢？

这11K是Oracle为了保护Log_buffer，分配出来的日志保护页。

根据你的想法，建议将两种方式整合下，建议如下设置：

接根据业务层的需要，把频繁使用的多个表数据进行整合，并利用视图的方式进行访问，这样既能减少数据表的压力，也能保持数据的准确性；

根据向系统设定场景，将经常使用到的数据存放在缓存中，缓存建议使用radis等非关系型数据库；

根据数据量确定，数据量比较大的，可以使用中间表等方式，如果数据量小而多的，放在缓存中最好，提高命中率。

物化视图

许多数据库管理系统（例如Oracle 或者微软SQL Server）都提供了一个被称作物化视图的功能 物化视图实际上是预先计算并且存储在磁盘上的表 可以通过各种各样的策略刷新和更新 MySQL 并不原生支持物化视图（我们将在第 章详细探讨支持这种视图的细节） 然而 使用Justin Swanhart 的开源工具Flexviews（//code google /p/flexviews/） 也可以自己实现物化视图 Flexviews 比完全自己实现的解决方案要更精细 并且提供了很多不错的功能使得可以更简单地创建和维护物化视图 它由下面这些部分组成

变更数据抓取（Change Data Capture y CDC）功能 可以读取服务器的二进制日志并且解析相关行的变更

一系列可以帮助创建和管理视图的定义的存储过程

一些可以应用变更到数据库中的物化视图的工具

对比传统的维护汇总表和缓存表的方法 Flexviews 通过提取对源表的更改 可以增量地重新计算物化视图的内容 这意味着不需要通过查询原始数据来更新视图 例如 如果创建了一张汇总表用于计算每个分组的行数 此后增加了一行数据到源表中 Flexviews简单地给相应的组的行数加一即可 同样的技术对其他的聚合函数也有效 例如SUM（）和AVG（） 这实际上是有好处的 基于行的二进制日志包含行更新前后的镜像 所以Flexviews 不仅仅可以获得每行的新值 还可以不需要查找源表就能知道每行数据的旧版本 计算增量数据比从源表中读取数据的效率要高得多

因为版面的限制 这里我们不会完整地探讨怎么使用Flexviews 但是可以给出一个概略 先写出一个SELECT 语句描述想从已经存在的数据库中得到的数据 这可能包含关联和聚合（GROUP BY） Flexviews 中有一个辅助工具可以转换SQL 语句到Flexviews 的API 调用 Flexviews 会做完所有的脏活 累活 监控数据库的变更并且转换后用于更新存储物化视图的表 现在应用可以简单地查询物化视图来替代查询需要检索的表

Flexviews 有不错的SQL 覆盖范围 包括一些棘手的表达式 你可能没有料到一个工具可以在MySQL 服务器之外处理这些工作 这一点对创建基于复杂SQL 表达式的视图很有用 可以用基于物化视图的简单 快速的查询替换原来复杂的查询

      返回目录 高性能MySQL

       编辑推荐

       ASP NET MVC 框架揭秘

       Oracle索引技术

       ASP NET开发培训视频教程

lishixinzhi/Article/program/MySQL/201311/29674

以MySQL为例：

影响数据库性能的主要因素总结如下：

1、sql查询速度

2、网卡流量

3、服务器硬件

4、磁盘IO

以上因素并不是时时刻刻都会影响数据库性能，而就像木桶效应一样。如果其中一个因素严重影响性能，那么整个数据库性能就会严重受阻。另外，这些影响因素都是相对的。

例如：当数据量并没有达到百万千万这样的级别，那么sql查询速度也许就不是个重要因素，换句话说，你的sql语句效率适当低下可能并不影响整个效率多少，反之，这种情况，无论如何怎么优化sql语句，可能都没有太明显的效果。

相关内容拓展：

1、SQL查询速度

风险：效率低下的SQL

2、网卡流量

风险：网卡IO被占满（100Mb/8=100MB）

方案：

①减少从服务器的数量。从服务器都要从主服务器上复制日志，所以，从服务器越多，网络流量越大。

②进行分级缓存。前方大量缓存突然失效会对数据库造成严重的冲击。

③避免使用“select ”进行查询

④分离业务网络和服务器网络

3、磁盘IO

风险：磁盘IO性能突然下降。

方案：使用更好的磁盘设备解决。

事件需要重定向到适当的 saga 实例。 为此，需要一些基础设施类。 最重要的组件是 SagaManager 和 SagaRepository 。

与处理事件的任何组件一样，处理是由事件处理器完成的。 但是，sagas 不是处理事件的单例实例。 他们有各自的生命周期，需要加以管理。

Axon 通过 AnnotatedSagaManager 支持生命周期管理，它被提供给事件处理器以执行处理程序的实际调用。 它使用要管理的 saga 的类型以及可以存储和检索该类型的 saga 的 SagaRepository 进行初始化。 单个 AnnotatedSagaManager 只能管理单个 saga 类型。

使用配置 API 时，Axon 将为大多数组件使用合理的默认值。 但是，强烈建议定义一个 SagaStore 实现来使用。 SagaStore 是在某处“物理”存储 saga 实例的机制。 AnnotatedSagaRepository （默认）使用 SagaStore 来存储和检索需要的 Saga 实例。

Axon Configuration API

Spring Boot AutoConfiguration

SagaRepository 负责存储和检索 saga，供 SagaManager 使用。 它能够通过它们的标识符以及它们的关联值来检索特定的 saga 实例。

但是，有一些特殊要求。 由于 saga 中的并发处理是一个非常微妙的过程，repository 必须确保对于每个概念 saga 实例（具有相同的标识符）在 JVM 中仅存在一个实例。

Axon 提供 AnnotatedSagaRepository 实现，它允许查找 saga 实例，同时保证只能同时访问 saga 的单个实例。 它使用 SagaStore 来执行 saga 实例的实际持久化。

使用的实现选择主要取决于应用程序使用的存储引擎。 Axon 提供了 JdbcSagaStore 、 InMemorySagaStore 、 JpaSagaStore 和 MongoSagaStore 。

在某些情况下，应用程序受益于缓存 saga 实例。 在这种情况下，有一个 CachingSagaStore 包装了另一个实现以添加缓存行为。 请注意， CachingSagaStore 是直写式缓存，这意味着保存 *** 作始终会立即转发到后备存储，以确保数据安全。

JpaSagaStore 使用 JPA 来存储 sagas 的状态和关联值。 Sagas 本身不需要任何 JPA 注解； Axon 将使用 Serializer 对 sagas 进行序列化（类似于事件序列化，您可以在 XStreamSerializer 或 JacksonSerializer 之间进行选择，可以通过在应用程序中配置默认的 Serializer 来设置。有关更多详细信息，请参阅序列化程序

JpaSagaStore 配置有 EntityManagerProvider ，它提供对要使用的 EntityManager 实例的访问。 这种抽象允许使用应用程序管理和容器管理的 EntityManager 。 或者，您可以定义序列化程序来序列化 Saga 实例。 Axon 默认为 XStreamSerializer 。

JdbcSagaStore 使用纯 JDBC 来存储阶段实例及其关联值。 与 JpaSagaStore 类似，saga 实例不需要知道它们是如何存储的。 存储使用序列化程序序列化 saga 实例。

您应该使用 DataSource 或 ConnectionProvider 配置 JdbcSagaStore 。 虽然不是必需的，但在使用 ConnectionProvider 进行初始化时，建议将实现包装在 UnitOfWorkAwareConnectionProviderWrapper 中。 它将检查当前工作单元中是否存在已打开的数据库连接，以确保工作单元内的所有活动都在单个连接上完成。

与 JPA 不同， JdbcSagaRepository 使用纯 SQL 语句来存储和检索信息。 这种方法可能意味着某些 *** 作依赖于特定于数据库的 SQL 方言。 也可能是某些数据库供应商提供了您想使用的非标准功能。 为此，您可以提供自己的 SagaSqlSchema 。 SagaSqlSchema 是一个接口，它定义了存储库需要在底层数据库上执行的所有 *** 作。 它允许您自定义为每个 *** 作执行的 SQL 语句。 默认值为 GenericSagaSqlSchema 。 其他可用的实现是 PostgresSagaSqlSchema 、 Oracle11SagaSqlSchema 和 HsqlSagaSchema 。

Schema 构建

请注意，Axon 不会为您创建开箱即用的数据库 schema 。 例如，在使用 Spring Boot 时也不行。

要构建 schema，应该调用 JdbcSagaStore#createSchema 。 默认情况下，这将使用 GenericSagaSqlSchema 。 您可以通过 JdbcSagaStoreBuilder 配置不同的版本来更改 schema。

MongoSagaStore 将 saga 实例及其关联存储在 MongoDB 数据库中。 MongoSagaStore 将所有 saga 存储在 MongoDB 数据库中的单个集合中。 对于每个 saga 实例，都会创建一个文档。

MongoSagaStore 还确保在任何时候，对于单个 JVM 中的任何唯一 Saga，都只存在一个 Saga 实例。 这可确保不会因并发问题而丢失状态更改。

MongoSagaStore 使用 MongoTemplate 和可选的 Serializer 初始化。 MongoTemplate 提供了对存储 sagas 的集合的引用。Axon 提供了 DefaultMongoTemplate ，它接受一个 MongoClient 实例以及数据库名称和存储 sagas 的集合名称。数据库名称 和集合名称可以省略。 在这种情况下，它们分别默认为 “axonframework” 和 “sagas” 。

如果使用数据库支持的 saga 存储，保存和加载 saga 实例可能是一项相对昂贵的 *** 作。 在短时间内多次调用同一个 saga 实例的情况下，缓存可能对应用程序的性能特别有益。

Axon 提供 CachingSagaStore 实现。 它是一个包装了另一个 SagaStore 的 SagaStore ，它负责实际存储。 加载 saga 或关联值时， CachingSagaStore 将首先查询其缓存，然后再委托给包装的 repository。 存储信息时，所有调用总是被委派以确保后备存储始终对 saga 的状态有一致的视图。

要配置缓存，只需将任何 SagaStore 包装在 CachingSagaStore 中。 CachingSagaStore 的构造函数采用三个参数： 1 要包装的 SagaStore 2 用于关联值的缓存 3 用于 saga 实例的缓存

后两个参数可能指的是同一个缓存，也可能指不同的缓存。 这取决于您的特定应用程序的要求。

PG物化视图（Materialized View）是PostgreSQL中一种特殊的视图，是对基本表数据的聚合和简化，并将结果缓存到物理表中。物化视图可以提高查询的执行效率，并且可以实现对基本表数据的定期刷新，确保数据的正确性。其主要优缺点如下：

优点：

1 提高查询性能。物化视图的使用可以避免大量 joins、group by 和聚集函数，可以加快查询速度。也可以在物化视图中进行预计算，简化表的复杂查询。

2 降低数据冗余。物化视图将计算结果保存在物理表中，相比动态视图或查询，无需每次执行查询时计算全部数据，可以有效减少数据冗余。

3 优化查询计划。物化视图可以作为附加的优化器提高查询计划的效率，特别是当查询中有多个相同的联结、聚合函数或固有的查询逻辑时。

4 常用于大数据量的系统。当查询结果集是大数据量的时候，直接读取物化视图，而非直接查询源数据表，这对于大数据量系统的性能改善是非常显著的。

缺点：

1 物化视图增加了存储成本。使用物化视图会占用更多的磁盘空间，增加存储和维护成本。

2 物化视图必须定期刷新。使用物化视图需要定期刷新保证数据的正确性，如果刷新的时间不当，可能导致数据不一致。

3 物化视图可能不适合高并发的应用场景。当物化视图的更新频率高，而且许多查询同时访问物化视图的时候，可能会产生锁问题。

4 物化视图的维护有一定的复杂性。如果物化视图对基本表进行了除了简单查询之外的 DML *** 作，就需要对物化视图进行重新计算或刷新，或禁止对基本表进行 DML *** 作，这需要一定的管理和维护成本。

总之，PG物化视图具有明显的性能优势和简化查询的能力，但是也需要权衡其缺点，特别是存储和维护成本。

以上就是关于cache数据库能建立视图嘛全部的内容，包括:cache数据库能建立视图嘛、怎么查看oracle数据库数据缓冲区大小、Java中怎么把数据库中的表做成定时任务，存入缓存，减轻频繁直查数据库时，数据库的压力等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！