Лучший NoSQL для фильтрации по нескольким индексам/полям

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

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

Структура примера будет такой

[
 {"name": "item name",
  "cost": 563.34,
  "category": "computer",
  "manufacturer: "sony",
.
.
.
 }
]

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

Я изучил: Elastic Search, mongodb, OrientDB, Couchbase и Aerospike.

  • Elastic Search кажется очевидным выбором, но меня интересует производительность и стабильность?
  • Кажется, что Aerospike будет очень быстрым, поскольку он делает все это в основном в памяти, но его возможности фильтрации и поиска не кажутся такими уж способными.

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

Я знаю, что лучший способ — протестировать производительность в реальном сценарии использования, но я надеюсь сначала немного сузить его.

Спасибо


person Faruk Brbovic    schedule 04.02.2015    source источник


Ответы (3)


Это вариант популярного вопроса "какой товар лучше" :)

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

Поскольку ваш вопрос касается данных о продуктах, а я работаю с данными о продуктах более 15 лет, я попытаюсь ответить на ваш вопрос.

  • Модель документа идеально подходит для данных о продукте. Поэтому для всех случаев использования, кроме простого поиска, я бы рекомендовал хранилище документов.
  • Если ваш вариант использования касается одного приложения, и вы используете платформу Java. Я бы рекомендовал использовать встроенную базу данных. Это упрощает работу и дает большое преимущество в производительности.
  • Если вам нужен фасетный поиск или другой расширенный поиск продукта, я рекомендую вам использовать SOLR или Elastic Search.
  • Если вам нужна распределенная система, я рекомендую Elastic Search вместо SOLR.
  • Если вам нужны рекомендации по продуктам, основанные на обзорах или других алгоритмах, ориентированных на графы, я рекомендую использовать OrientDB или ArangoDB (или Neo4J, но в этом случае это будет мой второй выбор)

Продукты, которые мы используем в производстве или тщательно оцениваем для описанного вами варианта использования,

  • СОЛР и ЕС. Оба чрезвычайно хорошо спроектированных продукта. Оба (также ES) зрелые и стабильные продукты
  • Нео4Дж. Самая зрелая графовая база данных. Большим преимуществом IMO является потрясающий язык запросов, который они используют. Интегрированный движок Lucene. Очень зрелый и хорошо спроектированный продукт. Недостатком является тот факт, что это не график документов, а график свойств (ключ-значение). Также это может быть дорого
  • МонгоДБ. Наш первый опыт работы с Document store. Очень хороший продукт. Большое преимущество: отличная документация, (безусловно) самая популярная база данных NoSQL.
  • ОриентДБ и АрангоДБ. Оба поддерживают парадигму Graph/Document. Это менее известные продукты, но очень мощные. Поскольку мы являемся магазином на основе Java, мы отдаем предпочтение OrientDB. OrientDB имеет встроенный движок Lucene (хотя реализация довольно проста). С другой стороны, ArangoDB имеет очень хорошую документацию и очень умный и эффективный формат хранения, и, наконец, AQL тоже очень хорош!
  • Производительность: (проверено с 11,43 млн статей и 2,3 млн продуктов). Все продукты очень быстрые, особенно SOLR и ES в этом случае использования. Встроенный OrientDB также невероятно быстр для импорта и простых запросов. Для многогранного поиска только поисковые серверы обеспечивают действительно высокую производительность!
  • Итог: я бы выбрал хранилище графиков/документов и/или сервер поиска (SOLR или ES). Потому что вы упомянули «фильтрацию» (я предполагаю многогранный поиск). Поисковый сервер является очевидным первым выбором
person rmuller    schedule 05.02.2015
comment
Да, мне кажется, что OrientDB или ES будут лучшим выбором. Спасибо за ваш подробный ответ. - person Faruk Brbovic; 05.02.2015

составные индексы для нескольких полей. Пример:

CREATE INDEX Product_idx ON Product (name, category, manufacturer) unique

SELECT FROM INDEX:Product_idx WHERE key = ["Donald Knuth", "computer"]

Вы также можете создать ПОЛНОТЕКСТОВЫЙ индекс, используя всю мощь Lucene в качестве движка.

person Lvca    schedule 04.02.2015

Aerospike — это хранилище ключей, а не база данных документов. База данных документов будет лучше выполнять такое индексирование на уровне полей и более глубокий поиск во вложенных объектах. В настоящее время вторичные индексы в Aerospike (версия 3.4.x) работают со строковыми и целочисленными «корзинами» (концепция, аналогичная полю документа или столбцу таблицы SQL).

Тем не менее, список и карта сложных типов Aerospike дополняются этими возможностями, работа которых ведется в этом квартале. Следите за этими изменениями в следующих выпусках. Вы сможете индексировать и запрашивать корзины типа списка и карты.


person Ronen Botzer    schedule 05.02.2015