Django和Rails有一个常见的DB [英] Django and Rails with one common DB
问题描述
我现在必须构建一个新的网络应用程序。
它将有一个集中的数据库。
将有两种不同类型的网络应用程序实例。
Web-App 1：
a）它没有任何UI渲染，没有html，js等
b）所有它需要给的是一些休息API将
b.1）在DB
中创建一些新条目b.2）修改DB
b.3中的某些条目）以JSON格式检索一些数据库记录。
某些前端代码（不属于此应用）将定期获取
此详细信息。
c）它将被最多100,000个人使用，但在给定的时间点，
我们可以期望大约1000个用户登录，并在b）
Web-App2：
a）它将有一些仪表板
b）90％的DB操作将被读取操作
c）10％的DB操作将被写入/修改
d）将有大约1000s该系统的用户在任何给定的时间点
几乎不会有50-1000人访问它。
我正在考虑关注。
在RoR中创建的python + Django和Web-App 2中创建了Web-App 1。
我打算用Dynamo DB和memcache。
为什么有两种不同的框架？
1）所以我学习了这两个
2）RoR中的可扩展性受到关注（我也知道人们声称它不在那里），Web-app 1将来可能具有扩展需求。
我的问题是你看到这个组合有什么问题吗？
例如活动记录会让你为您的数据库表使用特定的namings格式？还有其他类似的问题吗？
任何人谁使用过类似的技术堆栈？
这两个框架都是全堆栈框架并提供MVC，模板，单元测试，安全性，数据库迁移，缓存，安全性，ORM。
对于我的创业公司，我们还需要推出一个完整的网站和API。我们还使用DynamoDB存储大部分数据，只使用MySQL进行会话信息。
我选择使用Ruby on Rails作为Webapp和Sinatra的API 。如果您的标准只是尽可能多地学习新的东西，那么选择相对不同的堆栈（django / python和RoR）是有意义的。在我们的例子中，我们去了sinatra，因为它本质上是一个非常轻巧的包装机架，并且完美适用于基本接收请求，调用一个或多个服务或进行一些处理并执行格式化响应的API。虽然我没有看到使用python / django而不是sinatra的任何问题，但在我们的例子中，好处就是花费更少的时间来处理不同的语言。
另外，rails的可扩展性是一个iffy主题。最后，它是关于你如何使用它。我们没有问题用独角兽和nginx进行缩放。我们的业务逻辑全部在API服务中，rails服务器也使用API进行大部分工作。这意味着我们不会在栏杆上使用活动记录，网站只是我们API的另一个消费者，无论请求是来自应用还是网站，都是很重要的。使用MySQL进行会话存储可以确保我们可以将请求路由到任何应用程序服务器，而无需担心每次都会将来自同一客户端的请求从同一客户端路由到同一台服务器。这样我们就可以轻松地上下滚动，只要考虑到我们得到的流量。
当我们开始工作时，没有一个ORM对于发电机db，它看起来和感觉就像活动记录一样，所以我们最终写了几个我们自己的高级类来处理DynamoDb上的模型的存储和检索。考虑到DynamoDB不适合扫描或连接，因为我们几乎总是根据键和范围进行查找，所以没有花费太多的精力。这意味着我们并没有真正需要更换活动记录，因为活动记录的真正实力能够通过常规直观地进行联接等。
DynamoDB有限制，你可能会发现自己在需要扫描大量记录的情况下。在我们的例子中，我们还使用CloudSearch来索引一些重要信息，并将其用作一个需要扫描所有数据的基于文本的搜索的情况下的回退。
I have earlier worked on Java+Spring to create a web-app. I have to build a new web-app now.
It will have one centralized db. There will be two different type of instance of web-app.
Web-App 1:
a) It would have nothing to UI render, no html,js etc.
b) All it need to give is some set of rest API which will
b.1) create some new entries in DB
b.2) modify some entries in DB
b.3) retrieve some of DB records in JSON format.
some frontend code ( doesn't belong to this app) will periodically fetch
this details.
c) it will be used by max by 100,000 people but at a given point of time,
we can expect about 1000 users logged in and doing whats being said in b)
Web-App2 :
a) It will have some dashboards
b) 90% of DB operations would be read operations
c) 10% of DB operations would be write/modify
d) There will be about 1000s of user of this system and at any given point of time
hardly 50-1000 people will be accessing it.
I am thinking of following. Have Web-App 1 created in python+Django and Web-App 2 created in RoR. I am planning to use to Dynamo DB and memcache.
Why two different frameworks?
1) So that I get to learn both of them 2) There have been concern about scalability in RoR (and I also know people claim its not there), Web-app 1 may have scaling needs in future.
My questions is Do you see any problem with this combination?
for example active records would want you to use specific namings format for your data base tables? Are there any other concerns similar to this?
Anyone else who have used similar technology stack?
both frameworks are full stack framework and and provide MVC, templating, unit testing, security, db migration, caching, security, ORMs.
For my startup, we also needed to put out a full fleshed website along with an API. We are also using DynamoDB for storing most of the data and are only using MySQL for session info.
I opted to use Ruby on Rails for the Webapp and Sinatra for the API. If you're criteria is simply learning as many new things as possible, then it would make sense to opt for relatively different stacks (django/python and RoR). In our case, we went with sinatra because it's essentially a very lightweight wrapper around Rack and perfect for an API which essentially receives requests, calls one or more services or does some processing and hands out a formatted response. While I don't see any problem with using python/django instead of sinatra, in our case the benefit was having to spend less time working with a different language.
Also, scalability in rails is a bit of an iffy subject. In the end, it's about how you use it. We've had no issues scaling rails with unicorn and nginx. Our business logic is all in the API service and the rails server as well uses the API for most of the work. This means we don't use active record on rails and the website is just another consumer for our API which does all the heavy lifting whether the request comes from an app or the website. Using MySQL for the session store ensures we can route requests to any of the application servers without having to worry about always routing requests from the same client to the same server every time. This allows us to ramp up and down easily only considering the amount of traffic we're getting.
At the time we started working on this, there wasn't an ORM for dynamo db which looked and felt just like active record, so we ended up writing a few high level classes of our own to handle storage and retrieval of models on DynamoDb. Considering DynamoDB is not tailored for scans or joins, this didn't take a lot of effort since we were almost always doing lookups based on keys and ranges. This meant we didn't really need a replacement for active record since the real strength of active record is being able to intuitively do joins, etc. by convention.
DynamoDB does have it's limitations though and you might find yourself in situations where you will need to scan a large number of records. In our case, we also use CloudSearch to index some important info and use it as a fallback for cases when we need to do text based searches which need to scan all our data.
这篇关于Django和Rails有一个常见的DB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
