问题标签 [oltp]

我们正在设计一个典型的 OLTP 应用程序（想想：采购系统）。然而，这个特别需要一些用户离线，所以他们需要能够将数据库下载到他们的机器上，在它上面工作，然后一旦他们在 LAN 上同步回来。

我想指出，我知道这已经做过，我只是没有使用这个特定模型的经验。

我想到的一个想法是使用 GUID 作为表键。例如，采购订单不会有数字（自动数字），而是有一个 GUID，因此每个离线客户端都可以生成这些，并且当我连接回数据库时不会发生冲突。

出于某种原因，这是一个坏主意吗？通过 GUID 键访问这些表会很慢吗？

您有使用过这类系统的经验吗？你是如何解决这个问题的？

谢谢！
丹尼尔

我正在处理的 OTLP 项目遇到 Db 性能问题。我和另一位开发人员已经达到了我们积累的性能知识的终点，并寻找个人加入团队以帮助我们加快应用程序的速度。

对于某些背景，我们已经完成了架构更改以对数据片段进行非规范化，优化每个查询，运行多个数据库调整顾问以使我们的索引正确，调整 MSSql 的服务器选项。

我们不需要有人进来告诉我们加入可能很慢以及什么是死锁，我们需要在用尽上面列出的所有步骤后知道该做什么的人。

任何人有任何雇佣 OLTP DBA 的技巧或经验可以分享吗？在面试过程中我们可以问 DBA 什么样的问题？

这是一个奇怪的情况，我们知道我们需要比当前团队了解更多的人，但我们不知道要问什么问题，因为我们不知道下一步是什么。那有意义吗？

将典型实体关系 OLTP 数据库模型中的数据加载到 Kimball 星型模式数据仓库/集市模型中时采用了哪些常见设计方法？

• 您是否使用暂存区执行转换然后装入仓库？
• 如何在仓库和 OLTP 数据库之间链接数据？
• 您在哪里/如何管理转换过程 - 在数据库中作为 sprocs、dts/ssis 包或来自应用程序代码的 SQL？

我正在寻找有关 SQL Server 如何更详细地实际处理查询执行的信息（例如缓冲区/内存中保存的数据以及即使仅涉及表的一列中的更新更改，它如何决定获取新数据在查询等）

如果有人知道来源，请告诉我？

我们有一个使用 sql server 2000 的 Web 应用程序，它每 30 秒会频繁读取几乎 70% 的表（仪表板）。同时发生了大量的写入。

请让我知道优化上述场景的任何提示？

我有一个在多个大洲使用的网络应用程序。运行大型报表时，底层事务数据库处于锁定状态。我想要：

1. 将 SQL Server 2005 数据库实时生成到报告数据库
2. 将所有报告定向到报告数据库

理论上，这将防止插入和更新的事务锁定。只要事务继续，如果报告数据库被暂时锁定是可以的。报告数据库在负载较轻时可以接收新事务。维护事务数据库的近实时副本的最佳方法是什么？我应该使用复制、镜像还是两者的结合？我应该遵循哪些一般准则？

谢谢！

我工作的公司生产一个内容管理系统 (CMS)，其中包含用于出版、电子商务、在线打印等的各种附加组件。我们现在正在添加“报告模块”，我需要调查应该采用哪种策略被关注。“报告模块”也称为商业智能或 BI。

该模块应该能够跟踪项目下载、执行的搜索并从中生成各种报告。实际上，搅动什么样的数据并不重要，因为从长远来看，我们可能希望能够推送我们认为需要的任何内容并从中获取报告。

粗略地说，我们有两种选择。

选项 1是基于 Apache Solr 编写解决方案（特别是使用https://issues.apache.org/jira/browse/SOLR-236）。这种方法的优点：

