根据我的阅读,SE 网络上的每个站点似乎都存在于一个应用程序中,但有自己的数据库。这似乎很昂贵,我不确定有什么好处。我的新手理论是,由于每个数据库在每个表中的行数较少,因此读取和写入的速度要快一些。
这种好处来自于跨数据库应用任何迁移或数据库更新的看似巨大的成本,这更耗时,并为冗余、DevOps 等引入了更高的成本。
与单数据库 + 单应用架构相比,这有什么好处?
根据我的阅读,SE 网络上的每个站点似乎都存在于一个应用程序中,但有自己的数据库。这似乎很昂贵,我不确定有什么好处。我的新手理论是,由于每个数据库在每个表中的行数较少,因此读取和写入的速度要快一些。
这种好处来自于跨数据库应用任何迁移或数据库更新的看似巨大的成本,这更耗时,并为冗余、DevOps 等引入了更高的成本。
与单数据库 + 单应用架构相比,这有什么好处?
将每个租户保存在一个单独的数据库中,可以很容易地将要求高的租户移动到他们自己的服务器上,将他们的数据/日志文件放在更快的 I/O 上,等等。如果你把每个人都放在同一个数据库中,你最终会将在您当前的硬件上碰壁,然后您要么将所有人转移到更大的硬件上。
维护部分并不是什么大问题,实际上使一些事情变得更容易。对于相同模式的部署,您实际上并不需要任何额外的 DevOps 资源,您只需要一个循环(或SQL Farm Combine或Red-Gate Multi Script等工具)。更容易的事情是备份 - 虽然这听起来像是更多的管理开销,而且您仍然需要备份大约相同数量的整体数据,但单独的数据库实际上可以让您更好地控制 - 您可以将不同的备份放在不同的驱动器上,按不同的时间表运行它们,它们应该更小更快,您甚至可以让不同的租户使用不同的恢复模型。另一个好处:由于一个租户的问题而恢复到某个时间点只会影响该租户。
另一个好处是保持每个租户的数据分开 - 这有时可以满足法律要求,但也可以很容易地删除一个租户或将它们移动到不同的服务器而不影响任何其他租户。
这些答案中的其他一些叙述在 dba.SE 上:
https://dba.stackexchange.com/a/16767/1186
https://dba.stackexchange.com/a/33556/1186
这也是 Windows Azure SQL 数据库等基于云的解决方案设计的一个重要方面。
这类似于任何扩大与扩大规模的决定。
如果您向外扩展,您可以(通常)以更低的成本在更多硬件上分配工作负载。正如您所提到的,读取和写入也更容易在较小的数据库上进行优化。基本上,在较小的数据库上维护和控制性能更容易:索引更小,您不必担心分区等高级设计问题,如果您必须恢复单个租户的数据,恢复速度会更快,您不需要不得不担心代码错误会不正确地暴露其他租户的数据等。
正如您所提到的,与所有事情一样,必须考虑很多权衡。但是,避免多租户情况有非常明显的好处。