"我有个 sqlserver 生产库，越来越大，越来越慢，于是就把一些数据做归档，并把非核心业务表迁移到另外的实例，但业务还是不能割裂的，于是新实例和老的生产库之前会有大量的定时数据迁移，复制， .."
我有个 sqlserver 生产库，越来越大，越来越慢，于是就把一些数据做归档，并把非核心业务表迁移到另外的实例，但业务还是不能割裂的，于是新实例和老的生产库之前会有大量的定时数据迁移，复制，跨库查询，甚至回写（新实例的存储过程回写生产库），而跨库查询和回写反而对生产库产生很明显的性能影响，SPL 能在这个场景里提供哪些帮助吗？比如是否支持跨库查询乃至对生产库进行回写
跨库查询、回写这些对 SPL 不是大问题，但 SPL 并没有本事把数据库变得更快（无论它的运算还是 IO 都没办法），它只能让这些数据处理的代码容易写一点。
如果最终数据的落地处理仍然在数据库中，那只能指望负载被分摊后数据库性能会明显提升。
通常的办法是这样：做归档不是按数据所属的业务分，而是按数据的时间分，历史数据不再变化后归档出来用 SPL 来算，再和数据库中的热数据混合计算，性能会比单一数据库或两个数据库都要高得多，一般用不着再弄个数据库实例。
历史数据是归档在 spl 的文件型数仓里吗
是的，可以归档成组表或者集文件。
SPL 处理这些数据时，并不像数仓那样有个明显的“仓库”概念。SPL 的计算能力是开放的，并没有限制在一个“仓”内，只要能访问到的数据都可以计算，不同之处只在于计算性能的差异，采用 SPL 自有文件格式的速度比较快。
通俗类比时，我们会说文件型“数仓”，但理解 SPL 的架构逻辑后，就不会再用这个不贴切的词了。
跨库查询、回写这些对 SPL 不是大问题，但 SPL 并没有本事把数据库变得更快（无论它的运算还是 IO 都没办法），它只能让这些数据处理的代码容易写一点。
如果最终数据的落地处理仍然在数据库中，那只能指望负载被分摊后数据库性能会明显提升。
通常的办法是这样：做归档不是按数据所属的业务分，而是按数据的时间分，历史数据不再变化后归档出来用 SPL 来算，再和数据库中的热数据混合计算，性能会比单一数据库或两个数据库都要高得多，一般用不着再弄个数据库实例。
历史数据是归档在 spl 的文件型数仓里吗
是的，可以归档成组表或者集文件。
SPL 处理这些数据时，并不像数仓那样有个明显的“仓库”概念。SPL 的计算能力是开放的，并没有限制在一个“仓”内，只要能访问到的数据都可以计算，不同之处只在于计算性能的差异，采用 SPL 自有文件格式的速度比较快。
通俗类比时，我们会说文件型“数仓”，但理解 SPL 的架构逻辑后，就不会再用这个不贴切的词了。