我正在开发一个使用 SignalR 的应用程序来管理 Websockets 并允许我的客户端相互对话。
我计划在 Azure 辅助角色上托管此后台。由于我的 SignalR 请求携带的数据大部分时间保存在数据库中,我想知道 NoSQL 的 MongoDB 而不是经典的 SQL Server/Entity Framework 对是否应该是一个好方法。
假设我的应用程序的数据类型大部分都是字符串,我认为 MongoDB 将是一个可靠且高性能的解决方案,它将使我摆脱 Azure SQL 的数据库成本。
仅供引用,Azure 辅助角色将在具有以下硬件的计算机上运行:1 核 CPU、3.5GB RAM 和 50GB SSD 存储。
您认为我在这个架构上有一个良好的开端吗?
谢谢
最佳答案
Do you think I m on a good start with this architecture?
一句话,不。
用户提出了有关在辅助角色上运行 Redis 的类似问题 - Setting up Redis on Azure cloud service worker role - 该问答的所有内容都与 MongoDb 上下文相关。
我建议您阅读我的答案,因为它更详细,但作为为什么这是一个糟糕的架构方法的概述:
- 您无法保证 Azure Service Fabric 何时重新启动辅助角色。
- 在 Mongo 的实际实现中,您将在一个集群中运行多个节点,并使用单个辅助角色(正如您在问题中所建议的那样),这是不可能的。
- 您将需要在辅助角色中管理您的 MongoDb 安装,而它们根本不是为此而设计的。
如果您确实决定使用 Mongo,我建议您使用托管解决方案,例如 MongoLabs(如前面的答案中所建议),或考虑将其托管在 Azure IaaS VM 上。
如果您不固定使用 Mongo,我真诚地建议您查看 Azure DocumentDb(上面也有建议),这是 Microsoft 的 Azure NoSQL 产品 - 我已经在多个生产系统中使用过它,它无疑是一个功能强大的 NoSQL 解决方案;当然,它可能不具备 MongoDb 提供的所有功能。
如果您正在寻找用于缓存数据的 NoSQL 解决方案(即不是长期存储),我建议您看看 Azure Redis 缓存,这是一个非常强大的 Redis 产品。
关于entity-framework - Azure 上的 MongoDB 辅助角色,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32781514/