展开讨论

BrentOzarHN来源作者
创业与收入经验摘录 · 机器翻译

在微软SQL Server领域，这些供应商中有许多已经出现又消失了

在微软SQL Server领域，这些供应商中有许多已经出现又消失了。我的客户曾被它们严重伤害过，所以有一些快速的经验教训：要注意有数百个开放的问题[0]和几十个拉取请求[1]，其中一些涉及客户无法连接或不支持SQL语言的所有组件。即使你的数据库支持某项功能，并不意味着你的缓存层也会支持。当数据库的新版本发布，带来全新的功能和语言增强时，情况会变得非常糟糕，而缓存层却不支持这些新功能。在某些情况下，缓存层可能需要数月甚至数年才能与底层数据库的功能完全同步。如果你想使用这些语言增强功能，那么你的应用程序可能需要维护两个连接字符串——一个用于缓存层，另一个用于缓存层不支持的直接数据库查询。你的支持团队需要学习如何诊断缓存层的问题。…

源讨论Readyset：一个与MySQL和Postgres兼容的缓存层原帖 69 条评论 · 导入时统计
3

社区评论 0

还没有社区评论，来聊聊你的看法。

原讨论中的回复 3

仅展示本次导入中包含的直接回复。中文为机器翻译，可查看英文原文。

GI
gilbertbwHN

关于新的数据库版本的问题，我想知道为什么缓存层不能将它无法处理的任何查询传递给底层数据库呢？ 如果你们使用的一个功能不能返回正常的查询结果（例如Postgres中的发布/订阅支持），那就会更复杂一些。

完整原文
HO
hobofanHN

我认为把开放的问题和拉取请求的数量拿来指责他们是不公平的。随便看看这些问题，看起来95%以上都是他们自己团队成员提出的，而且很多问题都是“低优先级”的。所以你看到的只是通常存在于私有JIRA实例中的不断增长的待办事项清单。 不过，他们处理拉取请求的方式确实是我见过的最特别的。我看到他们使用了一个合并机器人，除此之外所有的分支名称都完全无法理解。由于很多团队成员似乎都参与了这个讨论，如果能了解一些这方面的细节会很有趣。

完整原文
GW
gwbas1cHN

他们使用数据库的复制API。理论上，这应该可以避免缓存无法理解查询语法的情况。 但，我担心的是应用程序需要缓存一个构建成本很高的对象的情况。（也许构建成本高是因为程序员不理解如何优化SQL。）

完整原文
在 Hacker News 阅读

尊重不同观点，分享具体经验。

登录后即可发帖、评论、转发和引用。