Organization of the audit system in the database?

Question

MySQL

Given:

1. Application written in PHP with MySQL (Yii Framework);
   
2. Several content types, such as setting and node. Stored in different tables with their own set of fields;
   
3. Approximately 10k users of an application with a very frequent update of one of the content types, let's say node. During editing, a node can be updated up to several times per second (with the creation of new revisions). At the same time, some nodes may not be updated for months, and some every day several times.
   

You need to do something like a version control system to keep multiple client applications in sync with the server. A good example is the Xmarks browser extension.
The question is how to store revisions (and changes to them) in the MySQL database?
The following solution came to my mind:
One table that stores all content changes. It looks like this:
rev action type id args
1 insert node 1421 { text: 'custom node', created: 1236124121 }
2 update node 1421 { text: 'asd', modified: 1237123134 }
3 update node 1421 { title: 'example node', modified: 1238123814 }
3 insert node 1422 { field: new_value }
3 update setting 12 { email: '[email protected]' }
4 update node 1422 { field: new_new_value }
4 update setting 12 { email: '[email protected]' }
5 delete node 1421 {}

• Rev is the revision number of the user. There can be multiple entries within one revision.
  
• Action - type of changes. insert|update|delete.
  
• Type - content type. For example node or setting.
  
• id - content identifier.
  
• Args is a json object with a change log.
  

I do not know how correct it is to store revisions in this way, in one table. Let's say each user has 5k revisions - that's already 50 million records! How will MySQL deal with this, given that there is a constant write to the table?
How can this problem be solved in the most rational way? Ready to consider options using other databases, incl. NoSQL.
Thank you very much for your help.
UPD:
There is an option to refuse the ability to restore old revisions. This way it is possible to exclude update records and store only the latest revision in the content table.
Then the table will be reduced by 10 times, and there will be about 5 million records in it. How much does it simplify the task? How will MySQL behave in this case?

Answer 1

If it is possible to refuse to restore old revisions, then you can store, say, the last N-pieces. If the number of records in the database is so scary, then why not make a different type of relationship in your table, you now have one to many, but make it one to one (by id), and write the entire history of changes in args, indicating the action, already directly in args. Here, the truth must be remembered that the length of the fields is also not infinite, and everything probably will not fit.
The second option is indeed to use a NoSQL database, for example CouchDb, or something like that, I think that this will be even the most correct option.