хранение изменений ревизии сообщения

Question

Какие алгоритмы и процессы участвуют в хранении изменений ревизий, как, например, stackoverflow и wikipedia?

Сохраняется только одна копия сообщения? И если так, то это только последняя копия? Тогда только изменения, чтобы вернуться к предыдущей версии (версиям) сохранены оттуда? (Это сделало бы для более быстрого отображения основного сообщения). Или полные сообщения хранятся? И если да, то выполняется ли сравнение между ними на каждом дисплее?

Какие алгоритмы лучше всего использовать для точного определения изменений в сообщении? Как эти данные хранятся в базе данных?

Если кто-нибудь точно знает, что википедия или stackoverlfow делает, я бы хотел знать.

Answer 1

Mediawiki (программа для Википедии) хранит полный текст для всех ревизий, см. Схему базы данных . Каждая запись в текстовой таблице в Mediawiki имеет флаги, указывающие, был ли контент, например, gziped, использование стандартного сжатия часто является самым разумным вариантом.

Я не могу сказать вам, как сделать различие алгоритмически, но какой бы алгоритм вы ни использовали, вы должны делать это из двух полных версий текста. То есть получить полную версию старого и нового объекта из базы данных, а затем выполнить diff. Это позволяет легко изменить алгоритм диффузии.

Git является отличным примером Unix-приложения, которое может сделать очень дешевое (хранение и ускорение) дельта-хранилище. Есть вики, которые могут использовать git, например ikiwiki , но я предполагаю, что вы хотите сделать это с базой данных.

Answer 2

Алгоритм самой длинной общей подстроки можно использовать для обнаружения различий между версиями, но он ограничен. Например, он не обнаруживает перемещение текста как таковое, но рассматривает это как несвязанные удаления и вставки.

Я полагаю, что веб-сайты обычно хранят последнюю копию полностью и применяют обратные различия оттуда. Так же работает CVS , но Subversion использует прямую разницу, что приводит к более медленным проверкам.

Чтобы сохранить это в базе данных, можно вести основную таблицу с последними версиями и иметь отдельную таблицу с обратными различиями. Эта таблица будет иметь строки в формате (article_id, revision_id, differences).

Answer 3

Обычно сообщения хранятся как полные снимки. Предыдущие версии отключены, а самая последняя отображается. Может использоваться оптимизация, например, кэширование, какая версия является самой последней.

Answer 4

Принято довольно плохо .. Проблемы:

• медленно
• не на будущее
• осложнено

Answer 5

Я бы использовал следующую технику:

• Сохранить текущее сообщение как полный текст.
• Сохранение истории с использованием дельта-алгоритма.

Это обеспечит хорошую производительность благодаря регулярному отображению при сохранении минимального объема памяти для истории.

Answer 6

Типичные изменения редакции хранятся с использованием дельта-алгоритма, поэтому сохраняются только данные в каждой редакции по отношению к оригиналу. Я не уверен в википедии или в стеке потока, как они это реализовали.