我有一台运行 Cassandra 的物理服务器。鉴于 Cassandra 在胖节点上表现不佳，哪种策略更好：
- 在服务器上运行单个大型节点（将所有资源分配给该实例）
- 在服务器上运行多个较小的节点并模拟集群（将资源拆分到实例）
提前致谢。
当我们将自动调整设置为 ON 以创建索引时，Azure SQL Hyperscale db 已为我们的一些大型表创建了大约 10 个索引。在分析索引时，其中一些仅在“包含”列中有所不同，而索引列相同。这种索引激增将损害此类表上的 INSERT、UPDATE 操作。
Azure 中是否有合并/优化索引的选项，而不是我们手动删除并重新创建许多表的更好索引？截至目前，关闭自动索引创建似乎是唯一可行的方法。
还有其他建议吗？
我正在查看我的只读副本数据库的Query Performance Insight 。但它显示的信息是来自主数据库的性能统计数据。如何获取只读副本的性能统计信息？
如果某列有索引，如果条件是，是否会加快搜索速度... WHERE column IS NULL？实际上它是 2 列的复合索引，第二列可以为 NULL ( WHERE col1 = X AND col2 IS NULL)。
最近，我的 mariadb 崩溃了，这引发了一场噩梦。当我恢复转储时，有时守护进程会在批量插入期间挂起。这种情况只发生在少数“大”innodb 表上（我有许多小型数据库，它们实际上不包含太多数据，而大多数其他数据库仅在少数表中包含大量数据）。数据库通常最终会恢复（有时在几个小时后），但有时会崩溃。我在几分钟之内就在另一台机器上恢复了数据库，没有出现任何问题，然后将数据目录移动到生产机器上。两者之间唯一的严重区别是成功的机器不是虚拟机和运动 SSD 存储。
从那时起，所描述的问题仍然在随机时间发生，并且总是在访问这些大表时发生。一般来说，我会冻结多个查询，但有时只有一个查询就足以触发该行为。
我发现实际上很难相信的是，iotop 报告了一个 mariadb 线程在查询挂起的整个过程中每秒稳定地写入千兆字节。这在物理上是不可能的，因为磁盘的性能甚至无法接近这些数字。我还搜索了互联网以找到可以优化设置的方法，直到几天前，这些设置似乎非常适合我的环境，我调整了一些变量，但没什么大不了的，“导入成功”机器上的默认值也没有太大不同首先。
这个问题与https://jira.mariadb.org/browse/MDEV-30884类似，但是自从我在 Gentoo 上使用 10.6.14（我也测试了 10.6.15）以来，这个问题应该已经得到解决。
我很茫然，这可能是什么原因造成的？机械硬盘存储能否以某种方式证明正在发生的事情是合理的？
我正在将 SSIS 包从 SQL Server 2012 迁移到新的 2022 服务器。该包在循环内使用执行包任务来运行项目中的另一个包。我发现第一次运行执行包任务时似乎需要相当长的时间才能启动，并且我不知道为什么或在哪里寻找原因。
主包的相关部分是这样的：
从执行时间来看，第一次调用通用解析包需要 10 多秒（最后一列以毫秒为单位），但该包的组件只花费了该时间的一小部分。通用解析的后续执行（也显示在结果中）按预期运行，没有初始延迟。
我在私有云环境中部署了CoC版本的PieCloudDB。我的 S3 服务由三台机器组成的集群。在部署PieCloudDB数据库的过程中，我指定其中一台机器作为S3主机。现在，在查询过程中，我发现该特定主机上出现了 S3 网络瓶颈。如何解决这个瓶颈问题？
我们被分配了一个新的应用程序，供应商预计数据库将增长到 100 TB 左右。他们提到 SQL Server 标准版是兼容的。
我的问题是 SQL Server 标准版是否能够充分处理这种大小的数据库？
企业版可以处理在线索引重建，但是SQL Server总体上可以处理这么大的数据库吗？
我管理的最大数据库是 3 TB，我担心 100 TB 的数据库在 SQL Server 2019 上的表现如何。
专家的任何建议将不胜感激。
我的基本问题是：什么影响了性能\d？
我有一个单独的（小）模式，在数据库服务器上管理，否则我没有更高的权限。服务器在其公共模式中拥有一个巨大的（十亿多行）数据库。我的单独模式提供了一些辅助信息，仅用于公共模式中数据的网页呈现。
编辑：实际上有超过 55 亿行，而且这只是最大的表之一（并且只花了 1.5 小时就完成了count(*)！）。
当我\d在 psql 提示符下执行一个简单的操作时，它真的很慢 - 当我计时时大约需要 6.5 秒。显然，数据库/数据库服务器负载很重，但是我应该让\d系统管理员（他们通常不想被打扰）注意这种性能吗？（这是否意味着系统中存在明显错误？）我的架构中的其他所有内容都以毫秒为单位运行，因此它不会影响我的架构本身的性能。
无论我是否引起他们的注意，什么会影响 的性能\d？公共模式有 985 个表。即便如此，这似乎是一个相当简单的查询；我希望它只查看表名称，而不查看表内容。
我在 Windows Server 2019 标准核心上有一台 SQl server 2019，我管理两种类型的备份，一种带有维护计划，另一种带有 Veeam Backup。维护计划没问题，Veeam 的备份每天都会失败，并出现 SQL 错误，使 SQLServerWriter 处于失败状态，最后一个错误为不可重试错误。我已经在 Veeam 支持上开具了一张票，我们已经了解了变化日志，但问题与 Veeam 无关，因为即使使用 vss 命令创建备份也会出现错误。根据日志，备份作业失败并出现错误：
[11.09.2023 00:07:12] <01> Error Failed to create snapshot: Backup job failed.
[11.09.2023 00:07:12] <01> Error Cannot create a shadow copy of the volumes containing writer's data.
[11.09.2023 00:07:12] <01> Error A VSS critical writer has failed. Writer name: [SqlServerWriter].
在VSS编写器中，可以观察到错误：
Writer name: 'SqlServerWriter'
Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
Writer Instance Id: {1fb6de2a-c593-45c2-b592-e90ff6aad393}
State: [8] Failed
Last error: Non-retryable error
在 Windows 应用程序事件中可以观察到以下错误：
Log Name: Application
Source: SQLWRITER
Date: 11.09.2023 0:07:05
Event ID: 24583
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQL03Core
Description:
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 3224
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: Cannot create worker thread.
Log Name: Application
Source: SQLWRITER
Date: 11.09.2023 0:07:05
Event ID: 24583
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQL03Core
Description:
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 3202
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: Write on "{7F86B757-DC6E-4B76-B35D-F382797EB665}414" failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)
服务器有 536 个数据库和 8 个核心，因此 Veeam 支持认为问题与工作线程数量不足有关，因此根据 https://learn.microsoft.com/en-us/sql/database-engine /configure-windows/configure-the-max-worker-threads-server-configuration-option?view=sql-server-ver16，我们已将工作线程数更改为 1000，但错误继续出现，因此 Veeam 支持建议帮助根据负载优化机器和线程。
任何人都可以建议一种处理方法吗？抱歉我的英语不好，提前谢谢...斯特凡诺