Использование базы данных NoSQL для реляционных целей - PullRequest
Новая
       18

Использование базы данных NoSQL для реляционных целей

0 голосов
/ 14 октября 2011

Нереляционные базы данных привлекают все больше внимания с каждым днем. Основным ограничением является то, что сегодняшние сложные данные действительно связаны. Разве не удобно соединять базы данных, когда мы соединяем таблицы в RDBMS? Конечно, я имею в виду простые случаи. Представьте себе три таблицы статей, тегов, отношений. В такой СУБД, как Mysql, мы можем запустить три запроса к 

1. Find ID of a given tag
2. Find Articles connected with the captured Tag ID
3. Fetch the contents of Articles tagged with the term

Вместо трех запросов мы выполняем один запрос с помощью JOIN. Я думаю, что три запроса в базе данных ключ / значение, такой как BerkeleyDB, быстрее, чем запрос JOIN в Mysql.

Является ли эта идея практичной? Или другие вопросы связаны с игнорированием этого подхода?

Ответы [ 3 ]

2 голосов
/ 14 октября 2011

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

В некоторых приложениях эти дополнительные усилия будут оправданы. Возможно, у вас есть только небольшое количество таблиц, и объединения, которые вам нужны, очень просты. Или, возможно, вы провели некоторую оценку производительности между традиционной реляционной СУБД и альтернативой NoSQL и обнаружили, что опция NoSQL больше подходит для ваших потребностей по ряду причин (производительность, масштабируемость, гибкость и т. Д.).

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

Следовательно, в тот момент, когда вы начинаете создавать свои собственные реляционные отображения и объединения поверх БД NoSQL , вы должны спросить себя: "Не кто-то уже создал это для меня?" Ответ вполне может быть «да», и решение может заключаться в использовании традиционной СУБД SQL.

Чтобы ответить на часть «3 запроса» вашего вопроса конкретно, ответ «возможно». Конечно, вы могли бы сделать такой запрос более быстрым в NoSQL DB, чем в RDBMS, но вам нужно помнить, что здесь нужно учитывать больше вещей, чем просто скорость вашего запроса:

  1. Технический долг, который вы будете нести при создании функциональности, подобной объединению, которую вам не пришлось бы создавать в противном случае
  2. Время, которое потребуется вам для создания, тестирования и оптимизации кода запроса, что, вероятно, будет более важным, чем написание простого запроса SQL
  3. Любая разница в транзакционных гарантиях или других типичных функциях продукта (репликация, инструменты управления и т. Д.), Которые вы можете потерять или получить в зависимости от выбранной вами опции NoSQL
  4. Возможность нанимать СУБД, которые знают, как управлять вашей базой данных с оперативной точки зрения

Вы можете просмотреть этот список и сказать себе: «Ничего страшного, я запускаю простое приложение, содержащее всего несколько тысяч записей в БД, и я буду поддерживать его самостоятельно» . Если это так, нокаутируйте себя - Беркли (и другие опции NoSQL) будут работать нормально. Я много раз использовал Беркли для таких приложений. Но у вас может быть другой ответ, если вы создаете серверную часть для продукта SaaS значительного размера, который вскоре может иметь миллионы пользователей и очень сложные запросы.

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

1 голос
/ 14 октября 2011

Конечно, соединение с одной записью довольно быстро в любом решении, но это не большое преимущество объединений. Объединения полезны, когда вы объединяете множество строк с множеством других строк. Представьте, что в вашем примере вы хотите сделать это для 100 различных тегов. Без объединений вы говорите 300 запросов на один SQL.

0 голосов
/ 21 августа 2012

Другое решение для систем noSql - playOrm.Он объединяет НО только в разделах, поэтому таблица может иметь бесконечный размер, но разделы должны соответствовать размеру таблиц РСУБД.Он также делает все модные вещи в спящем режиме для вас со всеми связанными аннотациями, хотя имеет некоторые отличия и будет добавлять Embedded для использования при денормализации.Это делает вещи намного проще.Обычно работа с nosql - это боль во всей логике перевода, которую вы должны выполнять, а также все ручное индексирование, обновление и удаление из индекса .... playOrm делает все это вместо вас.

...