Pri*_*ank 7 architecture api database-design middleware aggregation-framework
我们正在为我们的一个财务应用程序构建新的功能集.我们有自己的SQL服务器数据库,我们将调用多个返回JSON响应的RESTful API.例如,一些返回新闻数据,一些返回股票信息,一些返回财务数据,我们自己的sql server数据库有员工数据.因此,它们都有自己不同的数据格式.我们正在构建的这个新应用程序将聚合所有这些数据,将其转换为有意义的显示在网络上,如mint.com.
对于我们的后端和中间层,我们在技术堆栈方面完全开放.首先想到的是像mongodb这样的NoSQL以及用于搜索和报告的弹性搜索.将在这些数据之上构建一个Web应用程序(从API存储或检索),很可能是在Asp.net MVC中.
我们需要您的意见,特别是如果您有建立类似企业解决方案的经验.
你能否分享一下你的意见,
我们有与您提到的类似的设置,使用 ASP.Net MVC 和 ElasticSearch(用于关系数据的 SQL 服务器,定期更新 ES),聚合来自多个源的数据 (XML/JSON),尽管目的是改进搜索和过滤结果而不是报告。但是,我希望您正在查看的场景也适合 ElasticSearch,具体取决于您的具体要求。
1)由于您已经在使用 SQL Server(我希望熟悉它),我建议将其与 ElasticSearch 结合起来 - 就维护另一种技术和开发以适应该集成而言,额外的 mongodb 层似乎是不必要的。有一个非常好的 C# 库(实际上是两个,ElasticSearch.Net和NEST,一起使用),它公开了大部分 ES 功能。
2) 我们选择 ElasticSearch 是因为它具有可扩展性、灵活性和易用性。您可能面临的挑战可能是将文档从 C# 类映射到 ElasticSearch 文档。从本质上讲,它的设置非常容易,但是您确实需要做一些规划,以您想要搜索和检索数据的方式对数据进行索引。因此,如果选择 ES 作为平台,请花一些时间研究文档的结构 - 默认情况下dynamic mapping启用,因此您几乎可以将任何 JSON 放入文档中。但是,对于生产环境,最好将其关闭并设置一个或多个映射,以便可以以标准化方式查询它们。
3) Performance is a key factor for us as well, which is why we were looking at Lucene-based engines like Solr and ElasticSearch when doing research, along with NoSQL databases. ElasticSearch outperforms SQL Server by 10 to 1 or better, in most scenarios. Solr vs. ElasticSearch performance depends on scenario, benchmarks and comparisons are around if you Google them. The exception may be if many documents should be retrieved in one query - ES (or Lucene) is not made for that use case, it's best for fast retrieval of fewer results (similar to Google's per page results count) per page. If you need 1000 documents per page/result, a NoSQL database may be a better option.
ElasticSearch is fast to get up and running - install it on a local development box and try it out, you'll get a feel for if it fits.
| 归档时间: |
|
| 查看次数: |
1062 次 |
| 最近记录: |