2018 年 3 月 22 日，结贴
感谢各位的指点，受教良多：
- 如果只是想锻炼技术，有很多方式;
- 现有系统运行稳定，若想替换，再三考虑，特别是生产事故;
- 数据量如果较大，建议用更直接的方式进行迁移，免去不必要的开支;
huacnlee：要大量迁移，得写成并发执行（Ruby 也写成可以并发执行的），最好是批量原生 SQL 插入，避免无谓的动作降低速度
2018 年 3 月 18 日
我现在有这么一个 场景： 原先的系统已经运行了一段时间，期间已经产生了许多的数据。现在我准备把以前的系统，改成 Rails 的。那要怎么利用上原来的数据呢？
我感觉，主要的 思路 就是：
- Rails 中新建迁移，把表结构和模型处理好。
- Rails 中把原始数据通过迁移的方式导入进去，（或者使用数据库还原工具）
- 正常使用原始数据...
如果数据库体量比较大（60G），表的数目比较多（300 张），那要一个个添加上这些还是挺困难的。
我翻看 Rails Guide Active Record 迁移章节，提到了 数据库模式转储.。
不知道数据库模式文件，到底怎么用？
重新创建了数据库结构，就继续在 Rails 中创建模型吗……
重写系统可能会历时半年，期间一点产出都没有，失败风险很大，要考虑清楚是否要这么做。
如果系统可以短暂停机，并且不需要对老接口兼容，那么可以写个全新的然后写脚本把数据搬运过来过来。考虑到数据量大，可能要用 SQL 做。
如果系统不能停机，需要对老接口兼容，那么就复杂了，可能要做双向数据同步，看到一篇文章挺好的，但我没实践过 https://blog.heroku.com/monolithic-applications-into-services
同意 5 楼的 如果是重写的话没有必要迁移数据库，使用旧的数据库，创建对应的 model，ActiveRecord 会自动对应表里的字段。可以参考 https://stackoverflow.com/a/29571368/8493113
Rei
回复
嗯嗯，感谢您的回复。目前我也还只停留在“想法”阶段，距离“行动”还得再精打细算一番。我之所以有这样的打算，一方面想锻炼一下自己的技术，一方面也是想以后的维护不那么痛苦。哈哈，在探索的过程中，就会有很多想法啊。
BigNerdCoding
回复
原有的旧系统，维护过程就像是在不断地堆垃圾，实在难以忍受，才会有此想法。不过，也确实是想尝试新语言新框架，毕竟 web 要涉及的东西对我来说还是太多，换种语言换种思路，或许会带来新的拓展。
在维护老代码的时候想整个推翻重来，这是程序员的常见病，得治 
老代码久经考验，很多人补过无数坑，不是一个脑袋短期内能考虑周全的。
如果想锻炼一下技术，可以试着用 Rails 套上 discuz 的表重写一下，这对推广 Rails 应该很有帮助，还避免了老系统崩溃的问题。
我也是新手..我提供一个方案。
我最近自己在做一个爬虫和 rails 结合的项目，爬虫数据存储到数据库，然后 rails 连接同一个数据库。 由于我这个项目的数据部分只需要从数据库读取。第一步是建立对应的 model，新建 model 的时候没有新建 migration 文件，然后在 model 中使用 self.table_name = "" 的方式，迁移一下，scheme 文件中就可以看到对应的字段了。（爬虫的数据库是 pg rails 数据库也是 pg）
数据部分就搞定了，剩下的如果新建 model 就和平时写 rails 没什么区别了。
顺便再提供几个我考虑过的方案。一是导出 csv 再导入，二是直接数据库导出 sql 然后导入。第二个方案如果数据库不同的话需要做一部分修改。
因为我也是才开始写 rails 没多久，这有几个我参考的 ruby china 中的帖子，希望对你有帮助！
你 60G 的数据，有多少条记录？
你要考虑下面的问题：
- 有没有老的 API 什么的需要向下兼容的？
- 有没有足够的人一起干这个事情？
- 如果有老功能，老 API 需要兼容，是否有测试团队帮你验证？
- 有没有足够能力确保新做一次，比之前好很多，让老板支持？因为这个周期比较长。
- 等你开发完升级上线的时候，需要做数据迁移，你有没有能力在不停机，或短时间停机快速迁移完成？
关于老数据迁移
反正这种大量数据（上百万条）迁移，你要想当然的用 Rails 来写，走 ActiveRecord 的流程是很慢的（因为有各种验证、Callback ... 等等和迁移无关的动作），不适合大量迁移。
要大量迁移，得写成并发执行（Ruby 也写成可以并发执行的），最好是批量原生 SQL 插入，避免无谓的动作降低速度。
量更大的时候，你可能需要分布式，例如 (Hadoop 集群）的方式来执行迁移动作，不仅是并发，还多机器并发。
你还得考虑迁移过程中断（例如开发环境验证没遇到的奇怪数据）以后能增量迁移的问题，这样可以在升级前先把存量的老数据前迁移到新的库里面。等到最终测试完成，要上线的时候再增量跑一次后面新增的少量数据（这样能减少停机时间），完成以后一次切换掉。
huacnlee
回复
最大的表也就在百万级别…
- 有老的 API 要向下兼容;
- 人力总是紧张的;
- 测试 case 要重新写，没有专门的团队;
- 信心是有，就怕太过理想，总体衡量下还是有点悬;
- 并非 24 小时不间断的系统。
再三思索了下，主要的业务系统不太好重写。倒是可以给原有系统增加一些功能分支，逐步引入 rails。也感谢您的指点 
