Преобразование устаревшей схемы EAV в Mongo или Couch

Question

Допустим, у меня есть унаследованное приложение, которое по разным причинам решило, что предыдущие разработчики должны иметь произвольно гибкую схему, и они снова изобрели модель Entity-Attribute-Value. Они на самом деле пытались создать хранилище документов, для которого такие инструменты, как Mongo или Couch, теперь лучше подходили бы в современном мире, но не были доступны или не известны предыдущим командам.

Чтобы оставаться конкурентоспособными, скажем, нам нужно создать более мощные методы для запроса и анализа информации в нашей системе. Судя по большому количеству и разнообразию атрибутов, кажется, что карта / уменьшение лучше подходит для нашего набора проблем, чем постепенная реорганизация системы в более реляционную схему.

Исходная база данных содержит миллионы документов, но только небольшое количество различных типов документов. Есть некоторые общие черты между различными типами документов.

Какова эффективная стратегия для перехода от массивной реализации EAV, скажем, в MySql, к ориентированному на документы хранилищу, например, Mongo или Couch?

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

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

Answer 1

Мое первое использование Couch было после того, как я написал веб-сканер Ruby и Postgres (направил обход mp3-блогов для создания механизма рекомендаций).

Реляционная схема стала очень сложной, когда я попытался записать ID3метаданные, звуковые подписи и т. д. и т. д., а также обнаружение совпадений и иным образом дедупликации.Это работало, но было медленно.Настолько медленно, что я начал кэшировать свои строки API JSON в соответствующие первичные объекты ActiveRecord в виде полей BLOB-объектов.

У меня был выбор: изучить и изучить настройку производительности Postgres или перейти к горизонтальному подходу.Поэтому я использовал Nutch и Hadoop для паутинки в сети, а PipeMapper - для анализа страниц с помощью Ruby / Hpricot.Таким образом, я смог повторно использовать весь свой код синтаксического анализатора и просто изменить его с сохранения в виде нормализованной базы данных на сохранение в формате JSON.Я написал небольшую библиотеку для обработки конечных точек URL-адресов JSON и REST под названием CouchRest, которую я использовал для сохранения результатов Hpricot в CouchDB.

Для этого проекта я просто запустил Couch на одном узле EC2 смаленький кластер Hadoop с 6 узлами, заполняющий его.Только когда я приступил к созданию интерфейса просмотра данных для пауков, у меня действительно появилось хорошее представление о возможностях запросов.

Я оказался гибким и особенно хорошо подходил для приложений OLTP.быстро начал использовать его во всех моих проектах и ​​в конечном итоге основал компанию по разработке технологий с двумя создателями.