与以前相比，现在（2022 年）mysql 中的分片变得如何变得更容易？
我目前正在实施一个副项目，我必须在其中选择数据库。下面列出了基本注意事项：
- 架构不严格，可能有许多空字段。
- 应该有一种简单的方法来进行模糊文本搜索。
- 它应该以最少的工作水平扩展。
- 它只有一个需要执行插入和文本搜索的实体。
我首先评估了 MySQL，但由于第 2 点和第 3 点而放弃了它。此外，第 1 点暗示基于文档的数据库可以在这里工作。我通过搜索各种文章了解到，对于 mySQL：
- 文本索引虽然受支持，但在分区（或分片）表中不起作用。 （参考）
- 即使有文本索引模糊搜索实现起来并不是很简单。
所以我在这个场景中选择使用mongoDB。但后来我读了 这篇 文章，其中提到水平缩放已成为与以前相比，mySQL 更容易。
根据我对 mySQL 中水平扩展的理解，您需要指定分片键，这需要在应用程序层进行更改。
考虑到我之前列出的注意事项，是否有更好的方法来实现水平缩放。
更新：
- 主要查询将涉及两列的文本搜索。
- 想要有一种简单的方法来分片数据库。 （不是分区）
I was currently implementing a side project where I had to make a choice for database. The basic considerations are listed below:
- The schema is not strict and could have many empty fields.
- There should be an easy way to have fuzzy text search.
- It should scale horizontally with minimal work.
- It only has one entity on which insertion and text searching needs to be performed.
I first evaluated MySQL but was turned away from it because of points 2 and 3. Also 1 implied that a document based database could work here. I learned from searching through various articles that for mySQL:
- Text index though supported will not work in partitioned(or sharded) tables. (reference)
- Even with text indexes fuzzy searching will not be very straightforward to implement.
So I made the choice of using mongoDB in this scenario. But then I read this article which mentions that horizontal scaling has become easier on mySQL compared to before.
As per my understanding for horizontal scaling in mySQL you need to specify sharding key which will require changes at application layer.
Is there a better way to achieve horizontal scaling with the considerations that I have listed earlier.
Update:
- The primary queries will involve text searching over two columns.
- Want to have an easy way to shard the db. (not partition)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论