多个intranet/internet系统在同一数据上部分工作.数据库策略

Question

我们开始重写我们的应用程序(互联网门户，数百万独特的用户，很少的CRM/ERP系统，几百个用户)，我们现在有一个巨大的决定要做。我们将主要用Symfony2和Doctrine编写它们(90%-95%)，用Java编写一些后台服务(例如邮件)。数据库- MySql/MariaDb.还有许多附加技术(redis/memcached、load balancing、varnish、replication等)。最重要的(在本例中)是- symfony2、mysql/maria和doctrine。

问题是，很少有系统能在相同的表上工作。例如:提供职务的internet门户+客户关系管理系统( CRM系统)，用于管理为发布这些招聘而付费的客户(有许多类似的案例)。同时，在每个系统之间为我们的用户提供一个登录的功能也很重要。

我在这里看到两种方法：

1. 我们有一个很大的数据库，有几百张桌子。我以前使用过200+表，但没有处理那么大的流量。因此，如果流量上升，将涉及切分/分区。
2. 我们有许多数据库，每个数据库只供一个应用程序使用。如果需要一个应用程序与另一个DB通信，我们将编写特殊服务来提供该功能。

现在，我所担心的是: 1.易于开发--只有一个数据库更容易；2.易于配置/确保修改性；3.性能

我现在知道的一件事是，数据库将托管在三台带有master-slave复制的机器上，Doctrine很好地支持这种复制。

你的想法是什么？你的职业和骗局是什么？谢谢!

Answer 1

• 1数据库，镜像和群集，并按需要进行分区，并将存储过程作为API用于：
• 几个与DB对话并提供与域无关的API的App服务器：
• 许多客户端与之交互的web服务器。

这是实现可伸缩性的方法。您将一些处理抵消到各层，因此web服务器处理html页面的所有表示，给定从DB检索并由应用程序层组合或以其他方式传递的数据。一般情况下，这是很好的水平扩展(即需要更大的规模，添加更多的web或应用服务器)。

使用这种体系结构可以减少DB上的负载-- DB只向应用程序层提供原始数据。这意味着应用程序层可以提供一些数据的缓存，以进一步减少DB上的负载，因为只有少数数据不需要完整的缓存机制来保持缓存的同步。

如果数据很容易分区，而且客户端在与应用程序层交谈时甚至不知道您已经这样做了，您也可以引入单独的DB。这可能是最大的胜利，你可以改变事情而不重新部署一切。