Портирование структур SQL на NoSQL MongoDB или CouchDB

Question

Я пытаюсь выяснить, как вы проектируете хранилище данных в системе хранения документов, такой как CouchDB или MongoDB .

Я больше не использую JOIN в своих запросах, а просто продолжаю искать строки с определенными индексами, которые соответствуют моему критерию.Например, я могу искать последние комментарии (ORDER BY date) или всех активных пользователей (WHERE status = 1).Другими словами, моя логика поиска основана на индексированных столбцах типа int, хранящихся в ОЗУ .

При переходе на NoSQL, похоже, никаких индексов нет, поэтому я пытаюсьчтобы выяснить результаты фильтрации этих баз данных, не просматривая каждую строку вручную. Обновление : почему-то я упустил это: http://vivu.tv/portal/archive.jsp?flow=783-586-4282&id=1270584002677

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

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

Обновление: Я просто не тратил достаточно времени на просмотр сайта MongoDB. Документация , кажется, охватывает большинство вещей, таких как использование индексов для фильтрации результатов, как в sql.Также http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart и http://rickosborne.org/download/SQL-to-MongoDB.pdf были как раз то, что мне нужно.

Answer 1

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

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

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

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