В чем разница между MongoDB / NoSQL, которая позволяет быстрее агрегировать (MapReduce) по сравнению с MySQL?

Question

Приветствие!

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

id, big_text, price, country, field1, field2, ..., fieldX

И мы выполняем запрос, подобный этому

SELECT .... WHERE 
[use FULLTEXT index to MATCH() big_text] AND 
[use some random clauses that anyway render indexes useless, 
like: country IN (1,2,65,69) and price<100]

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

(results) GROUP BY field1
(results) GROUP BY field2
(results) GROUP BY field3
(results) GROUP BY field4

Это упрощенный случай того, что мне нужно, актуальная задача еще более проблематична, например, иногда первый запрос результатов также имеет свою собственную GROUP BY,И примером такой функциональности может быть этот сайт http://www.indeed.com/q-sales-jobs.html (результаты поиска плюс фильтры слева)

Я сделал и все еще продолжаю глубокое исследование того, как функционирует MySQL, и на данный момент я полностьюне вижу этого возможного в MySQL.Грубо говоря, таблица MySQL - это просто куча строк, лежащих на жестком диске, а индексы - это крошечные версии этих таблиц, отсортированные по полю (ам) индекса и указывающие на фактические строки.Это, конечно, супер упрощение, но дело в том, что я не вижу, как вообще можно это исправить, то есть как использовать более одного индекса, чтобы иметь возможность быстро выполнять GROUP BY-s (к тому времени, когда запрос достигает GROUPИндекс BY совершенно бесполезен из-за поиска диапазона и прочего).Я знаю, что в MySQL (или аналогичных базах данных) есть различные полезные вещи, такие как слияние индексов, слабое сканирование индексов и т. Д., Но это просто неадекватно - выполнение вышеупомянутых запросов будет выполняться вечно.

Мне сказали, чтоЭта проблема может быть решена с помощью NoSQL, который использует несколько принципиально новых способов хранения и обработки данных, включая задачи агрегирования.Что я хочу знать, так это краткое схематическое объяснение того, как это происходит.Я имею в виду, я просто хочу быстро взглянуть на это, чтобы я действительно мог видеть, что это делает это, потому что в настоящий момент я не могу понять, как это вообще возможно сделать.Я имею в виду, что данные все еще являются данными и должны быть помещены в память, а индексы все еще являются индексами со всеми их ограничениями.Если это действительно возможно, тогда я начну детально изучать NoSQL.

PS.Пожалуйста, не говорите мне пойти и прочитать большую книгу по NoSQL.Я уже сделал это для MySQL только для того, чтобы выяснить, что он не пригоден для использования в моем случае :) Поэтому я хотел бы получить некоторое предварительное представление о технологии, прежде чем получить большую книгу.

Спасибо!

Answer 1

По сути, существует 4 типа «NoSQL», но три из четырех на самом деле достаточно похожи, чтобы поверх него мог быть написан синтаксис SQL (включая MongoDB и его сумасшедший синтаксис запросов [и я говорю, что, хотя Javascriptодин из моих любимых языков]).

Хранилище ключей-значений

Это простые системы NoSQL, такие как Redis, которые по сути представляют собой действительно необычную хэш-таблицу.У вас есть значение, которое вы хотите получить позже, поэтому вы назначаете ему ключ и помещаете его в базу данных, вы можете запрашивать только один объект за раз и только по одному ключу.

Вы определенно не 'Я не хочу этого.

Хранение документов

Это на один шаг выше хранилища ключей и значений, о котором большинство людей говорят, когда говорят NoSQL (например, MongoDB).

По сути, это объекты с иерархической структурой (например, XML-файлы, JSON-файлы и любые другие виды древовидной структуры в компьютерной науке), но значения различных узлов в дереве могут быть проиндексированы.Они имеют более высокую «скорость» по сравнению с традиционными базами данных SQL при поиске, поскольку они жертвуют производительностью при объединении.

Если вы ищете данные в своей базе данных MySQL из одной таблицы с тоннами столбцов (предполагая, что это не представление / виртуальная таблица), и если вы правильно его проиндексировали для своего запроса (здесь это может быть вашей реальной проблемой), базы данных документов, такие как MongoDB, не дадут вам преимущества Big-O по сравнению с MySQL, так что вывероятно, не хотят переноситься по этой причине.

Хранение столбцов

Это наиболее похожие базы данных SQL.Фактически, некоторые (например, Sybase) реализуют синтаксис SQL, а другие (Cassandra) - нет.Они хранят данные в столбцах, а не в строках, поэтому добавление и обновление обходятся дорого, но большинство запросов обходятся дешево, потому что каждый столбец по сути неявно индексируется.

Но если ваш запрос не может использовать индекс, вы 'с Columnar Store не в лучшей форме, чем обычная база данных SQL.

Хранилище графиков

Базы данных Graph расширяются на за пределы SQLВсе, что может быть представлено теорией графов, включая Key-Value, базу данных документов и базу данных SQL, может быть представлено базой данных графов, например neo4j.

Базы данных графов делают объединения как можно дешевле (в отличие от DocumentБазы данных), но они должны это сделать, потому что даже простой запрос «строки» потребует много соединений для извлечения.

Запрос типа сканирования таблицы будет , вероятно, медленнее, чемстандартная база данных SQL из-за всех дополнительных объединений для извлечения данных (которые хранятся несвязанным образом).

Так в чем же решение?

Вы, вероятно, заметили, что у меня нетТ точно ответил на ваш вопрос.Я не говорю «вы закончили», но реальная проблема заключается в том, как выполняется запрос.

1. Вы абсолютно уверены, что не можете лучше индексировать свои данные?Есть такие вещи, как Multiple Column Keys , которые могут повысить производительность вашего конкретного запроса.Microsoft SQL Server имеет полнотекстовый ключ типа , который будет применим к приведенному вами примеру, и PostgreSQL может эмулировать его .
2. real Преимущество, которое большинство баз данных NoSQL имеют над базами данных SQL, - Map-Reduce - в частности, интеграция полного полного языка Тьюринга, который работает с высокой скоростью, в которую могут быть записаны ограничения запросов. Функция запросов может быть написана так, чтобы быстро «потерпеть неудачу»«несовпадающих запросов или быстрого возврата с успехом к записям, которые отвечают« приоритетным »требованиям, в то же время делая то же самое в SQL - это немного более громоздко.

Наконец, однако, точную проблему выВы пытаетесь решить: текстовый поиск с дополнительными параметрами фильтрации, более широко известный как search engine, и есть очень специализированные механизмы для решения этой конкретной проблемы.Я бы порекомендовал Apache Solr для выполнения этих запросов.

По сути, выгрузите текстовое поле, поля «фильтра» и первичный ключ таблицы в Solr, разрешите ему индексировать текстовое поле, выполнить запросы через него, и, если вам потребуется полная запись после этого, запроситьваша база данных SQL для конкретного индекса, который вы получили от Solr.Он использует больше памяти и требует второго процесса, но, вероятно, лучше всего будет соответствовать вашим потребностям, здесь.

Зачем весь этот текст, чтобы получить к этому ответу?

Потому что заголовок вашего вопросане имеет никакого отношения к содержанию вашего вопроса, поэтому я ответил на оба вопроса.:)