现在或以后扩展?

时间:2011-03-11 23:24:39

标签: ruby-on-rails nosql cloud pylons

我希望开始开发一个相对简单的Web应用程序,它将从各种来源提取数据并对其进行规范化。用户还可以直接将数据输入站点。如果成功,我预计会达到规模。现在是否值得使用可扩展或分布式技术或者只是从LAMP堆栈开始?框架与否?任何想法,建议或评论都会有所帮助。

忽略我对这个想法的含糊描述,一旦我走得更远,我很乐意分享。

5 个答案:

答案 0 :(得分:8)

后来。我不记得是谁说的(可能是SO的杰夫阿特伍德)但它确实如此:你的第一个问题是让其他人关心你的工作。当他们这样做时担心规模。

尽管如此,一定要采用结构良好的框架来实现自己的理智。即使它最终没有成千上万的用户,你也会想要随着时间的推移添加功能。维持一个没有良好结构的扩展代码库很快变得相当可怕(去那里,做到了,失去了客户端)。

不过,如果你想写自己的框架,请注意它是很多的工作。我的公司有一个我们非常自豪的内部公司,但它需要3 - 4年才能成熟。

答案 1 :(得分:6)

  

现在是否值得使用可扩展或分布式技术或者只是从LAMP堆栈开始?

LAMP堆栈是可扩展的。 Apache提供了许多替代方案。

  

框架与否?

始终使用您能找到的最强大的框架。写尽可能少的代码。尽快在人们面前获取一些东西。

专注于重要事项:让事情发挥作用。

如果你没有可行的东西,可扩展性并不重要,是吗?

然后阅读优化。 http://c2.com/cgi/wiki?RulesOfOptimization非常有用。

规则1.不要。

规则2.还没有。

规则3.优化前的配置文件。

在您拥有一个正在运行的应用程序之前,您不知道具体的东西会限制您的可伸缩性。

不要假设。测量。

这意味着构建人们实际使用的东西。规模来得晚。

答案 2 :(得分:3)

以后一定要做。扩展难度是一个问题,这意味着像你的项目这样的人足以强调它正在运行的硬件。

我工作的最后一家公司开始使用PHP和CakePHP的第一个版本(当它还处于测试阶段时)开始时相当小。有些代码很脏,管理工具很乱(代码方面),并且确保它可以从一开始就做得更好。但你知道吗?他们在竞争对手之前就把它拿出来了,并且变得非常成功。

当我加入时,他们开始达到目前潜在可扩展性的极限, 是他们决定开始研究CDN,lighttpd缓存技术以及其他清理方法的时候在负载很重的情况下,代码可以使运行更顺畅。我不再为他们工作了,但这是一个很好的经验,可以将建筑发展到最初的范围之外。

我现在可以告诉你,如果他们在销售内容和网站直播之前尝试进行可扩展性和优化 - 他们将永远不会增长到现在的规模。该公司是www.beatport.com如果你对我正在谈论的人感兴趣(为了重新进行迭代,我不打算宣传它们,因为我不再与它们有关联,但它是一个很好的案例学习,当他们看到他们的网站时,人们更容易理解我在说什么。

就个人而言,在使用Ruby和Rails(并理解分离!)了几年之后,并且在Beatport有PHP经验 - 我可以自信地说我再也不想使用PHP代码= p

答案 3 :(得分:1)

有趣地问“现在或以后的比例?”并将其标记为“ruby on rails”。 实际上,Ruby on Rails是由David Heinemeier Hansson创建的,他在他的书中有一章标记为“后来缩放”:)) http://gettingreal.37signals.com/ch04_Scale_Later.php

答案 4 :(得分:0)

我同意早期的受访者 - 让它变得有用,让它有效并让人们有动力首先使用它。我也同意你应该选择现成的组件(其中有很多组件)而不是自己动手组件。同时,请确保为基础架构选择可扩展的组件,以便在需要时可以到达那里,而无需重新编写应用程序的主要块。

作为Berkeley DB的产品经理,我见过开发人员的反对案例,他们决定“哦,我们只是将其写入平面文件”或“我可以编写自己的简单B树功能” “或”数据库XYZ'足够好',我不必担心以后的并发性或可扩展性“。这种方法的问题在于:a)你正在重新发明轮子(并且放弃了其他人已经学到的困难)和b)你忽略了你必须在某些时候处理可扩展性这一事实并采用“足够好”的解决方案。

祝你好运。