#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. Это очень специфичный случай, когда СУБД падает, и поисковый индекс сияет. Единственный способ, которым СУБД может обеспечить даже полуразумные результаты для таких запросов, — это если она включила полнотекстовую поисковую систему под капотом. Если вам действительно нужен полнотекстовый поиск, то зачем брать на себя накладные расходы СУБД и терять производительность, которой вы бы достигли в противном случае.