考虑到这种期望，您会选择什么语言或系统来实施该解决方案？
是系统应处理的估计：
- 3000 多个最终用户
- 世界各地 150 多个办事处
- 高峰时段
- 1500 多个并发用户 10.000 多个每日更新
- 每秒 4-5 次提交
- 每秒 50-70 个事务（读取/搜索/更新）
以下 将是仅供内部使用的业务应用程序，致力于帮助航运公司进行全球货运管理。
您会选择什么技术、为什么选择以及实施它大约需要多长时间？ 谢谢。
注：我不招聘。 :-)
Here are the estimates the system should handle:
- 3000+ end users
- 150+ offices around the world
- 1500+ concurrent users at peak times
- 10.000+ daily updates
- 4-5 commits per second
- 50-70 transactions per second (reads/searches/updates)
This will be internal only business application, dedicated to help shipping company with worldwide shipment management.
What would be your technology choice, why that choice and roughly how long would it take to implement it? Thanks.
Note: I'm not recruiting. :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
所以，你问我将如何处理这样的项目。 在 Smalltalk 世界中，人们似乎都同意 Gemstone 使事物能够神奇地扩展。
所以，我真正要做的是：我开始使用 SandstoneDB。 然后，这一刻就会出现单个图像开始变得太慢的情况。
GemStone 然后负责复制您的公共对象（从某个根目录可见的对象）并在所有实例之间进行。 您可以获得会话和增强的查询功能，以及相当快的虚拟机。
它与 C、Java 和 Ruby 共享数据。
事实上，他们有自己的 Ruby VM，也值得一看。
So, you asked how I would tackle such a project. In the Smalltalk world, people seem to agree that Gemstone makes things scale somewhat magically.
So, what I'd really do is this: I'd start developing in a simple Squeak image, using SandstoneDB. Then, this moment would come where a single image begins being too slow.
GemStone then takes care of copying your public objects (those visible from a certain root) back and forth between all instances. You get sessions and enhanced query functionalities, plus quite a fast VM.
It shares data with C, Java and Ruby.
In fact, they have their own VM for ruby, which is also worth a look.
维基百科使用 MySQL 管理更苛刻的要求
wikipedia manages much more demanding requirements with MySQL
您的数据量很大，但如果编程有效，则不太可能对任何可靠的 RDBMS 造成压力。 如果您的团队很草率（即，随意地将 SQL 查询直接放入组件中，然后再将其组合成更大的组件），那么您可能会面临“乘数”效应，其中一个逻辑需求（获取该页面所需的数据）变成了一个大量物理数据库查询。
因此，您不应该关注 RDBMS 的能力，而应该关注程序员的能力以及实现语言和环境促进分析和重构的程度。
您提出的场景显然也是 24x7x365 的场景，因此您还应该考虑监控/仪表板要求的需要。
无法根据您提出的需求来估计开发工作量； 很高兴您能够将事务分析到这种粒度级别，但是开发工作的主要决定因素将是域和 UI 要求。
Your volumes are significant but not likely to strain any credible RDBMS if programmed efficiently. If your team is sloppy (i.e., casually putting SQL queries directly into components which are then composed into larger components), you face the likelihood of a "multiplier" effect where one logical requirement (get the data necessary for this page) turns into a high number of physical database queries.
So, rather than focussing on the capacity of your RDBMS, you should focus on the capacity of your programmers and the degree to which your implementation language and environment facilitate profiling and refactoring.
The scenario you propose is clearly a 24x7x365 one, too, so you should also consider the need for monitoring / dashboard requirements.
There's no way to estimate development effort based on the needs you've presented; it's great that you've analyzed your transactions to this level of granularity, but the main determinant of development effort will be the domain and UI requirements.
选择您的开发人员了解和熟悉的技术。 所有主要技术都可以轻松满足此类要求。
Choose the technology your developers know and are familiar with. All major technologies out there will handle such requirements with ease.
您的每日更新次数与提交次数不相加。 每秒 4 次提交 = 每小时 14,400 次。
您没有提到任何有关预期数据库大小的内容。
无论如何，我会集中精力选择一个强大的后端，如 Oracle、Sybase、MS 等。这种选择将对性能产生最大的影响。 根据需要，前端可以是桌面应用程序或 WEB 应用程序。 由于这将在世界各地的许多办公室中使用，因此 WEB 应用程序可能最有意义。
Your daily update numbers vs commits do not add up. Four commits per second = 14,400 per hour.
You did not mention anything about expected database size.
In any case, I would concentrate my efforts on choosing a robust back end like Oracle, Sybase, MS etc. This choice will make the most difference in performance. The front end could either be a desktop app or WEB app depending on needs. Since this will be used in many offices around the world, a WEB app might make the most sense.
我会选择 MySQL 或 PostgreSQL。 满足您的要求，两者都不可能出现问题。
I'd go with MySQL or PostgreSQL. Not likely to have problems with either one for your requirements.
我喜欢对象数据库。 就每秒提交次数和数据库往返次数而言，任何关系数据库都无法承受。 查看 db4o。 它非常容易学习，请查看示例！
至于编程语言和 UI 框架：嗯，选择你的团队擅长的。 元时间浪费较少的动态语言可能会节省时间。
I love object-databases. In terms of commits-per-second and database-roundtrip, no relational database can hold up. Check out db4o. It's dead easy to learn, check out the examples!
As for the programming language and UI framework: Well, take what your team is good at. Dynamic languages with fewer meta-time wasting will probably save time.
这里没有提供足够的信息来给出适当的建议。 需要进行更多的尽职调查。
There is not enough information provided here to give a proper recommendation. A little more due diligence is in order.