Question 258244 in Mysql Question posted in
The official MySQL documentation can be found here.

Scalibility challenges of MYSQL

I need someone expert advice here.

For my chat application, I’m using MYSQL. As I have structured messages so I chose mysql. Now My concern is about the scalibility and throughput.

I spent time analizing DynamoDB in terms of scalibility and throughput. It sounds good idea as it can handle any scale, but the pricing and data limit per row is concern for me. I’m confused should I move to DynamoDB, As we definately predicting large amount of messages getting exchanged in near future. We want to handle any amount of read and write without any downtime.

I’m not much familiar that how MYSQL should be scaled. I now the concepts of Sharding using consistence hashing but never have implemented. I’m looking for solution where we don’t have to manage the scalibility things manually, like as per my understanding right now I have to direct the request to the respected shard if I’m going to shard MYSQL.

Can someone please suggests me should I migrate to DynamoDB considering my worries, Or if you can explain me how I can perfectly scale MYSQL without much manual interaction and any downtime.
For more context, We have running our application on kuberenetes and willing to put MYSQL also on kuberenetes, but As I’m not much familiar regarding the MYSQL scalibility not sure what will be best here.

Tags:

2

Answers


  1. 0

    Your worries are really only the item(row) limit size of DynamoDB. However, if you correctly model your data in DynamoDB you can easily overcome this challenge.

    For example, this would be the wrong data model to choose

    PK Messages
    chatId123 [msg1,msg2,msg3…]

    This would be a better approach, it provides smaller items but also enhances the flexibility of querying.
    PK | SK | Msg
    —|—|—
    chatId123 | MSG#msg1 | message content
    chatId123 | MSG#msg2 | message content
    chatId123 | MSG#msg3 | message content

    Login or Signup to reply.
  2. 0

    You will likely hit the limits of storage engine before you reach the limits of mysql in terms of capacity.

    With Innodb, using the default 16Kb block size, that’s 64Tb per file. Which is rather a lot of data. But Innodb can store multiple tables in a single file (the default configuration) one table per file and can partition one table across multiple files. And you can transition between these (although it will take time to move around big chunks of data).

    A requirement for sharding is probably way beyond your planning horizon for now – but capturing and storing information which support sharding based on intrinsic data may prevent pain in future. If your data already has attributes which could be used for sharding this will be much more useful than hashing.

    If you are talking about petabytes of data, then you need more help than some q&a here. Hire a specialist consultancy.

    We want to handle any amount of read and write without any downtime

    That’s an availability issue – not a capacity issue. DynamoDB is not a magic cure for this. Make sure you understand CAP theorem and replicate; you need a at least one hot replica and consider using ProxySQL or similar to manage routing.

    ….and see https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search