(*nix) 用于快速构建的云/集群解决方案可扩展的网络服务

发布于 2024-08-11 16:27:02 字数 1539 浏览 6 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

§对你不离不弃 2024-08-18 16:27:02

你确实需要对“大”有一个更好的定义。 “大”是一个愿望,还是您的营销部门*认为他们会提供确切的数字?

如果您可以使用简单的组件来完成此操作,请这样做。 Cassandra 和 Hadoop 之类的软件既不容易设置(尤其是后者),也不容易开发;能够有效开发此类应用程序的开发人员将非常昂贵且难以雇用。

所以我想说,开始使用您最喜欢的“传统”数据库,并采用适当的高可用性解决方案,然后等到接近限制(一旦构建了实际应用程序,您始终可以测量实际应用程序的限制在哪里)并且您有一个性能测试系统)。

请记住,Stack Overflow 使用非常传统的组件,只需使用少量商用硬件进行良好调整即可。这对于它的规模来说很好,但永远不会适用于(例如 Facebook),但开发人员知道 SO 的受众永远不会达到 Facebook 的水平。

编辑:

当“传统”技术开始失败时,例如您达到了在单个数据库实例上可以完成的操作的限制,那么您可以考虑分片或对更多实例进行功能分区(再次选择HA系统)。

您唯一需要这些(例如 Cassandra)“nosql”系统之一的情况是,如果您有一个具有非常高的写入要求和可用性要求的同构数据存储;即使这样,你仍然可以通过对传统系统进行分片来解决这个问题——就像其他人(甚至 Facebook)有时所做的那样。

You really need a better definition of "big". Is "Big" an aspiration, or do you have hard numbers which your marketing department* reckon they'll have on board?

If you can do it using simple components, do so. The likes of Cassandra and Hadoop are neither easy to setup (especially the later) or develop for; developers who are going to be able to develop such an application effectively will be very expensive and difficult to hire.

So I'd say, start off using your favourite "Traditional" database, with an appropriate high-availability solution, then wait until you get close to the limit (You can always measure where the limit is on your real application, once it's built and you have a performance test system).

Remember that Stack Overflow uses pretty conventional components, simply well tuned with a small amount of commodity hardware. This is fine for its scale, but would never work for (e.g. Facebook), but the developers knew that the audience of SO was never going to reach Facebook levels.

EDIT:

When "traditional" techniques start failing, e.g. you reach the limit of what can be done on a single database instance, then you can consider sharding or doing functional partitioning into more instances (again with your choice of HA system).

The only time you're going to need one of these (e.g. Cassandra) "nosql" systems is if you have a homogeneous data store with very high write requirement and availability requirement; even then you could probably still solve it by sharding conventional systems - as others (even Facebook) have done at times.

迷你仙 2024-08-18 16:27:02

由于您的表述有点含糊,所以很难提出具体的建议,但我会推荐 Google Appengine基本上适用于任何网络服务。它可靠、易于使用,并且基于 Google 架构构建,因此快速且可靠。

It's hard to make specific recommendations since you've been a bit vague, but I would recommend Google Appengine for basically any web service. It's reliable, easy to use, and is built on the google architecture so is fast and reliable.

情释 2024-08-18 16:27:02

我想推荐平层交响曲。这是一个可以完成这一切的私有云服务。您刚才提到的一切 - 这项服务提供得非常完美。他们的 symphony 产品为您的企业数据中心提供公共云体验。如果这就是您正在寻找的,我建议您尝试一下

i'd like to recommend stratoscal symphony. it's a private cloud service that does it all. everything you just mentiond - this service provides perfectly. their symphony products deliver the public cloud experience in you enterprise data center. if that's what you're looking for, i suggest you give it a shot

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文