戳蓝字“读字节”关注我们哦
问题：
如题，最近公司想做电商服务类型的企业级应用，这些应用里会导入电商海量级的数据，可能在用户量不像互联网产品那样大，但是需要处理海量数据以及数据较为复杂的结构处理等，所以在想是否能直接用MongoDB替换掉MySql(当然，一些基本的配置类信息还是存储在MySQL里)。多谢大牛们赐教！！！！
另外一个问题：如果有海量的用户量，那么频繁的用户登录、注册、授权等行为，是不是也需要考虑用MongoDB或者Redis等取代MySQL？
回答：
我不建议你进行全部替换，MongoDB和MySQL的共同之处都是为了应对在线业务处理尤其是WEB和电商的业务处理。但它们之间是有不同擅长的领域，要懂得量材器使。
MySQL作为RDBMS的一个成员，自然非常擅长做密集关系业务的处理，基本上遇到复杂的关系型问题，除非你用图处理，MySQL还是必须要用的。可问题是你的数据呈现海量的增长，你怎么办？
首先要考虑MongoDB用在什么环境上进行替代，例如订单查询问题，尤其是海量订单的问题，完全可以交给MongoDB，关键是注意订单、商品、用户、物流四者之间的数据结构模式设计，能让MongoDB查起来更舒服，只要你给足内存，那MongoDB就是为海量而生。
其次非结构化数据的处理，电商页大量的宣传文档、宣传图片，这些都可以交给MongoDB来存储，虽然你仍然需要像Elasticsearch这样的专业文本搜索解决产品个性化查询。但是MongoDB至少可以在分类查找（facets）上提供足够的功能，免去用搜索引擎的麻烦。
再次当你把电商数据中几个数据量瓶颈环节的优化：订单、产品和文字图像用MongoDB进行替换，那么留给MySQL关系结构的数据表就是一副比较精炼的骨架。
对于MySQL面向海量的情况，除了读写分离之外，就只能注意分区的设计、优化了，所谓垂直切分，就是切数据，注意哪些是活跃数据就放到活跃分区，哪些是历史数据，按时间或者hash分区，注意倾斜。不建议一开始就搞成多库垂直切分，麻烦！
最后对于用户管理的在线量问题，前置分布式Redis做缓存，后端MySQL读写分离，负载读库，没有问题。除非大到要用到事件驱动，查询该用户推送，我相信很少有业务能大到那个程度。
补充最关键的一点是MySQL和MongoDB共存，就要有共存的方案，尤其是数据同步方案，要考虑MySQL binglog和MongoDB oplog同步的解决方案。
另外我想告诉你，每个业务都有其独特的一面，就只是你自己能去理解。任何大厂的解决方案对于99%的用户都是不适用的，那叫“幸存者模式”，打磨和定制好自己的架构格局更关键。
如果觉得写得不错，那就点个赞或者“在看”吧，多谢阅读。
文章均为“读字节”原创，转载务必注明来源。
点这里👇关注我
