Quiver best practices（Quiver 最佳实践）¶

The following sections document best practices and considerations to keep in mind when using Quiver, particularly for improving performance.

Analysis structure¶

Quiver uses canvases to display and organize the cards in your analysis. Any content in an inactive canvas tab will not be rendered or queried, so consider splitting the analysis into separate canvases if you have a large analysis with many cards. Similarly, any hidden plot will not be queried; you can hide any plots or charts that you might not need to see but are required for the analysis.

To further reduce compute in your analysis, you can update the Load settings found in the Global settings of the analysis to use Only visible items instead of All items. This change can improve performance for large canvases, but note that cards will load as they become visible. Every time you scroll to a different section of the canvas, you will need to wait for card computations to finish.

You can easily move cards between canvases through the Analysis Contents panel, or you can move a specific card to a different canvas using the Move to canvas option in a card's More actions menu.

Additionally, you can duplicate cards or entire canvases to a new analysis.

Graph mode¶

In graph mode, cards are only computed when their preview is shown. With the compact node design, previews are only displayed when a node is selected or pinned in the preview panel, rather than rendering for all nodes simultaneously. For large analyses, avoid pinning unnecessary previews to reduce compute costs and time.

You can further simplify the graph by using color groups to organize related nodes and collapse or hide groups that you are not actively working with. The filtering tools in the Analysis Contents panel also allow you to narrow down the visible nodes by type, canvas, dashboard, or function.

Transform tables¶

Quiver transform tables are a powerful feature that allows you to perform a batch analysis on objects or tabular data derived from objects. However, transform tables can require high compute. For this reason, the maximum number of rows allowed is 50,000. If your input object set is larger, we recommend using a filter object set to reduce the number of rows before passing it into the transform table.

Because transform table computation is performed in the browser, the performance of certain analyses may vary depending on your hardware (memory size, for example).

Additionally, all transformations in a single transform table are computed sequentially. For example, if you have four numeric formulas, each formula is computed one after the other. This behavior can cause a performance restriction. You can improve performance by parallelizing the computation and dividing the transformations into multiple transform tables.

Transform table computation¶

Transform tables are paginated, meaning that only the viewable rows are computed. For example, if you have 50,000 rows in a table but only 100 are in view, the results are only computed over the viewable 100 rows. However, some operations require that the entire table is computed. These operations include any visualizations or charts, aggregations, and joins.

Sparklines¶

When rendered as a sparkline, each time series cell in a table is computed and billed as an independent query. Because of this, applying a time series operation on all rows can lead to high compute costs. For example, if a transform table has a time series aggregation on 100 rows, the required compute would be equivalent to applying an aggregation on 100 quiver plots.

To improve load performance and reduce costs, you can update the view range setting of the sparkline to limit the size of the compute. By default, time series sparklines always load the "full extent" of the series, with all data included.

Materializations¶

If you are using transform tables without time series or data editing features, consider using materializations instead to improve performance. Materializations offload the computation from your browser and can lead to improved performance on operations such as table joins and aggregations. Materializations also do not have a 50,000-row limit, allowing you to easily work with large-scale datasets. You can switch from a materialization to a transform table at any time without losing the inputs and configurations already added. However, note that transform table operations will likely be slower since they are done in the browser.

You cannot switch from a transform table to a materialization.

:::callout{theme="neutral"} Materializations do not support time series operations; use a transform table if you need to analyze time series data. :::

Object set search around¶

Quiver allows you to search around to linked objects from an object set. If your object set is using Object Storage V1 (Phonograph), your input object set must have fewer than 100,000 objects. If your input object set is using Object Storage V2 (OSv2), the resulting linked object set must have fewer than 10 million objects.

The same restrictions also apply when you're using the filter object set card and trying to filter using linked objects.

Time series¶

By default, Quiver renders 1,000 buckets per time series to improve performance. If you require a more granular view of the series, you can adjust your axis by panning and zooming to the desired time range.

Some time series might take longer to load due to index hydration. However, once a series is hydrated, any subsequent queries will load much faster.

If you are working with a large time series and want to avoid hydrating the entire series, you should first use the filter time series card with an explicit time range filter to reduce the series. Then, compute any future operations on top of that filtered series. This way, the series will only need to be hydrated for the time range you need and not for the full extent.

Time series card performance depends directly on the number of points in the series; consider using sample time series to reduce the number of points. Filtering down to a time range will also speed up compute for any future operations. You can also specify a time range when using the time series search card to speed up performance, since the default search range is for the full series.

Point sets¶

The following cards are not bucketed. Instead, all points involved in the series are recomputed every time you run a calculation based on the series:

With large series, analysis performance can quickly degrade. Quiver has a 25,000-point limit for these time series types, but we recommend limiting the series size to improve performance.

Streaming¶

Quiver has two time series streaming modes: analysis-wide streaming and individual axis streaming. By default, analysis-wide streaming will be activated when pressing the Stream button on an axis. This enables metric cards to update along with the new time series data, but degrades performance due to increased cache clearing. To achieve time series streaming while maintaining optimal performance, enable the Stream individual axis setting in the configuration for each of the time axes in the analysis.

Dashboards¶

When embedding Quiver dashboards in other Foundry applications, you should use tabs as much as possible. Just like canvases in a Quiver analysis, content in inactive dashboard tabs will not be rendered or queried. Splitting your dashboard into tabs as much as possible will improve loading time and performance of the dashboard.

Notepad integration¶

When embedding multiple charts in a Notepad document, use the dashboard widget with the same inputs to reuse the same computation cache and speed up performance.

中文翻译¶

Quiver 最佳实践¶

以下章节记录了使用 Quiver 时的最佳实践和注意事项，特别是关于性能优化的内容。

分析结构¶

