快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

我们使用CosmosDB而不是关系数据库,这是经历和学习的

请联系QQ:1793040 索取软件

大约两年前,我们进行了一个相当大的项目。如果一切进展顺利,我们正在谈论来自世界各地的用户的潜力;以及?一个非常复杂的领域,对产品的目标意义重大。

我参与了解决方案体系结构的设计,除数据库外,其他所有问题都得到了同意。考虑到实体之间关系的复杂性,我建议使用Azure SQL并找到一种使用Elastic Database工具进行水平扩展的方法。在表的另一端,决定使用CosmosDB,为什么?主要是由于以下原因:

  1. 快速。我们保证某些查询会快于10ms。
  2. CosmosDB提供了几乎轻松的扩展。设置分区键,编写几行代码来处理分区,然后就可以了。
  3. 由于我们正在处理多租户,因此我们发现CosmosDB的分区可以帮助我们正确隔离每个租户的数据。

当我仍称为DocumentDB时,我就一直在研究CosmosDB。我从来没有想过可以用NoSQL数据库完全替换关系数据库,但是,如果您正确执行它或复杂性允许的话,您仍然可以拉它。关键是正确地对实体建模,您应该确定何时需要引用或嵌入,这完全取决于数据的波动性。我为我的想法准备了一个三明治,并告诉我我们将使用CosmosDB。我们做了肮脏的工作,这是我们经历的:

  1. 存储过程在它们自己的事务上运行。您不能编写将运行多个存储过程并在出现问题时回滚所有更改的事务。
  2. SQL引擎并不是您熟悉的所有SQL。SQL语句非常有限,并且JOIN不能像您从关系数据库中知道的JOIN那样工作。您不能进行交叉收集查询。
  3. 那时,SDK不支持那么多LINQ语句。我们很难实现分页。当前,支持更多的LINQ语句,并且SQL引擎引入了OFFSET LIMIT语句。
  4. 分区可能会妨碍您的查询。我们的应用程序中有很多过滤器。有时我们需要重组分区以容纳过滤器,或者完全说我们不能做那些过滤器,因为分区禁止了我们。
  5. 您必须处理错误429。我不会对此深究,它需要另一面文字。从根本上讲,这意味着您的集合正因请求而超载,您必须处理此错误并重试请求。SDK可以帮助您自动处理,也可以为更多请求单位支付更多费用。
  6. 热分区。我们尝试了请求单位(RU)的自动缩放功能。想法是,当我们达到阈值时,将自动分配更多的RU,并且在不需要时会回落。仍然会遇到很多错误429,发现我们遇到了热分区。开发人员设置的分区键是逻辑分区,然后将其映射到物理分区,这些物理分区占用一定数量的RU。如果物理分区的RU用完,则对映射到该物理分区的所有逻辑分区的所有请求将导致错误429。
  7. 我个人坚信,除非您是肮脏的有钱人并且愿意付出代价,否则您不可能没有错误429的生活。我们优化了代码,进行了缓存,并实现了自动缩放。我们仍然会收到429错误,而成本并未真正下降。

我从未确信CosmosDB是正确的方法。我们花了太多钱,对此我们不能做太多。我们无可救药地梳理了诊断日志,以找到一些线索,甚至不屑一顾地为我们提供了甚至毫无意义的问题的答案。直到我离开的那天,我们仍在尝试使用CosmosDB并为此掏腰包。通过经验,这是我们意识到的:

  1. CosmosDB实际上确实通过分区提供了轻松的扩展。
  2. 如果您不对数据做任何花哨的事情,那对您来说真的会很高兴。如果您有要在显示时存储或在存储时显示的数据,则可以真正受益于CosmosDB承诺的速度。
  3. 如果您只需要直接存储大量数据,则可以利用通过分区扩展存储的轻松程度。我们还拥有其他项目,CosmosDB真正取得了回报。我们有一个物联网项目,该项目使用CosmosDB节省了大量遥测。该团队能够扩展数TB的数据,而不会费心费力地担心存储。
  4. 您可以创建集合触发器,并在需要事件驱动的情况下使用更改提要处理器。
  5. 对于业务逻辑严重依赖实体关系的域,您无法用NoSQL数据库完全替换关系数据库。

就这样。我确实相信CosmosDB是一个很棒的产品。通过正确的设计和适当的文档资料,开发人员可以真正受益于速度和几乎无痛的存储扩展。让我知道如果我错过了什么,您同意还是不同意我的想法,我们将进行讨论。


免责声明:这篇文章并不是要对CosmosDB进行负面批评或说服开发人员远离它。CosmosDB是一个非常好的NoSQL数据库,并且在正确实现上有很多好处。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1793040