我有一个与Django，Apache，Nginx和Postgres部署的项目。 该项目要求客户可以查看实时数据。 项目要点是：1.现场设备login后向服务器发送数据（设备也类似网站用户）。 2.有postgres导入上传数据的后台导入过程。 3.系统的networking用户使用这些数据，并可以向设备发送命令，设备在login时读取这些命令。 4.还有对数据运行的背景分析例程。
上述所有设置和系统都部署在一台亚马逊EC2云计算机上。 该项目目前支持600多个设备和400个用户。 但随着设备数量的不断增加，服务器的性能正在下降。
我们想扩展这个项目，以便它可以支持越来越多的设备。 我最初的想法是，我们将创build一个像当前的服务器，并将其中的设备分为服务器。 但是，我们需要一个中央的用户和设备pipe理点，虽然Django的pipe理。
有任何想法吗？ 创build可伸缩体系结构的最佳方式是什么？ 如果可能的话，如何创build一个Postgres集群并在Django中使用它？
你的问题是短暂的细节和长时间的挥手，但这听起来像你最初的想法是一个很好的开始。 您的应用程序听起来与Zenoss监视套件非常相似，它使用基本上相同的负载分布架构来扩展：多个监视主机共享数据收集工作负载，具有单个pipe理界面，以及pipe理主机上的数据库或单独的系统。
如果你的瓶颈在第一点（设备发送数据到你的服务器），那么将这些任务分到第二台机器上，应该为负载增长腾出空间。 最大的实现障碍通常是如何pipe理多个Django服务器上的任务。 Celery，一个分配的任务队列引擎，可能是目前最好的select。 它最初是围绕Djangodevise的，对你有好处，它有非常活跃和有用的开发者和用户社区。
如果点＃2和＃4是你目前的限制，但是，你可能在谈论数据库的可伸缩性。 总的来说，这只是一个难题：没有代码透明，负载中立且便宜的方法来扩展数据库容量。
如果你只需要获得更多的数据库“读取”IO容量，复制就可能成功。 Postgres使用名为Slony-I的外部工具支持复制。 这是单主复制，具有多个只读“从”主机，获得在主服务器上执行的语句副本。 所有应用程序的写入操作（UPDATE，INSERT，DELETE …）都会通过单主控主机，但是您将在主控和所有从控制器之间分配您的读取（SELECT …）。
分布式读取所需的代码修改通常非常简单。 Django最近增加了对复制数据库的支持，我还没有用过，但它应该是相当不错的。
如果你需要更多的数据库写入IO容量，分片将可能工作。 每个主机都保留每个数据库表的独立块。 数据库客户端使用确定性函数来决定任何给定logging应该驻留的位置，因此负载分布实际上是无状态的，并且可以扩展到大量的数据库服务器。 Django的新的多数据库支持（与上面相同的链接）也支持分片。 你需要更改代码，痛苦应该是有限的。
另外，我想提一下Memcached，它似乎是今天（Facebook，Google，Twitter …）上互联网上所有高度可扩展的Web应用程序的一部分。 一个好的caching实现可以将您的数据库需求减less到原始大小的一小部分，将昂贵的缓慢的数据库查找转换为便宜，快速的caching查找。 现在，Django已经支持了Memcached的整合。
我意识到这些都不是太具体，但它应该给你一个很好的起点去搞清楚细节。 祝你的项目好运。
首先你必须认识到，你的酒店在哪里？ 应用层的问题？ 数据层访问？ 你的访问模式是什么？ 大部分是读？ 或者也许主要是写？
对于应用层：
对于数据层有一些方法，你可以遵循：