这几年一直是MONGODB使用者，从3.2 到4.0 ，在使用中也一直充分的感受到MONGODB 这几年的飞速的发展以及功能的扩展，偶然在极客时间里面看到有MONGODB 的 终极玩家 唐建法 老师的关于MONGODB的课，其中有一段内容以前是不大敢想的, 就是ORACLE TO MONGODB。
就是 ORACLE 或者说传统型数据库到 MONGODB 的迁移，做数据库的都知道，即使是 ORACLE --- MYSQL ,ORACLE -- PG 也并非容易的事情，这样的迁移还算是 SQL 圈里面的事情。 RDBMS 到 NOSQL 的数据迁移，就比较少见了。
所以对这个课的主题是蛮觉得有点意思， 那第一就的确认需求
MOGNODB 中最大的特点就是高并发，高容量，高吞吐量 ，俗称“三高”， 对比传统关系型数据库，在同等的硬件配置下，的确也是高。同时有不愿意投入太高的成本，例如 学习基本MONGODB的技术可能短时间就能速成，但即使是RDBMS 里面最简单的MYSQL 也的付出不少的精力，所以从如果这个项目马上就需要在短时间上线，并且项目预期，三高的的情况下， MONGODB 在项目初期不会给项目实施拖后腿。
除此以外对于开发者的开发程序的迭代等等，关系数据库最大的问题在于限制多，经常会卡在一个地方，我字段要多少，我要什么类型，开发过程中经常有字段又小了， 要改浪费时间, Mongodb 在这点上，的确是可以忽略这一切的问题，开发的速度应该也是比较快的。
其实这几天公司的开发者也问我，传统数据库一行最大可以有多少列， varchar 最大可以到多少，有什么标准，其实每个数据库在这方面都有自己的限制，我们自然不愿意你把一个字段，尤其是存储JSON字段的数据统统塞到ORACLE ， SQL SERVER ， MYSQL , varchar 或 类string 类型的字段里面去。心里就想，如果直接用MONGODB 双方都省心了，你还能一个行(document) 给我塞 16MB 。
另外如果应用中有地理的经纬度计算的要求，MONGODB自带计算的能力，同时最近的时序性数据能力，基本上可以把常用的功能都包含在MONGODB 里面去处理了。
当然最终还有数据的高可用的问题，反正从ORACLE 到 SQL SERVER 到 MYSQL ，到 PG ，这堆的数据库高可用，只能是一言难尽， 何时能像MOGNODB 这么简单就好了，即使是跨中心机房的方案也是MONGODB最简单。
所以如果有上面项目时间的问题，项目灵活性的问题，业务多变的问题，如果是我我就选MOGNODB，这也是课上提出的一些原因。
除此以外就是迁移的难度的问题，从SQL 到 NOSQL ，总体要考虑
1 单体模式到分布模式 （不是分布式数据库），这里个人理解就是读写分离的灵活运用，对于MYSQL 来说读写分离需要注意的地方太多，并且数据库本身也不大给力，数据的一致性保证起来难，而MONGODB 的read concern ，write concern都可以帮助程序员来完成整体的读写分离的方案执行，降低写库的压力。
2 模式设计，原先数据库是需要符合一些数据库的设计需求，如范式，或反范式，传统数据库到NOSQL 需要的是关系型 到文档型，将原有的多表之间的关系，融合到单表，或 Few 表的 一对一 ，一对多，多对多， 等关系的设计中，最大化利用单 document 承载数据，可以冗余数据的思路,及基于object的设计思路。
3 程序与MONGODB 之间的 接口，这与我们平时使用的JDBC不一样，需要mongodb 自带的 API . 对于应用开发对于MONGODB 语句不熟悉的问题。
4 存储过程与函数的迁移，部分可以通过JS的方式来表达，或基本将这些通过程序来进行重构。
5 数据迁移，数据迁移中课程提到了四种方式，个人觉得在实际的工作中，可以采用灰度的方式来进行数据的迁移
1 程序需要将数据同时写入原有的数据库，和 MONGODB的数据库
2 工作一段时间，并且此时将原有的RDBMS 的历史数据从RDBMS数据库中导出，并且处理后，导入到mongodb
3 在一个确定的时间进行应用程序的切换，并且还有可靠的回滚的方式。
历史数据的导入可以采用常用一些工具 kettle ,datax 等，或批量数据导出导入如使用mysqldump mongoimport的方式（需要时间并且建议是历史性的数据而不是立即切换）
也可以使用tapdata cloud 的方式将 MSSQL, MYSQL, ORACLE 的数据迁移到MONGODB 中。
所以数据到迁移本身也应该是应用程序 历史数据 当前实施数据迁移的模式。
