Дано:
- Приложение, написанное на PHP с MySQL (Yii Framework);
- Несколько типов контента, например setting и node. Хранится в разных таблицах со своим набором полей;
- Около 10к пользователей приложения с очень частым обновлением одного из типов контента, допустим node. Во время редактирования node может обновляться до нескольких раз в секунду (с созданием новых ревизий). В тоже время, некоторые node могут не обновляться месяцами, а некоторые каждый день по нескольку раз.
Необходимо сделать что-то вроде системы контроля версий, чтобы синхронизировать несколько клиентских приложений с сервером. Хороший пример: расширение для браузеров Xmarks.
Вопрос заключается в том, как хранить ревизии (и изменения в них) в базе MySQL?
Мне на ум пришло такое решение:
Одна таблица, которая хранит все изменения контента. Выглядит это примерно так:
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: 'Oo@mail.ru' }
4 update node 1422 { field: new_new_value }
4 update setting 12 { email: 'mail@mail.ru' }
5 delete node 1421 {}
- Rev – номер ревизии пользователя. В рамках одной ревизии может быть несколько записей.
- Action – тип изменений. insert|update|delete.
- Type – тип контента. Например, node или setting.
- Id – идентификатор контента.
- Args – объект json с логом изменений.
Не знаю, насколько правильно хранить ревизии таким образом, в одной таблице. Допустим, у каждого юзера будет по 5к ревизий – это уже 50 млн. записей! Как с этим будет справляться MySQL, если учесть, что идет постоянная запись в таблицу?
Как можно решить данную проблему наиболее рационально? Готов рассмотреть варианты с использованием других БД, в т.ч. NoSQL.
Большое спасибо за помощь.
UPD:
Есть вариант отказаться от возможности восстановить старые ревизии. Таким образом, можно исключить update записи и хранить только последнюю ревизию в таблице контента.
Тогда таблица сократиться в 10 раз, и в ней будет около 5 млн. записей. Насколько это упрощает задачу? Как поведет себя MySQL в таком случае?
