如何获得讲师PPT：
扫码关注公众号，后台回复「Q104」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
1、时间线可以到亿级么？
在我们当前的生产线中，我们已经达到了千万级别的生产能力，这是我们已经成功验证过的能力。对于更高千亿级别的需求，我认为也完全没有问题。前面已经提到，我们当前已经将最重的倒排完全忽略，这意味着用户的写入查询不会带来任何额外的代价。无论是亿级还是十亿级，都不会有什么问题，因为我们的系统不存在线性膨胀的困扰。
2、在高基数场景下，时间线量级很大的话，怎么确保倒排索引在内存中的有效存储？
关于这个问题，我刚才已经提及，我们这边并没有采用倒排。实际上，我们跳过了倒排这一步。尽管我们也计划在一些低技术要求的场景中保留倒排，因为倒排确实是一种有效的查询加速手段。但在高技术要求的场景下，我们更倾向于直接不保存倒排。而是通过一系列列存索引结构，比如我刚才提到的M max和波动过滤器等概率性索引结构来解决高基数数据的写入和查询问题。这些概率性索引结构的体积相对较小。因此，在高基数的场景下，我们选择拒绝使用倒排，只在低基数的场景中选择性地构建倒排。
3、补充提问Q2：是否有特定的数据结构或算法来优化内存使用？
关于倒排的优化思路，目前业界和学术界确实存在一些通用的手段，但我认为这些手段并没有特别创新之处。例如，通过bitmap来压缩倒排，以减少内存的使用。然而，这种方法并未解决本质性问题。随着倒排数量的增加，仅仅通过减少内存使用的方式并不能从根本上解决问题。虽然这些方法能在一定程度上降低内存消耗，但效果并不理想。因此，我们还需要寻找更为有效的倒排优化策略。
4、缓存解压后的数据块，会不会导致cache利用率不够高？比如解压前可以缓存100个，解压后只能缓存10个了（压缩比为10）
这位同学观察得很细致，确实存在这个问题。数据压缩与缓存之间存在天然的矛盾。针对此问题，我们采取了一种多级缓存的策略。具体来说，我们设计了两级缓存：一级是基于内存的缓存，另一级则是基于磁盘的缓存。这样的设计能在一定程度上解决数据放大的问题。当数据容量增大时，我们会根据LRU算法优先将部分数据淘汰至本地磁盘。这种分级的索引和缓存机制，首先利用程序内的内存缓存，当内存不足时，再转向磁盘缓存，最终还有OSS作为后备。我们的思路是通过这种多级缓存的方式来有效解决问题。
5、（分布式方案）提到的对象存储作为持久化层，具体怎么保证数据的可靠性、一致性？对时序数据做了特殊优化？
对象存储本身具备高可用性，因此无需我们额外保证。对于实时写入的数据，在内存中但尚未刷新到对象存储的部分，我们采用LSM组件中的WLL来确保高可用。虽然本次分享重点是查询，未深入讲解WLA，但WLL作为分布式组件，确保了写入WLL的数据也具备高效用。我们可以基于卡夫卡实现WLL，从而保障内存中的数据高可用。
关于时序优化，我认为关键在于实际数据的可用性需求。有些数据可能并不需要高可用性，因此我们可以考虑省略WLL环节。通过在内存中进行取舍，牺牲部分数据的高可用性，以实现更高的写入存储效率。因为写入共享WLL本身也会带来一定开销。
6、动态扩容，新加入的实例怎么能够快速地接入、处理数据？
目前，我们仍然采用手动方式来进行扩容。尽管我们有计划实现自动扩容逻辑，但这一功能仍在开发中，尚未完成。我们的扩容过程相对简单，由于数据存储在底层的对象存储中，因此在扩容过程中无需移动数据。所有数据都位于远端，我们只需根据监控指标发现热点机器后，直接启动两台新实例。在短暂的机器旋转时间后，即可实时进行扩容，因为只需同步WL数据即可。通常，需要同步的数据量很小，主要是最近一两分钟的数据，同步速度较快。
要实现自动化扩容，我们可以利用ETCD等机制。例如，通过上报每个节点的状态信息（如CPU和内存使用情况）给meta，让meta自动触发扩容操作。当然，在决策过程中可能需要权衡各种因素，如采用何种策略、达到何种阈值才进行扩容等，这可能需要一定的经验值来进行判断。
7、请问OSS拉取数据性能瓶颈是怎么解决的？
这位同学提到的缓存和并发，在我们当前业务中至关重要。针对冷查询的优化，我们仍有改进空间。针对应用持续性的特点，最新的数据查询较多，因此可以考虑预取最新数据，而非事后缓存。理想情况下，我们希望能缓存最近的所有数据，以减少对最新数据的查询压力。对于历史数据，我们可通过降低精度来优化大量数据的拉取能力。
综上所述，针对热门数据，我们将通过预取方式提高实时性；对于历史数据，则采用降低精度的方法来简化数据拉取流程。这将是我们后续的优化方向。
8、LRU缓存替换策略可以展开讲一下吗？
这位同学似乎对数据库的细节有一定了解，他提到LRU在某些情况下可能不够理想。确实，当线上查询负载较大时，尤其是当发生全表扫描时，LRU的效果可能不佳。因为全表扫描会污染LRU缓存，导致缓存中存储的数据可能不再是最热门的，而真正需要的数据则可能被淘汰。
我认为他可能想探讨的是这个问题。针对此，我们虽然还未采用业界更高效的算法如LFU，但已根据业务特点进行了定制。例如，当我们识别出某个查询是全表扫描时，我们会使用LRU缓存但不调整其频率。这意味着我们仅利用缓存而不更新其指针，从而避免全表扫描导致的缓存失效问题。目前，这种方法在我们的系统中运行尚可接受。 然而，正如之前提到的，业界还存在更高级的缓存策略。我们计划后续进行调研，以寻求更优化的解决方案。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