Quiver 使用画布来显示和组织分析中的卡片。非活动画布标签页中的内容不会被渲染或查询，因此如果分析规模较大且包含大量卡片，建议将分析拆分为多个画布。同样，任何隐藏的图表也不会被查询；你可以隐藏那些不需要查看但分析中必需的图表或图形。

为了进一步减少分析中的计算量，你可以在分析的全局设置中更新加载设置，选择仅可见项目而非所有项目。这一更改可以提升大型画布的性能，但请注意，卡片会在可见时加载。每次滚动到画布的不同区域时，都需要等待卡片计算完成。

你可以通过分析内容面板轻松在画布之间移动卡片，也可以使用卡片更多操作菜单中的移动到画布选项将特定卡片移至其他画布。

此外，你可以将卡片或整个画布复制到新的分析中。

图形模式¶

在图形模式下，卡片仅在其预览显示时才会进行计算。采用紧凑节点设计后，预览仅在预览面板中选择或固定节点时显示，而非同时渲染所有节点。对于大型分析，避免固定不必要的预览以减少计算成本和时间。

你可以通过使用颜色分组来组织相关节点，并折叠或隐藏当前不使用的分组，从而进一步简化图形。[分析内容面板中的筛选工具也允许你按类型、画布、仪表板或函数缩小可见节点的范围。

转换表¶

Quiver 转换表是一项强大功能，允许你对对象或从对象派生的表格数据执行批量分析。然而，转换表可能需要较高的计算资源。因此，允许的最大行数为 50,000。如果输入对象集更大，建议先使用筛选对象集减少行数，再传入转换表。

由于转换表计算在浏览器中执行，某些分析的性能可能因硬件（例如内存大小）而异。

此外，单个转换表中的所有转换是按顺序计算的。例如，如果有四个数值公式，每个公式会依次计算。这种行为可能导致性能限制。你可以通过并行计算并将转换拆分为多个转换表来提升性能。

转换表计算¶

转换表是分页的，这意味着只有可见行会被计算。例如，如果表中有 50,000 行但只有 100 行可见，则结果仅针对这 100 行进行计算。然而，某些操作需要计算整个表，包括任何可视化或图表、聚合以及连接。

迷你图¶

当以迷你图形式渲染时，表中的每个时间序列单元格都会作为独立查询进行计算并计费。因此，对所有行应用时间序列操作可能导致较高的计算成本。例如，如果转换表对 100 行进行了时间序列聚合，所需的计算量相当于对 100 个 Quiver 图表应用聚合。

为了提升加载性能并降低成本，你可以更新迷你图的视图范围设置，限制计算规模。默认情况下，时间序列迷你图始终加载序列的"完整范围"，包含所有数据。

物化¶

如果你使用转换表但不涉及时间序列或数据编辑功能，建议改用物化来提升性能。物化将计算从浏览器中卸载，可以在表连接和聚合等操作上带来性能提升。物化也没有 50,000 行的限制，让你能够轻松处理大规模数据集。你可以随时从物化切换到转换表，而不会丢失已添加的输入和配置。但请注意，转换表操作可能会更慢，因为它们是在浏览器中执行的。

你不能从转换表切换到物化。

:::callout{theme="neutral"} 物化不支持时间序列操作；如果需要分析时间序列数据，请使用转换表。 :::

对象集关联搜索¶

Quiver 允许你从对象集搜索关联对象。如果你的对象集使用 Object Storage V1 (Phonograph)，输入对象集必须少于 100,000 个对象。如果输入对象集使用 Object Storage V2 (OSv2)，生成的关联对象集必须少于 1000 万个对象。

同样的限制也适用于使用筛选对象集卡片并尝试通过关联对象进行筛选的情况。

时间序列¶

默认情况下，Quiver 每个时间序列渲染 1,000 个数据桶以提升性能。如果你需要更精细的序列视图，可以通过平移和缩放调整坐标轴至所需时间范围。

某些时间序列可能因索引水化而加载较慢。但一旦序列完成水化，后续查询的加载速度会快得多。

如果你处理的是大型时间序列并希望避免水化整个序列，应首先使用筛选时间序列卡片，设置明确的时间范围筛选器来缩小序列范围。然后，基于该筛选后的序列计算后续操作。这样，序列只需在你需要的时间范围内进行水化，而非完整范围。

时间序列卡片性能直接取决于序列中的点数；考虑使用采样时间序列来减少点数。缩小时间范围也会加速后续操作的计算。在使用时间序列搜索卡片时，你也可以指定时间范围以提升性能，因为默认搜索范围为完整序列。

点集¶

以下卡片不进行分桶处理。相反，每次基于序列执行计算时，序列中涉及的所有点都会重新计算：

对于大型序列，分析性能可能迅速下降。Quiver 对这些时间序列类型设有 25,000 点的限制，但我们建议限制序列大小以提升性能。

流式处理¶

Quiver 有两种时间序列流式处理模式：分析范围流式处理和单个坐标轴流式处理。默认情况下，当按下坐标轴上的流式按钮时，分析范围流式处理将被激活。这使指标卡片能够随新的时间序列数据更新，但由于缓存清除增加，性能会下降。为了在保持最佳性能的同时实现时间序列流式处理，请在分析中为每个时间坐标轴启用单个坐标轴流式设置。

仪表板¶

在将 Quiver 仪表板嵌入其他 Foundry 应用程序时，应尽可能使用标签页。与 Quiver 分析中的画布类似，非活动仪表板标签页中的内容不会被渲染或查询。尽可能将仪表板拆分为多个标签页，将提升仪表板的加载时间和性能。

Notepad 集成¶

在Notepad 文档中嵌入多个图表时，请使用具有相同输入的仪表板小部件，以重用相同的计算缓存并提升性能。