什么是检索分析服务 TSearch ？
检索分析服务 TSearch 是腾讯云结合海量日志数据和应用实践打造的，专用于日志场景的新一代检索引擎。它采用自研高性能列存引擎替换 Lucene，针对日志场景对 Elasticsearch 检索分析功能进行了深度适配，全面覆盖日志场景下的高频使用需求，拥有丰富的集群管理功能以及安全、弹性、高可用等特性，提供 ES DSL接入方式。大幅降低成本的同时提升读写性能、易用性、稳定性和安全性。
TSearch 适用于什么业务场景？
TSearch 适用于日志场景写多读少、存储量大且周期长的业务场景。
TSearch 性能如何？
TSearch 产品性能优异，与开源 ES 相比：
写入性能：支持向量化解析、物理复制、定向路由等能力，提升写入性能 10 倍以上。
存储成本优化：融合列式存储、摘要索引、压缩编码等能力，单位存储成本降低 3-5 倍。
查询性能优化：融合查询剪裁、二级索引等能力，点查性能与 ES 对齐，分析性能提升 3-10 倍。
生态兼容：兼容 ES API、ELK 生态，支持无缝切换，同时支持 SQL 生态。
按量转包年包月之后多久按包年包月计费？
支付成功后，即时生效。
有未支付的转换订单，升级了集群的配置，转换订单还有效吗？
无效，因为按量付费转换包年包月时会生成一个新购订单，如果您在订单未支付前变更了集群的配置，新购订单金额与集群不匹配，未支付订单会被禁止支付。
在成功购买后，是否支持更换云硬盘的类型？
目前暂不支持云硬盘在不同类型之间进行切换，您可以对数据进行快照备份后，通过快照创建您需要的新类型云硬盘。
TSearch 包年包月退费金额怎么计算？
退款金额 = 当前有效订单金额 + 未开始订单金额 - 资源已使用价值
资源已使用价值按照如下策略计算：
创建集群时，配置多大规格的节点和磁盘合适？
腾讯云检索分析服务 TSearch是分布式多节点形式的集群，每个节点均是有计算和存储两部分构成，您可以根据业务的需求，选择合适的配置。我们强烈建议最好的方法还是需要您在业务的实际使用过程中逐步去探索。依托腾讯云 TSearch 提供的弹性伸缩机制，在业务规模增大，性能遇到瓶颈的时候，您可以随时扩容，调整得到合适的集群规格。如果您在前期对集群规模评估存在问题，您可以直接通过 售前咨询 进行提问，会有专属客户经理在线为您解答。
TSearch 对 ES、Kibana、Logstash 和 Beats 的兼容性如何？
在日志场景下，TSearch 的写入和查询链路通常无需额外适配，整体高度兼容 Elasticsearch 7.10 版本。
您可以继续使用 Kibana 作为数据可视化和分析界面，Logstash 负责日志数据的采集、处理和转发，Beats 作为轻量级采集器将数据从各类源头发送到Logstash 或 TSearch 。
从 Elasticsearch 迁移至 TSearch 有什么推荐的策略吗？
在日志场景下，TSearch 的写入和查询链路通常无需额外适配，整体高度兼容 Elasticsearch 7.10 版本。从 Elasticsearch 向 TSearch 的迁移推荐两种策略：
第一种是双写方案，通过同时写入 Elasticsearch 和 TSearch 实现数据平滑迁移和兼容性验证。待原集群数据自然过期后，业务可逐步切换至 TSearch。
第二种是使用中间件进行数据导入的方式，例如 Logstash 等工具。
几点注意事项：
集群设计方面，建议采用少量大 shard 的模式。TSearch 支持 shard 内并发查询，相比传统的小 shard 并发模型，大 shard 在资源利用率和查询性能方面表现更优。
TSearch 引入 WAL（预写日志）机制，默认每 30 秒刷新一次。对于写入量较大的场景，支持通过攒批写入绕过 WAL 实现数据的快速可见，推荐单批次写入量达到 10MB 以上。
与 Elasticsearch 默认构建所有字段索引不同，TSearch 默认不对字段建立索引。为获得最佳查询性能，建议明确指定需要支持查询的字段并提前设计好索引策略。
在日志类场景中，建议明确主时间字段，并在建索引时将其设置为排序字段，以提升范围查询效率和冷热数据管理能力。
TSearch 支持 DataStream 功能，可按时间进行索引滚动，便于实现数据的生命周期管理，同时支持 mapping 模板的动态更新和索引结构的渐进优化。
集群健康状态异常（RED、YELLOW）如何解决？
当集群存在未分配的主索引分片，集群状态会为RED。该情况影响索引读写，需要重点关注；当集群所有主索引分片都是已分配的，但是存在未分配的副本索引分片，集群状态则会 YELLOW。该情况不影响索引读写，一般会自动恢复。可以通过集群_cat/shards API 确认问题分片，通过 _cat/nodes?h=ip,uptime确认是否有节点重启。
集群整体 CPU 使用率过高问题如何解决？
查询请求或写入请求较大等都有可能导致CPU飙高，需要业务方根据实际情况来优化。您可通过使用集群的监控指标以及集群日志定位问题的根因。
集群磁盘使用率过高和 read_only 状态问题如何解决？
read only 可能是磁盘满、索引级别的 blocks 设置。
当节点磁盘使用率到达集群配置的洪水水位线（默认95%，可以在 _cluster/settings API 进行配置），会导致该节点上所有分片所属的 index 变为 read_only_allow_delete，即不可写状态。可以通过清理集群数据、扩容等方式解决。
写入拒绝或查询拒绝问题如何解决？
写入拒绝是因为写入请求超过了节点处理能力，可以通过检查机器负载是否过高，是否有其他大查询、写入字段数过多等进行问题定位和处理。
查询延时相关的因素包括检索数据大小、查询复杂度、数据分布程度等。
节点负载不均的问题如何解决？
节点负载不均匀可能和索引分片的分配方式、数据倾斜、连接数不均等因素有关，可以检查索引分片数量及分布是否合理，同时可通过监控进行排查定位。
