Assess the necessity and value of migration
List your challenges
If you have two or more requirements that your relational database can’t be satisfied with, you could consider to migrate.
- High currency (thousands – millions ops per sec)
- Dynamic model and flexible queries
- Agile development and rapid iteration
- Shorten application launch time
- Geographic queries
- Multi center data synchronization, disaster recovery
- Deploy rapidly and expand on demand
- 99．999% uptime (< 10 minutes per year)\
- Reduce costs of hardware, use x86 servers
- Recovery at any time
Migration Difficulty
Simple: RDBMS → RDBMS, such as Oracle → MySQL, SQLServer
Complex: RDBMS → Document, such as Oracle → MongoDB
Need to consider:
- Data model design
- Overall architecture design
- Full stack consideration
| Apps | |
| POJOs |
In theory, POJOs should be pure object models, expressing business concepts. In fact, many POJOs and relational tables have a one-to-one correspondence to connect with ORM. |
| ORM | MongoDB doesn’t need ORM. |
| SQL/ResultSet | MongoDB doesn’t support SQL, ResultSet and join. |
| JDBC | MongoDB handles drivers with itself, includes MQL, connection pool management, write security, no JDBC, no multi-document multi-statement transaction control |
| RDBMS |
Main field of migration: model, stored procedure, operational tools & scripts, backup and restore, testing environment. Extra benefits: High Availability & Disaster Recovery |
| Storage Layer | Storage scheme: RDB typically deploy on SAN. MongoDB also supports SAN, but it gets best performance by using local storage. |
Calculator of migration cost
| Current application features | Difficult | Requirement |
| Multi-phase XA, remote transaction support (queue) | -5 | |
| More than 100 tables, most are core and important | -3 | ✔ |
| Use ORM extensively | -3 | |
| Hundreds of SQL driven BI reports | -2 | |
| Dynamic SQL generator | +2 | ✔ |
| Business code is neat and no SQL | +2 | ✔ |
| Business code has a lot of BLOB data read & write | +2 | |
| Need to save and query third-party (uncontrollable) data | +4 | |
| Exist independent abstract DAL | +4 | |
| Hope to simplify DAL | +4 | |
| Score | +1 |
Score less than 0: relate to migration value, the cost is a bit high.
Consideration of data model and structure
Modelling
| RDBMS(5 tables) | MongoDB(2 collections) |
 |
 |
Data Structure: not only single value
| RDBMS | MongoDB |
| BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME |
Map bn = makeName(FIRST, LAST, MIDDLE) {first: “Buzz”, last: “Moschetti”} |
| INSERT INTO COLL BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME |
Collection.insert( {“buyer_name”: bn}); |
| Select BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME |
Collection.find(pred, {“buyer_name”:1}); |
Add a new field
| RDBMS | MongoDB |
| BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME |
Map bn = makeName(FIRST, LAST, MIDDLE, NICKNAME) |
| INSERT INTO COLL BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME |
Collection.insert( {“buyer_name”: bn}); NO change |
| Select BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME |
Collection.find(pred, {“buyer_name”:1}); NO change |
Add a new type: so easy
| RDBMS | MongoDB |
| BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME SELLER_FIRST_NAME SELLER_LAST_NAME SELLER_MIDDLE_NAME SELLER_NICKNAME |
Map bn = makeName(FIRST, LAST, MIDDLE, NICKNAME) Map sn = makeName(FIRST, LAST, MIDDLE, NICKNAME) |
| INSERT INTO COLL BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME SELLER_FIRST_NAME SELLER_LAST_NAME SELLER_MIDDLE_NAME SELLER_NICKNAME |
Collection.insert( {“buyer_name”: bn, “seller_name”: sn}); |
| Select BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME |
Collection.find(pred, {“buyer_name”:1, “seller_name”: 1}); |
Add a “title” field for everyone
| RDBMS | MongoDB |
| BUYER_FIRST_NAME BUYER_LAST_NAME BUYER_MIDDLE_NAME BUYER_NICKNAME SELLER_FIRST_NAME SELLER_LAST_NAME SELLER_MIDDLE_NAME SELLER_NICKNAME LAWYER_FIRST_NAME LAWYER_LAST_NAME LAWYER_MIDDLE_NAME LAWYER_NICKNAME CLERK_FIRST_NAME CLERK_LAST_NAME CLERK_NICKNAME QUEUE_FIRST_NAME QUEUE_LAST_NAME … |
Map bn = Easy change NO change |
Selection of data architect
| Less model modification | Extensive model modification | |
| Advantage | ● Migrate large amounts of data more easily ● Little impact on upper-level business code ● Little impact on DAL |
● New data model for subsequent development more agile ● 1:n embedded model improve performance usually |
| Disadvantage | ● Need to implement join in code ● Single value needs reload to multi-value |
Increase the cost of design |
Here are some things to consider before deciding to migrate from a SQL database to MongoDB. Includes migration costs and some key points that data architects are concerned about. After all, migration and rewriting are the ways to solve problems.
If you decide to migrate, I would like to introduce you to some methods. So please continue to pay attention.
