CouchDB и MongoDB действительно выполняют поиск по каждому документу с помощью JavaScript?

Question

Из того, что я понимаю об этих двух базах данных "Не только SQL".Они выполняют поиск по каждой записи и передают ее в написанную вами функцию JavaScript, которая вычисляет, какие результаты должны быть возвращены, просматривая каждую из них.

Так ли это на самом деле?Звучит хуже, чем использование простой RBMS без каких-либо индексированных ключей.

Я построил свои схемы, чтобы они не требовали операций соединения, поэтому я выполняю простой поиск по индексированным столбцам int.Другими словами, столбцы находятся в ОЗУ , и быстрая проверка значений через них (WHERE user_id IN (12,43,5,2) или revision = 4) дает базе данных простой список идентификаторов, который она использует для поиска в реальных строках вмассивный сбор данных.

Поэтому я пытаюсь представить, как в мире, просматривая каждую строку в базе данных, можно считать приемлемым (если это действительно так).Возможно, кто-то может исправить меня, потому что я знаю, что я что-то упускаю.

Answer 1

@ Xeoncross

Я построил свои схемы так, чтобы они не требовали операций соединения, что оставило меня с помощью простого поиска по индексированным столбцам int.Другими словами, столбцы находятся в оперативной памяти, и через них можно быстро проверить значение (ГДЕ user_id IN (12,43,5,2) или revision = 4)

Хорошо, тогда вам понравитсяMongoDB.MongoDB поддерживает индексы, так что вы можете индексировать user_id и revision, и этот запрос сможет возвращаться относительно быстро.

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

Поэтому я пытаюсь представить, как в мире просмотр каждой строки в базе данных может считаться приемлемым (если действительно так оно и работает).).

Хорошо, если вы выполняете запрос в базе данных на основе SQL, и у вас нет индекса, база данных будет выполнять сканирование таблицы (, т. Е. Просматривая каждую строку * 1018).*).

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

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

Вот, возможно, другой подход к NoSQL.SQL действительно хорош в реляционных операциях, однако реляционные операции не очень хорошо масштабируются.Вместо этого многие из NoSQL сосредоточены на концепциях Key-Value / Document-ориентированных.

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

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

Это не решение для всего, но это действительно хороший вариант для многих случаев использования.

Answer 2

С точки зрения CouchDB, функция Map может быть Javascript, но также может быть и Erlang.(или вообще другой язык, если вы подключаете сторонний сервер просмотра)

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

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

Answer 3

Вы должны изучить их немного больше. Это не «хуже», чем в RDMBS, это отличается ... на самом деле, при определенных доменах / функциях парадигма «NoSQL» работает намного быстрее, чем традиционные, а в некоторых случаях устаревшие реализации RDMBS. Подумайте о платформе Google Big Table, и вы получите то, что MongoDB, Riak, CouchDB, Cassandra (Facebook) и многие, многие другие пытаются достичь. Основное отличие состоит в том, что большинство этих решений NoSQL сосредоточены на хранилищах ключей / значений (некоторые называют их «документными» базами данных) и не ограничиваются концепцией отношений (в отношении первичного / внешнего ключа) и объединений. Операции соединения на таблицах могут быть очень дорогими. Кроме того, давайте не будем забывать проблему несоответствия реляционного импеданса объекта ... Вам не нужен ORM для доступа к MongoDB. На самом деле он может хранить ваш код объекта (или документа), как он находится в памяти. Можете ли вы представить экономию в строках кода и сложности !? db4o - еще одно легкое решение, которое делает это.

Я не знаю, что вы имеете в виду, когда говорите "Не только SQL" база данных? Это парадигма NoSQL, в которой SQL не используется для запроса базового хранилища данных системы. NoSQL также означает не СУБД, на которой обычно построен SQL. Хотя MongoDB имеет SQL-подобный синтаксис, который можно использовать из .NET при получении данных - он называется NoRM.

Я скажу, что я действительно работал только с Riak и MongoDB ... Я ни в коем случае не знаком с Cassandra или CouchDB, не имея уровня чтения и понимания набора функций. Я предпочитаю использовать MongoDB над всеми ними. Риак тоже был хорош, но не для того, что мне было нужно. Вам следует скачать несколько таких решений NoSQL, и вы получите концепцию. Посмотрите db4o, MongoDB и Riak, так как я считаю, что они самые простые с большей поддержкой языков на основе .NET. Это будет иметь смысл только для определенных приложений. В общем, база данных NoSQL или Document, или OODBMS ... как бы вы это ни называли, очень привлекательна и набирает обороты.

Я также забыл о вашем вопросе javascript ... MongoDB имеет JavaScript-привязки, которые позволяют использовать его как один метод поиска данных. Riak обрабатывает данные в формате JSON. MongoDB использует BSON, я верю, и я не могу вспомнить, что используют другие. В любом случае, вместо SQL (язык структурированных запросов) смысл «запрашивать» у базы данных информацию, некоторые из которых (MongoDB - единое целое) используют Javascript и / или RESTful синтаксис для запроса данных в системе NoSQL. Я считаю, что CouchDB и Riak могут запрашиваться по HTTP, что делает их очень доступными. Не говоря уже о том, что это чертовски круто.

Проведите свое исследование .... скачайте их, все они бесплатны и OSS.

db4o: http://www.db4o.com/ (версии Java и .NET)

MongoDB: mongodb.org/

Riak: http://www.basho.com/Riak.html

NoRM: http://thechangelog.com/post/436955815/norm-bringing-mongodb-to-net-linq-and-mono

Answer 4

Думаю, CouchDB сохраняет документы в btree в соответствии с "индексом" (просмотр) и просто прогуливается по этому дереву .. поэтому он не ищет ..

см. http://guide.couchdb.org/draft/btree.html