<\/span>Challenges with legacy database solutions<\/span><\/h2>\n\n\n\nBecause the core system behind @cosme was Windows-centric, istyle used SQL Server as the core relational database management system (RDBMS). Over time, the system became increasingly complex, with more than 150 subsystems and a tightly-coupled database environment. The situation became extremely complicated and, over the years, had accumulated technical debt.<\/p>\n\n\n\n
To fully migrate to the cloud, istyle needed to minimize application-side modification costs while addressing their technical debt.<\/p>\n\n\n\n
<\/span>Selecting the right cloud-based solution <\/span><\/h2>\n\n\n\nistyle initiated the “Reborn Project” to tackle these challenges head-on. Based on the status quo of their challenges and issues, the team decided that only SQL Server could minimize the cost of repairing applications. Led by Toshifusa Suzuki, the project’s SQL Server subcommittee considered various options, including Amazon RDS for SQL Server, SQL Server on EC2, and Amazon Aurora.<\/p>\n\n\n\n
Initial trial with Amazon RDS and SQL on EC2<\/h3>\n\n\n\n
The team initially considered Amazon RDS for SQL Server (RDS) as a way to move to the cloud without changing the DB engine. However, RDS did not support replication. As for SQL Server on EC2, the operating cost was quite high, including licensing.<\/p>\n\n\n\n
The team again considered building with RDS and consolidating all databases into one RDS so that it would work even if replication was not possible. However, when they sized by the number of CPUs and required memory, the team found that RDS could only scale up by two levels. That was a problem: it made operations extremely inconvenient.<\/p>\n\n\n\n
Evaluating TiDB for database migration<\/h3>\n\n\n\n
After the trial with Amazon RDS, Mr. Suzuki began exploring distributed RDBMS with the aim of merging multiple databases. The SQL Server in use had already supported multiple copies for reading and writing. They did not need additional primary-secondary configurations to meet performance requirements. Instead, by physically dividing the database internals rather than the database server, they could balance the load without replication. This approach would also enable joining between databases and reduce the need for application modifications during the migration process.<\/p>\n\n\n\n
They then started properly evaluating TiDB and finally selected the solution for the following reasons:<\/p>\n\n\n\n
\n- TiDB is MySQL compatible. <\/strong>When they migrated their data, they didn\u2019t have to change any of their SQL statements. <\/li>\n\n\n\n
- TiDB is horizontally scalable.<\/strong> TiDB consists of a TiDB layer that interprets SQL and a TiKV layer for distributed data storage. TiDB\u2019s decoupled compute-storage architecture allows each layer to expand according to demand. <\/li>\n\n\n\n
- TiDB has a columnar store, TiFlash, that speeds up analytic processing<\/strong>. This makes TiDB an Hybrid Transactional and Analytical Processing (HTAP) database that allows transaction processing and real-time analytic queries to be processed in the same database without extract, transform, load (ETL). In istyle\u2019s test, TiDB demonstrated impressive results: some aggregate queries that previously took 30 seconds on conventional SQL servers ran in less than a second.<\/li>\n\n\n\n
- Throughout istyle\u2019s evaluation, the PingCAP team demonstrated thorough support and excellent R&D capabilities. <\/strong>This <\/strong>gave istyle enough confidence to continue using TiDB Cloud for their database needs.<\/li>\n<\/ul>\n\n\n\n \n \n
![\"\"](\"https:\/\/static.pingcap.com\/files\/2023\/05\/09004115\/iShot_2023-05-09_15.40.52.png\")
\n <\/div>\n \n The PoC was successfully completed with generous support from PingCAP. When we tested the data migration, some data types did not migrate correctly. However, the PingCAP team promptly identified and resolved the issue by applying a patch. This level of responsiveness reassured us that we could expect similar support during actual operations. Additionally, the fact that PingCAP operarates in Japan is also an advantage, as we can receive support in our native language<\/em>.<\/p>\n <\/div>\n \n Service Infrastructure Group<\/strong>, istyle<\/p>\n <\/div>\n <\/div>\n<\/div>\n\n\n<\/span>Results and benefits<\/span><\/h2>\n\n\n\nAfter a month of verification, istyle determined that TiDB was the best solution for their migration. TiDB Cloud, the managed service of TiDB on AWS, fits the scenarios of coupled DB groups, while Amazon Aurora is used specifically for applications with independent databases due to its lower costs.<\/p>\n\n\n\n![\"\"](\"https:\/\/static.pingcap.com\/files\/2023\/05\/09002159\/image-1024x662.png\")
<\/figure>\n\n\n\nBy the fourth quarter of 2023, the company plans to complete the migration to TiDB Cloud. Compared to building SQL Server on EC2, this move is expected to cut costs by half.<\/p>\n\n\n\n
<\/span>Conclusion<\/span><\/h2>\n\n\n\nistyle’s successful migration to TiDB Cloud is a testament to the power and flexibility of cloud-based solutions. By leveraging TiDB’s advanced features, istyle is set to continue its growth trajectory, providing an optimal user experience and a powerful platform for cosmetic brands to engage with their audience.<\/p>\n\n\n
\n \n Try TiDB Cloud Free Now!<\/p><\/div>\n
\n Get the power of a cloud-native, distributed SQL database built for real-time
analytics in a fully managed service.<\/p><\/div>\n
istyle initiated the “Reborn Project” to tackle these challenges head-on. Based on the status quo of their challenges and issues, the team decided that only SQL Server could minimize the cost of repairing applications. Led by Toshifusa Suzuki, the project’s SQL Server subcommittee considered various options, including Amazon RDS for SQL Server, SQL Server on EC2, and Amazon Aurora.<\/p>\n\n\n\n
Initial trial with Amazon RDS and SQL on EC2<\/h3>\n\n\n\n
The team initially considered Amazon RDS for SQL Server (RDS) as a way to move to the cloud without changing the DB engine. However, RDS did not support replication. As for SQL Server on EC2, the operating cost was quite high, including licensing.<\/p>\n\n\n\n
The team again considered building with RDS and consolidating all databases into one RDS so that it would work even if replication was not possible. However, when they sized by the number of CPUs and required memory, the team found that RDS could only scale up by two levels. That was a problem: it made operations extremely inconvenient.<\/p>\n\n\n\n
Evaluating TiDB for database migration<\/h3>\n\n\n\n
After the trial with Amazon RDS, Mr. Suzuki began exploring distributed RDBMS with the aim of merging multiple databases. The SQL Server in use had already supported multiple copies for reading and writing. They did not need additional primary-secondary configurations to meet performance requirements. Instead, by physically dividing the database internals rather than the database server, they could balance the load without replication. This approach would also enable joining between databases and reduce the need for application modifications during the migration process.<\/p>\n\n\n\n
They then started properly evaluating TiDB and finally selected the solution for the following reasons:<\/p>\n\n\n\n
- \n
- TiDB is MySQL compatible. <\/strong>When they migrated their data, they didn\u2019t have to change any of their SQL statements. <\/li>\n\n\n\n
- TiDB is horizontally scalable.<\/strong> TiDB consists of a TiDB layer that interprets SQL and a TiKV layer for distributed data storage. TiDB\u2019s decoupled compute-storage architecture allows each layer to expand according to demand. <\/li>\n\n\n\n
- TiDB has a columnar store, TiFlash, that speeds up analytic processing<\/strong>. This makes TiDB an Hybrid Transactional and Analytical Processing (HTAP) database that allows transaction processing and real-time analytic queries to be processed in the same database without extract, transform, load (ETL). In istyle\u2019s test, TiDB demonstrated impressive results: some aggregate queries that previously took 30 seconds on conventional SQL servers ran in less than a second.<\/li>\n\n\n\n
- Throughout istyle\u2019s evaluation, the PingCAP team demonstrated thorough support and excellent R&D capabilities. <\/strong>This <\/strong>gave istyle enough confidence to continue using TiDB Cloud for their database needs.<\/li>\n<\/ul>\n\n\n
\n\n\n\n <\/div>\n \nThe PoC was successfully completed with generous support from PingCAP. When we tested the data migration, some data types did not migrate correctly. However, the PingCAP team promptly identified and resolved the issue by applying a patch. This level of responsiveness reassured us that we could expect similar support during actual operations. Additionally, the fact that PingCAP operarates in Japan is also an advantage, as we can receive support in our native language<\/em>.<\/p>\n <\/div>\n
\nService Infrastructure Group<\/strong>, istyle<\/p>\n <\/div>\n <\/div>\n<\/div>\n\n\n
<\/span>Results and benefits<\/span><\/h2>\n\n\n\n
After a month of verification, istyle determined that TiDB was the best solution for their migration. TiDB Cloud, the managed service of TiDB on AWS, fits the scenarios of coupled DB groups, while Amazon Aurora is used specifically for applications with independent databases due to its lower costs.<\/p>\n\n\n\n
<\/figure>\n\n\n\nBy the fourth quarter of 2023, the company plans to complete the migration to TiDB Cloud. Compared to building SQL Server on EC2, this move is expected to cut costs by half.<\/p>\n\n\n\n
<\/span>Conclusion<\/span><\/h2>\n\n\n\n
istyle’s successful migration to TiDB Cloud is a testament to the power and flexibility of cloud-based solutions. By leveraging TiDB’s advanced features, istyle is set to continue its growth trajectory, providing an optimal user experience and a powerful platform for cosmetic brands to engage with their audience.<\/p>\n\n\n
\n\nTry TiDB Cloud Free Now!<\/p><\/div>\n
\nGet the power of a cloud-native, distributed SQL database built for real-time
analytics in a fully managed service.<\/p><\/div>\n - TiDB is horizontally scalable.<\/strong> TiDB consists of a TiDB layer that interprets SQL and a TiKV layer for distributed data storage. TiDB\u2019s decoupled compute-storage architecture allows each layer to expand according to demand. <\/li>\n\n\n\n