Специализированная фасетная поисковая система для работы с динамическими таксономиями - помогает только с производительностью или еще и гибкостью?
-
21-09-2019 - |
Вопрос
Я некоторое время думал о моделировании типичного сайта электронной коммерции с таксономией, подобной 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, но для генерации кода пользовательского интерфейса (во время выполнения или нет) все равно понадобились бы какие-то метаданные.
Здесь много вопросов, но я не хотел разбивать их на более мелкие вопросы, поскольку меня интересует общий подход к проектированию при работе с большим классом таких проблем.
Решение
Я не утверждаю, что у меня есть окончательный ответ на все это (это довольно открытый вопрос, который вы должны попытаться разбить на более мелкие части, и это зависит от ваших реальных требований, на самом деле у меня есть соблазн проголосовать за его закрытие), но я прокомментирую несколько вещей:
- Я бы забыл о моделировании этого на RDBMS. Фасетный поиск просто не работает в реляционной схеме.
- ИМО, это неподходящее место для генерации кода.Вы должны разработать свой код таким образом, чтобы он не менялся при изменении данных (я не говорю о схема изменения).
- Хранение метаданных / атрибутов в электронной таблице Excel кажется очень плохой идеей.Я бы создал пользовательский интерфейс для редактирования этого, который был бы сохранен в Solr / MongoDB / CouchDB / независимо от того, что вы выберете для управления этим.
- Солр не делает "просто зеркально отображайте реляционную базу данных".Фактически, Solr полностью независим от реляционных баз данных.Один из наиболее распространенных случаев является сброс данных из СУБД в Solr (денормализация данных в процессе), но Solr достаточно гибка, чтобы работать без какого-либо реляционного источника данных.
- Иерархическое огранение в 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
, у вас были бы разные свойства и категории зависит от тип/класс продукта.
Видишь супертипы и подтипы