• 免费/开源/优质
• 我们在其他地方使用 Solr/Lucene，所以我们非常了解这个领域
• 由于我们可以获取传入数据（以 XML 格式），通过 XSLT 推送并将其提供给 Solr，因此对索引的内容具有完全的灵活性
• 如何显示搜索结果的完全灵活性。与上述步骤类似，我们可以自定义 XSLT 搜索模板并以我们认为必要的任何格式显示结果
• 我们的前端开发人员精通 XSLT，因此为不同的客户安装这种机制应该相对容易
• Solr 提供对我们来说绝对必要的实时/全文/分面搜索。一个快速原型（基于 Solr，1M 记录）能够在 55 毫秒内提供搜索结果。我们估计的最大记录数约为 10 亿行（这对于典型的 BI 应用程序来说并不算多），如果情况变得更糟，我们可以随时查看 SolrCloud 等。
• 有些公司使用 Solr 做非常相似的事情（例如，Honeycomb Lexicon）

这种方法的缺点：

• SOLR-236 可能稳定也可能不稳定，此外，尚不清楚何时/是否将其作为官方发布的一部分发布
• 我们可能需要编写一些东西才能使某些特定于 BI 的功能正常工作。这听起来有点像重新发明轮子
• 最大的问题是我们不知道将来可能需要什么（例如与某些 BI 软件集成，导出到 Excel 等）

选项 2是与一些免费或商业的 BI 软件集成。到目前为止，我已经查看了Wabit并将查看QlikView，可能还有其他人。这种方法的优点：

• 无需重新发明轮子，软件（希望）经过尝试和测试
• 将节省我们的时间，我们可以花在解决我们擅长的问题上

缺点：

• 因为我们是一家 Java 商店，而且我们的解决方案是跨平台的，所以我们必须消除市场上的很多选择
• 我不确定 BI 软件能有多灵活。一些 BI 产品需要时间来查看它们是否可以进行灵活的索引、实时/全文搜索、完全可定制的结果等。
• 有人告诉我，开源 BI 产品还不够成熟，而商业 BI（SAP 等）成本很高，它们的许可证从数万英镑/美元开始。虽然我本身并不反对商业选择，但它会增加整体价格，很容易变得太大
• 不确定 BI 处理无模式数据的效果如何

我绝对不是在市场上找到最合适的集成选项的最佳人选（主要是因为缺乏 BI 领域的知识），但是需要快速做出决定。

有没有人遇到过类似的情况，可以建议采取哪条路线，甚至更好 - 就选项#2的可能利弊提供建议？这里最大的问题是我不知道我不知道什么;）

使用 WCF 实现 OLTP 系统是个好主意吗？系统必须每秒处理 5-8k 个请求。

好吧，除了这个问题，没什么可问的。当您说 OLTP DB 必须具有高吞吐量时，您是什么意思。

去维基。

“在通信网络中，例如以太网或分组无线电，吞吐量或网络吞吐量是通过通信信道成功传递消息的平均速率。这些数据可以通过物理或逻辑链路传递，或通过某个网络节点。吞吐量通常以每秒位数（bit/s 或 bps）为单位，有时以每秒数据包或每个时隙的数据包为单位。”

那么这是否意味着，OLTP 数据库需要具有高/快速的插入率（即避免死锁等）？

如果我们以航空业为例，我总是有这样的印象，它必须具有快速插入，但同时又要快速响应，因为它对其运营至关重要。在许多方面，这不应该仅限于将消息/数据传递到数据库所涉及的协议吗？

我并不是要挑出 OLTP 系统的“唯一”特征。一般来说，我想了解 OLTP 系统固有的特性。

干杯!

我们正在设计一个 OLTP 财务系统。它应该能够支持每秒 10.000 笔交易并具有报告功能。

所以我们想到了使用：

• 一个 NoSQL DB 作为我们的主要存储
• 一个 MySQL 数据库（实际上是 Percona 服务器）从 NoSQL 数据库生成一些 ETL 以存储报告数据

我们正在考虑将 MongoDB 和 Riak 用于 NoSQL 作业。我们读到 Riak 比 MongoDB 更平滑地扩展。我们想听听您的意见。

• 您会将哪个 NoSQL DB 用于 OLTP 金融系统？
• 您扩展 MongoDB/Riak 的经验如何？

我有点混淆了我从 Wiki 中读到的用于制作 OLAP 的 Hadoop 配置单元。现在我想从使用 Mysql 的 OLTP 数据库在 Hive 上制作 OLAP。

我怎么能解决这个问题？我可以在 Hive 中使用 Kettle 制作 OLAP 吗？任何指导如何从 OLTP mysql 在 Hive 上制作 OLAP？

谢了。