Solr / rdbms, где хранить дополнительные данные

Question

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

т. Мне нужно дружественное имя / изображение / мета ключевые слова / описание / и многое другое .. для категорий товаров. (при огранке по категориям)

• включить это в документ? (может привести к появлению дубликатов)
• ввести категорию в качестве нового индекса в solr (или подделать в поле doctype = category в solr)
• используйте rdbms для поиска дополнительных данных, используя SELECT WHERE IN (..category Faced result ids ..)

Спасибо

РЕМКО

Answer 1

• используйте быструю базу данных NoSQL, соответствующую вашим данным

Кстати, Lucene, который является базовым уровнем Solr, на самом деле также является хранилищем типа NoSQL.

На вашем месте я бы использовал MongoDB. Это первое, что пришло в голову, так как вам нужны двоичные данные, а они практически изобрели BSON, который сейчас широко используется для передачи двоичных данных в JSON-подобной манере.

Если ваша структура данных более графоподобна (например, социальная сеть), проверьте Neo4j, в котором есть ослепительно быстрые алгоритмы обхода графа.

Answer 2

Реляционная БД может надежно обеспечивать выполнение функции "категория - это объект первого класса". Вам потребуется ссылочная целостность : продукт может не принадлежать к категории, которой не существует. В удаленной категории не должно быть дочерних категорий. Нормализованная RDB может обеспечить ссылочную целостность через схему. БД NoSQL должна работать с клиентским кодом (вы должны писать) для обеспечения ссылочной целостности.

---

Посмотрим, как выполняются «категория продукта должна существовать» и «родители подкатегории должны существовать»:

RDB : Таблица, которая присваивает категории продуктам (отношение m: n), должна быть привязана к продукту и категории с помощью ON DELETE CASCADE. Если категория удалена, продукт просто не может иметь такую ​​категорию. Категория, которая связана с другой категорией в качестве дочерней: поле relayvent имеет ON DELETE CASCADE. Это означает, что если родитель удален, его дети не могут существовать. Весь этот метод является декларативным («он объявлен таким образом»), все сложности существуют в данных, нам не нужен вонючий код, чтобы сделать это за нас. Вы можете смоделировать DB так же естественно, как и , понимая их последствия для реального мира.

Тип хранилища документов NoSQL : вам нужно написать код, чтобы сделать все. «Категория удалена» - это вариант использования , и вам нужно найти продукты, которые имеют эту категорию, и обновить каждый из них. Вы должны написать код для каждого варианта использования. То же самое касается управления подкатегориями. Модель данных может быть невероятно глупой, но их реальное значение должно быть смоделировано в коде . И его сложнее рассуждать в коде и потоке управления, чем в структурах данных .

У вас действительно есть потребности в производительности, требующие баз данных NoSQL?

Так что используйте РСУБД для управления вашими данными. Затем используйте обработчик прямого импорта или код на стороне клиента, чтобы вставить / обновить денормализованные объекты для поиска. Если большинство запросов на ваш сайт может быть выражено в запросах Solr, то отлично!

---

Что касается выражения иерархической огранки в Solr, см. ' Способы выполнения иерархической огранки в Solr? '.

Answer 3

возможно, я ошибаюсь, но если вы находитесь на соединительной линии Solr, вы можете воспользоваться Solr join suport , это позволит вам индексировать несколько сущностей с отношениями между ними, одновременно применяя условия для обоих.

Answer 4

Я бы подумал о 2 альтернативах:

1.) Сильная информация для каждого документа без его индексации (чтобы индекс был как можно меньше).Дело в том, что я не буду хранить представление об изображении Lucene / Solr - только указатель файла.

2.) Хранит дополнительные данные в rdbms или nosql (linke mongoDB) для поиска, как вы написали.

Мой любимый 2-й.один, потому что база данных является традиционным и наиболее оптимизированным способом хранения данных.Но, наконец, это зависит от вашей системы, потому что вы должны помнить, что вам нужно время для подключения базы данных, поиска в данных и отправки дополнительной информации обратно в приложение.Так что может быть быстрее хранить все в lucene.

Возможно, небольшой тест производительности будет полезен.