Специализированная фасетная поисковая система для работы с динамическими таксономиями - помогает только с производительностью или еще и гибкостью?

StackOverflow https://stackoverflow.com/questions/2081148

Вопрос

Я некоторое время думал о моделировании типичного сайта электронной коммерции с таксономией, подобной ebay, и атрибутами, зависящими от конкретной категории товаров.

Первой попыткой был выбор между EAV и моделированием наследования базы данных Table для каждого класса.Я выбрал последнее из-за производительности, но это означало создание специальной таблицы для каждой конкретной (лист в дереве категорий) категории продуктов с определенными атрибутами категории (например, разрешением для телевизоров), смоделированными в виде отдельного столбца.

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

  • Изменить / создать таблицу
  • Новая форма для фильтрации внутри такой категории по определенным атрибутам
  • Новый код для генерации запросов к базе данных для поиска и фильтрации
  • Некоторые новые viewmodels / DTO и представления для представления продуктов из новых категорий

Чтобы справиться с этой сложностью, я думаю, необходимо какое-то метапредставление этих атрибутов (даже вне приложения) в xml или даже файле Excel, чтобы при каждом изменении весь упомянутый код мог автоматически генерироваться (запросы sql / orm, код приложения, шаблоны).Таким образом, это может помочь в разработке, но все равно требуется тестирование и дополнительное развертывание.

На этом этапе я узнал, что ebay на самом деле не использует реляционную базу данных для поиска и что их таксономия настолько гибкая, что они могут довольно быстро добавлять новые категории листа.Кроме того, их категории, вероятно, не являются категориями из иерархического дерева, смоделированного в реляционной базе данных, а просто атрибутами поиска (фасетами).

После краткого ознакомления с наиболее перспективной настройкой выделенного фасетного поиска (отдельный экземпляр Solr) Я не уверен, может ли это помочь мне быть гибким к изменениям таксономии, поскольку обычно Solr просто каким-то образом отражает реляционную базу данных, поэтому атрибуты конкретной категории все равно должны быть смоделированы в DB как метаданные СУБД, например.динамическая генерация форм пользовательского интерфейса для фильтрации атрибутов была бы затруднительной, если бы:

1) Я бы сохранил данные в СУБД, используя EAV fasion, и преодолел бы проблемы с производительностью с помощью SOLR search (но все равно были бы проблемы с беспорядком EAV, отсутствием контроля целостности данных и т.д.)

2) Я бы сохранил только словарь атрибутов (т.е.только их имена и типы) в RDBMS и сохраняйте конкретные значения атрибутов в SOLR, используя его как своего рода нереляционное хранилище данных отдельно от средства поиска.Я также не убежден в этом решении (даже если это возможно), поскольку приложение будет тесно связано с solr (т. Е.администратор редакции продукта CRUD будет взаимодействовать с SOLR напрямую).

О чем вы думаете?Считаете ли вы, что для любого вида такой (производительной) гибкости таксономии генерация кода неизбежна?Как бы вы справились с этим?Может быть, какой-нибудь отдельный словарь данных в формате EAV в БД только для целей генерации кода?Я думаю, я мог бы также использовать что-то вроде MongoDB, но для генерации кода пользовательского интерфейса (во время выполнения или нет) все равно понадобились бы какие-то метаданные.

Здесь много вопросов, но я не хотел разбивать их на более мелкие вопросы, поскольку меня интересует общий подход к проектированию при работе с большим классом таких проблем.

Это было полезно?

Решение

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

  1. Я бы забыл о моделировании этого на RDBMS. Фасетный поиск просто не работает в реляционной схеме.
  2. ИМО, это неподходящее место для генерации кода.Вы должны разработать свой код таким образом, чтобы он не менялся при изменении данных (я не говорю о схема изменения).
  3. Хранение метаданных / атрибутов в электронной таблице Excel кажется очень плохой идеей.Я бы создал пользовательский интерфейс для редактирования этого, который был бы сохранен в Solr / MongoDB / CouchDB / независимо от того, что вы выберете для управления этим.
  4. Солр не делает "просто зеркально отображайте реляционную базу данных".Фактически, Solr полностью независим от реляционных баз данных.Один из наиболее распространенных случаев является сброс данных из СУБД в Solr (денормализация данных в процессе), но Solr достаточно гибка, чтобы работать без какого-либо реляционного источника данных.
  5. Иерархическое огранение в Solr это все еще открытый вопрос в исследованиях.В настоящее время исследуются два отдельных подхода (СОЛР-64, СОЛР-792)

Другие советы

Что, если бы у вас были разные типы категорий для разных типов продуктов?

Взяв пример eBay, мы бы имели Продукты это может быть либо Книги или Телевизоры / Дисплеи.

Книги имеют название и ISBN и могут относиться к категории научной фантастики, или к эротической категории, или к категории нехудожественной литературы, или к автобиографической категории.Или, может быть, у вас есть книга, относящаяся к категории нехудожественной, автобиографической эротики.

Дисплеи имеют разрешение экрана и потребляемую мощность в ваттах (?) и могут относиться к категории плоских экранов, ЭЛТ или HD.

С чисто реляционной точки зрения вы могли бы может быть смоделируйте это примерно так:

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

Вместо моделирования attributes dependent on a particular product category, у вас были бы разные свойства и категории зависит от тип/класс продукта.

Видишь супертипы и подтипы

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top