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

Question

[Сергей Попов]

Добрый день.

Существует необходимость спроектировать сервис, ключевой особенностью которого планируется реализовать историю версий текстового документа. Ближайшим аналогом, обладающим данной фичей является история версий документа в Google Docs. Соответственно, необходимо максимально корректно подобрать базу данных к данной задаче.
Мною, предлагается использовать связку из двух баз: PostgreSQL для хранения метаинформации и данных необходимых для функционирования сайта и HBase в качестве хранилища для текстовых документов, включая их версии.

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

Comments

[sim3x]

Что из себя представляет "документ"?
Какой размер?
Почему не хранить все в постгресе?

[Артемий]

А cvs системы чем не устраивают?

[Сергей Попов]

sim3x, документ - текст. Произвольный. Все в постгресе хранить не стоит, на наш взгляд по той причине, что колоночная база больше подходит под задачу версионирования документов. Кроме того, постгрес не очень любит работать с большими (больше нескольких МБ) документами в одной колонке, а такие документы планируются. Добавь к этому с пару сотен версий этого документа и получи в итоге низкую производительность.. В данном случае, HBase будет более производительным и отказоустойчивым вариантом. Если есть контраргумент - я выслушаю с удовольствием. Для этого вопрос и задал:)

[Сергей Попов]

Артемий Прототипы, cvs хороши для разработки. Но пользоваться системой будут далеко не профессиональные программисты, для которых подобные решения - хлеб насущный. Следовательно, необходимо максимально уменьшить кривую входа на сервис и сделать его максимально удобным. Но предложение имеет смысл. Надо подумать в эту сторону.

[WayMax]

Артемий Прототипы, cvs хороши, но как ты сделаешь графическое отображение разницы между двумя версиями docx файла? Для кода то это элементарно, а вот для сложных документов.

[Артемий]

Сергей Попов, интерфейс сделайте для ламеров и будет вам счастье.

[Артемий]

WayMax, там же и редактор будет, значит html, значит и diff можно сделать.

[WayMax]

Артемий Прототипы, ок, расскажите мне как корректно "перегнать" docx в html

Answer 1

[Dimonchik]

alfresco посмотрите

Comments

[Сергей Попов]

К сожалению, Alfresco не подходит по самой своей сути. Это целостный продукт для организации документооборота в предприятии. По своей природе это EMC, а в данном случае, несмотря на все плюсы Alfresco, он не нужен. Необходима именно база данных, коей данный продукт не является.

Тем не менее, ответ хороший, за рекомендацию спасибо.

[Dimonchik]

))

посмотреть нужно КАК , сорри, что не сказал прямо

Answer 2

[xfg]

Можно посмотреть на архитектуру CQRS + Event Sourcing. Вместо того, чтобы хранить состояние сущности, хранят произошедшие с ней события. Накатив эти события в порядке очереди на сущность всегда можно получить состояние сущности на любой момент времени.

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

Базы данных можно брать любые, хотя обычно для ReadModel используют стандартную реляционную или документоориентированную, а для WriteModel можно взять что-нибудь более специализированное, например event store, просто потому что все фишки реляционных субд для этой части приложения не требуются.

Можно посмотреть примеры реализации event sourcing https://github.com/prooph/event-sourcing

Comments

[Сергей Попов]

Event Sourcing - отличный подход, ничего против него не имею. Однако, как было указано, усложняется чтение. Использование же двух хранилищ, если следовать CAP теореме, автоматически усложняет либо доступность, либо консистентность данных, сохраняя возможность масштабирования: надо придумывать какой-то обходной путь. Кроме того, основной операцией в наших реалиях будет чтение и необходимо максимально упрощать эту операцию. Операция же записи будет не такой частой.
Тем не менее, спасибо, что напомнили про этот подход, возможно, если мы не найдем другого варианта, он будет хорошим, особенно с учетом того, что нам необходимо обеспечить возможность восстановления при отказе без потерь данных, а он позволяет довольно удобно это реализовать.

[Rodres]

Сергей Попов, здравствуйте.

Скажите пожалуйста, к какому решению в результате пришли и с каким результатом? У меня аналогичная задача, поделитесь опытом?

[Сергей Попов]

Rodres, Воспользовался подходом с event-soursing + доп. состояние для чтения. Это чуток усложнило операцию чтения, но позволило мне свободно редактировать документы.