问题标签 [oltp]

我应该将 OLAP 或 OLTP 用于 BIRT、Jasper Report... 等报告工具吗？我想建立临时的许多文件（例如 1000000）。

我继承了一个大容量的 OLTP DB，我可以自由支配，尽可能多地改进它。改进已经非常有帮助，但我想把它提升到一个新的水平。我发现的数据访问模式使它成为 IMO 将数据缓存在其他服务器上的一个很好的候选者，我很想听听任何人对这种设置的经验或建议。

我们有一个数据库，每天将大约 3GB 的数据添加到一个表中，并且过去报告它的速度非常慢。数据一旦放入就不会改变，并且不会插入超过一周的数据。在过去 3 天内输入的行往往会在数千万行之间看到数千个插入。

我正在考虑将超过 2 周的数据推送到 MongoDB。然后，我可以让未推送到 Mongo 的 2 周滑动窗口数据被某种缓存软件缓存，以便查询和显示这些数据，而不是一直从数据库中读取数据。我认为通过这种方式，我们仍然可以通过让数据库引擎验证所有数据来获得完全的 ACID 合规性，因为它没有命中数据库，所以具有高读取性能，然后当它不再是“事务”时 Mongo 可以接受它。

有人有任何推荐的解决方案吗？我正在查看 MemCached，但不太确定这是否是一个好的甚至是合理的解决方案。谢谢！

我正在为大学做这篇关于 DataWarehouse 的论文工作，更具体地说是关于 OLTP。我在网上找不到太多信息。我找到了一般和肤浅的总结，但没有什么能让我有可能做更详细的工作。

我真的很感激有关查找此类信息的任何帮助，我现在有点迷失了。

那么，是否有任何 pdf 或电子书或其他东西可以用来作为我工作的基础？

提前感谢，约翰

PS。关于 OLTP、datawarehouse 我可以找到足够的信息

我们刚刚开始组建一个数据仓库，它将对我们的报告要求有用，将不同的数据源整合在一起。

一起回顾数据的潜在用途，我们发现了一些潜在的场景，我们的一些事务处理系统可以以有用的方式引用这些数据。显然数据会过时，并且针对读取进行了优化，但是在某些情况下，这对于应用程序目的来说是好的，并且会减少核心服务器上的负载。

我的问题是：交易系统访问存储在数据仓库中的数据是否被认为是一种糟糕的设计？显然，我们仓库的主要目的是报告，这让我质疑我们是否应该允许其他非报告系统读取数据。我的直觉引导我远离允许应用程序读取和显示数据，有什么好的理由来听它们吗？！

我正在尝试构建一个基础架构，用于按需快速运行回归，从包含我们网络服务器上所有历史活动的数据库中提取 apache 请求。为了通过确保我们仍然回归来自较小客户的请求来提高覆盖率，我想通过为每个客户检索最多 n 个（为了这个问题，比如说 10 个）请求来确保请求的分布。

我发现这里回答了许多类似的问题，其中最接近的似乎是SQL 查询，以在一系列 ID 中返回每个 ID 的前 N ​​行，但答案大部分是我已经尝试过的与性能无关的解决方案。例如，row_number() 分析函数准确地为我们提供了我们正在寻找的数据：

但是，鉴于此表包含给定日期的数百万个条目，并且这种方法需要从索引中读取与我们的选择标准匹配的所有行才能应用 row_number 分析函数，因此性能很糟糕。我们最终选择了近一百万行，只是因为它们的 row_number 超过 10 而丢弃了绝大多数行。执行上述查询的统计数据：

但是，如果我们只查询特定 contextid 的前 10 个结果，我们可以更快地执行此操作：

运行此查询的统计信息：

在这种情况下，Oracle 足够聪明，可以在获得 10 个结果后停止检索数据。我可以收集一组完整的 contextid 并以编程方式生成一个查询，该查询由每个 contextid 的该查询的一个实例和union all整个混乱在一起，但考虑到 contextid 的绝对数量，我们可能会遇到内部 Oracle 限制，即使没有，这种方法有点杂乱无章。

有谁知道一种方法可以保持第一个查询的简单性，同时保持与第二个查询相称的性能？另请注意，我实际上并不关心检索一组稳定的行。只要它们满足我的标准，它们就可以用于回归。

编辑： Adam Musch 的建议成功了。我在此处将性能结果与他的更改一起附加，因为我无法将它们放入对他的回答的评论回复中。这次我还使用更大的数据集进行测试，以下是我原始 row_number 方法中的（缓存）统计数据进行比较：

我冒昧地将亚当的建议简化了一点。这是修改后的查询...

...以及来自其（缓存）评估的统计数据：

