返回首页
一周热榜
我设计了一套小型实践练习，旨在教授如何构建和调试具有各种功能的LLM代理。这套练习可以在本地运行，涵盖以下任务：<p>- 一般的LLM风格聊天：数学问答<p>- 工具使用：使用工具进行哈希<p>- 图像理解<p>- 网络浏览：（井字棋）<p>- 代码生成与执行<p>- 跨会话记忆<p>这个项目的目的不是进行基准测试，而是为开发者提供实用的训练，以便了解代理在何处成功或失败。这对教育、研讨会或自学都非常有用。<p>欢迎反馈其他可能使其更有用的练习。<p>在这里尝试：<a href="https://ape.llm.phd/" rel="nofollow">https://ape.llm.phd/</a>
背景：在RudderStack，我成功地使用Postgres处理事件流用例，扩展到每秒10万个事件（注意：选择Postgres而非Kafka有其合理原因）。尽管如此，我们仍在继续探索优化的机会。因此，我和我的团队开始尝试使用Pulsar（仅针对我们系统中的数据摄取部分）。
我们对比了使用Apache Pulsar进行数据摄取与为每个客户设置专用Postgres数据库的效果（一个客户可以拥有一个或多个Postgres数据库，所有数据库都是主节点，无法共享数据，每次扩展操作时都需要手动迁移数据）。
现在使用Pulsar已经有一段时间了，我觉得可以分享一些关于用Pulsar替代基于Postgres的流处理解决方案的经验，希望能从大家的意见和见解中学习。
----
我喜欢Pulsar的地方：
1. 租户隔离非常可靠，自动负载均衡效果良好：到目前为止，我们没有遇到过一个活跃的租户影响到其他租户的情况。我们使用同一个集群来处理所有客户的数据（按地区划分，一个在美国，一个在欧洲）。多租户功能结合集群自动扩展使我们能够控制成本。
2. 不再有单点故障（数据在多个bookie中复制）：数据现在至少在两个bookie中复制。这使我们在数据丢失方面变得更加可靠。
3. 维护更简单：不再有单一主节点的限制，这简化了很多基础设施的维护（想象一下将一个Postgres pod迁移到不同的EC2节点，这可能导致停机）。
----
Pulsar的痛点：
1. StreamNative的许可费用相当高。
2. 随着多可用区和复制，网络成本显著增加。
3. 学习曲线比预期陡峭，调试也更复杂。
----
我很想听听你们对Postgres/Pulsar的经验，以及对这种方法/挑战的任何意见或见解。希望这个对话能帮助社区中的其他人，欢迎随时问我任何问题。