Простые возможности поиска с помощью NoSQL (DynamoDB)

#amazon-web-services #elasticsearch #nosql #amazon-dynamodb #data-modeling

Вопрос:

Я новичок в NoSQL. Я пытаюсь сделать простое приложение, в котором будут продукты, которые вы будете искать. С помощью SQL у меня была бы просто таблица продуктов, и я мог бы искать в любом из столбцов подстроки %LIKE% и извлекать возвращенные строки. Я хотел бы использовать DynamoDB, но, по-видимому, это невозможно сделать без внедрения AWS OpenSearch (ElasticSearch), который, вероятно, будет стоить больше, чем все мои таблицы DynamoDB. Есть ли какой-нибудь простой способ сделать это в DynamoDB без необходимости сканирования всей таблицы и фильтрации с contains помощью ?

Комментарии:

1. Если вам требуется такая функциональность, то DynamoDB-неподходящий инструмент для вас. Просто используйте обычную базу данных, такую как MySQL.

2. какое приложение в наши дни не требует такой функциональности, это простой поиск ? когда NoSQL будет актуален ?

3. NoSQL не является заменой традиционным базам данных. У него разные варианты использования и назначение. Вам явно требуется традиционная база данных.

Ответ №1:

Итак, DynamoDB-это не то, что вы ищете, он предназначен для совсем другого варианта использования.

Однако ElasticSearch, который никоим образом не связан с DynamoDB, — это то, что вы ищете, и это значительно упростит то, что вы пытаетесь сделать с помощью традиционной базы данных SQL. Те, кто утверждает обратное, предоставляют плохую информацию. Традиционная база данных не может индексировать запрос %КАК%, где именно это делает ElasticSearch для каждого поля в вашем документе.

Начать работу с ElasticSearch очень просто. Просто скачайте Jar и запустите его, затем начните просматривать примеры размещения и получать документы из индекса. Если ваш опыт чем-то похож на мой, вы никогда больше не захотите использовать базу данных SQL, но, как уже упоминалось, у каждой из них есть свое место, и поэтому я все еще использую традиционные СУБД, но я специализируюсь на ElasticSearch.

Я преобразовал многие приложения, которые не смогли найти приемлемую производительность, в ElasticSearch, где производительность почти всегда ниже второй, и, как правило, составляет лишь часть этого. СУБД, которой будет предложено выполнить много %ПОДОБНЫХ% совпадений, не сможет предоставить вам второсекундные результаты.

Существует также ряд инструментов, которые автоматически перенаправляют данные из вашей базы данных СУБД в ElasticSearch, чтобы вы могли воспользоваться преимуществами обоих миров.

NoSQL означает очень многое. В целом он был применен к нескольким классам хранилищ данных.

Столбчатое хранилище данных — DynamoDB, База данных документов/объектов Hive — MongoDB, CouchDB, Логика метки и множество других Ключей/значений — Cassandra, MongoDB, Redis, Индекс поиска Memcache — SOLR, ElasticSearch

ElasticSearch устраняет разрыв между базой данных документов и индексом поиска, предоставляя возможности и того, и другого. Он также предоставляет возможности хранилища данных «Ключ/значение».

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

Однако ElasticSearch обеспечивает очень быстрый поиск по большому количеству документов JSON, индексируя по умолчанию каждое значение в json.

Способ сделать это с помощью dynamodb-использовать ElasticSearch, однако для этого вам не нужен DynamoDB с помощью ElasticSearch, поэтому вам не нужно удваивать стоимость.

Ответ №2:

Нет, нет никакого способа сделать то, что вы хотите (поиск в dynamodb), без добавления другого слоя, такого как elasticsearch — все просто, используйте традиционную базу данных.

ИМО, никогда не предполагайте, что вам нужна база данных nosql — потому что вы редко это делаете — всегда предполагайте, что вам нужна традиционная база данных, пока не будет доказано обратное.

Комментарии:

1. Это очень специфичный случай, когда СУБД падает, и поисковый индекс сияет. Единственный способ, которым СУБД может обеспечить даже полуразумные результаты для таких запросов, — это если она включила полнотекстовую поисковую систему под капотом. Если вам действительно нужен полнотекстовый поиск, то зачем брать на себя накладные расходы СУБД и терять производительность, которой вы бы достигли в противном случае.