正如宣传的那样，我们只访问dailylogdata 表以获取完全过滤的行。我担心它似乎仍在根据它声称选择的行数（1213K）对 urlcontext 索引进行全面扫描，但鉴于它仅使用 6770 个缓冲区（即使我增加上下文特定结果的数量）这可能会产生误导。

我的问题与这个问题相同- 但需要补充一点。我的问题是我的网络应用程序的用户被允许创建记录的新版本。记录的每个新版本都会在 50 个其他相关表中创建相应的“新版本”，以记录对该特定版本的单独更改。这种包含大约 50 个表的新版本的创建在事务中运行（以在发生错误时回滚所有更改）。很多时候，这个过程很慢，这是可以理解的，因为“冗长的事务”涉及太多的表“插入”。

我正在寻找更好的解决方案/设计来实现这样的场景。

1. 有没有更好的方法来维护同一记录的“版本”，特别是当它在多个表中创建太多重复项时
2. 我觉得设计本身并不好，因为“每一行版本”都插入了太多记录，但至少想解决眼前的问题，即“冗长的事务”——这有时会导致延迟。可能没有出路，但仍然想问 - 如果我不将“版本控制”放在事务中，是否有更好的方法在发生错误时回滚（因为事务似乎阻止了其他 OLTP查询 - 由于在所有主表上插入新版本）

版本控制查询现在运行大约 10 秒，但有时会变得更糟。任何想法表示赞赏

我正在使用 C# 开发应用程序并尝试选择正确的数据库平台。我的应用程序是某种数据分析工具。在将数据初始导入数据库后，我总是会进行 SELECT 查询。我打算使用 SQLite，因为与 SQL CE 相比，它的读取性能更好。（我在某处看过比较）

但是，我觉得为此需要一个 OLAP 数据库而不是 OLTP 数据库。我还在某处读到 SQLite 仅支持 OLTP。你知道任何其他支持 OLAP 的类似于 SQLite 的 PORTABLE 库吗？或者你有什么推荐给我的？

目前，我有一个高度事务性的数据库，每天大约有 100,000 次插入。如果我开始允许从我的主事务表中进行大量并发读取，我是否需要担心？我不关心并发性，更关心性能。

目前这张表有110+万笔交易，我用的是SQL 2005

更广泛的观点：维护库存 EOD 数据的数据库计划。

手头的工具：我计划使用 MySQL 数据库 4.1+ 和 PHP。在 PHP 中实现了一个自定义 DBAL（基于 mysqli）以与 MySQL 一起使用。但是，我对任何其他数据库引擎持开放态度，只要它们可以免费使用并使用 SQL 语句：P

问题域：我需要为我的项目规划一个数据库来维护库存的 EOD 数据。由于数据库中维护的库存数量将非常庞大，因此相同的 EOD 数据的更新过程在一天结束时将是一个相当繁重的过程。不用说我在共享主机上，并且在初始启动期间必须避免 MySQL 性能瓶颈。但是以后可能会迁移到 VPS。

问题：

1.规范化模式能否在不产生性能问题的情况下进行繁重的更新过程？

2.必须对 EOD 数据进行基于 MACD 和 CMF 等流行算法的分析，以发现股票的特定趋势，分析数据必须再次存储以供进一步参考。当天的 EOD 数据更新后，将计算分析数据。那么在这里使用规范化模式很好，保持性能问题吗？我还需要经常获取 EOD 和分析数据！

阐述：

1 个 INSERT 语句（插入 EOD 数据）+ 1 个 INSERT 语句（插入分析数据）

= 2 INSERT 语句* 1500 个股票（用于启动）

= 3000 INSERT 语句完成了 2 回！

随着项目的发展，我进一步计划增加更多库存，因此我也在关注可扩展性。

虽然我不知道 DW 的概念（只听说过），但是如果从性能角度来看，它比 OLTP 更可行，我准备试一试。

我对使用 Microstrategy 报告复杂的雪花 SQL Server 数据库相关的评论和见解感兴趣，该数据库由几个事务性规范化 (3NF) 表组成。

具体来说，在这样的环境中报告的最佳方法或挑战是什么？目前，有一些复杂的视图用作分析事实表，它们在几个事务表之间使用复杂的 SQL 连接。

事务表也有自己的维度，等等。这些视图似乎在 SSRS 中运行良好。但是，我读到 Microstrategy 并不适合针对如此复杂的数据库进行报告（不是因为工具的性能，而是因为在 Microstrategy 中构建这些指标时 SQL 的复杂性）。

在这样的环境中报告的最佳方法是什么？在当前数据仓库上构建 SSAS 多维数据集是个好主意吗？应该在数据库上进行报告，还是应该创建一个新的数据库或集市，专门供 Microstrategy 使用，只有基本报告的相关视图？

任何建议或意见表示赞赏。