最新

今天我发布了关于我正在进行的一个人工智能创业项目的消息——没有薪水，处于非常早期的阶段，“出于热情而构建”。许多人联系了我，但几乎所有人都来自旧金山湾区。西雅图没有一个人联系我。 这让我思考：为什么西雅图的科技文化似乎更倾向于W2（工资）/RSU（限制性股票单位）/稳定性，而湾区则更倾向于冒险和可能性？ 这只是我的个人经历，还是其他人也注意到了这种文化差距？

我的一个朋友通过LinkedIn与我分享了一个Google文档链接。<p>LinkedIn显示了这条帖子的小缩略图以及文档标题。但是，令人失望的是，我发现我无法访问这个文档，因为它被限制在他自己的Google工作区内！<p>哈哈，真是让人困惑！我想这可能是缓存出现了问题？另外，Google是否允许LinkedIn不受限制地访问其Google文档的缩略图和标题呢？

背景：在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的经验，以及对这种方法/挑战的任何意见或见解。希望这个对话能帮助社区中的其他人，欢迎随时问我任何问题。