Варианты использования для NoSQL [закрыто]


144

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


6
Cassandra и MongoDB - это совершенно разные продукты - совершенно разные категории . На этот вопрос было бы легче ответить, если бы он спрашивал о вариантах использования для определенного типа базы данных (OODB, DODB, DKVS и т. Д.). «NoSQL» - это просто общий термин для «всего, что не является SQL» - это точно так же, как что-то вроде BerkleyDB или куча плоских файлов, находящихся на сетевом ресурсе.
Ааронаут

@ Я понимаю, что я ценю различия, я думаю, что я, возможно, виновен в использовании термина с nosql
robjmills

Ответы:


86

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

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

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

Как основатель Joomla, я предвзято :-), но, исходя из пространства CMS, что-то вроде MongoDB - это серебряная пуля, поскольку контент очень естественно отображается в системах документов.

Другим хорошим примером для MongoDB является аналитика в реальном времени, поскольку MongoDB обладает очень высокой производительностью и масштабностью, особенно в отношении параллелизма. На веб-сайте MongoDB.org есть примеры, демонстрирующие эти атрибуты.

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


1
действительно хорошо сказал spacemonkey, я нахожусь в том же положении, что и seegee, ясно, что мы должны думать по-новому и должны спросить себя, как мне структурировать данные моих приложений в структуру документа, избавляя себя от мышления RDBMS, когда мы делаем этот анализ
on_

49

Некоторые отличные варианты использования - в любом случае для MongoDB - упоминаются на сайте MongoDB. Приведенные примеры - аналитика в реальном времени, ведение журнала и полнотекстовый поиск. Эти статьи все стоит прочитать http://www.mongodb.com/use-cases

Также есть отличная статья о том, какая база данных NoSQL лучше всего подходит для какого типа проекта: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis



8

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


1
Я бы точно не сказал, что это тривиально , но в остальном это хороший момент для документно-ориентированных баз данных. На самом деле обратное верно для некоторых других продуктов NoSQL - DKVS, как правило, труднее отобразить, чем SQL / реляционные БД.
Ааронаут

8

Я уже некоторое время использую NoSQL DB, и это мой вклад в тему:

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

В такой ситуации база данных NoSQL может быть отличным выбором

Давайте рассмотрим, например, MongoDB :

Если у вас есть данные в JSON (они могут быть получены из стороннего API или экспортированы из sql-приложения) в MongoDB , довольно просто импортировать и обновлять данные JSON в базе данных; например, используя mongoimportутилиту командной строки

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

Например, используя Aggregation Framework :

$pipeline = [];

//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ]  ]  ];

//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
    $pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];    

//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];

return $collection->aggretate( $pipeline );

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

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

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

  • Отсутствие транзакций: приложение не выполняет запись, а только чтение, поэтому нам вообще не нужны транзакции

  • Отсутствие объединений между таблицами. Нам не нужны объединения, поскольку мы можем использовать избыточность для хранения наших денормализованных данных в коллекциях. Поскольку мы только читаем данные, нам не нужно беспокоиться о синхронизации денормализованных данных между обновлениями.

Таким образом, мы можем сосредоточиться на хранении данных с избыточностью таким образом, чтобы они хорошо подходили к нашим запросам и были сосредоточены на отдельных коллекциях.

Я просто пишу это, потому что, если бы я читал что-то подобное несколько раз назад, это сэкономило бы мне время на исследования.

Надеюсь это кому-нибудь пригодится


3

Я настоятельно рекомендую этот разговор Мартина Фаулера:

https://www.youtube.com/watch?v=qI_g07C_Q5I

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

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


Понял, буду иметь ввиду на будущее.
user3631881

3

Сначала вы должны понять теорию CAP (непротиворечивость, доступность и разбиение, где вы должны выбрать два из трех) и наш бизнес-пример использования. MongoDB удовлетворяет требованиям согласованности и разметки, а база данных Couch удовлетворяет доступности и разметке.

Видео Edureka в YouTube на тему NoSQL - одни из лучших видеоуроков.

https://www.youtube.com/watch?v=gJFG04Sy6NY

https://www.youtube.com/watch?v=KSq6tMMXZ8s

https://www.youtube.com/watch?v=3z1KFA2qcSo

Хорошие презентации доступны на slideshare.net

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when?qid=3bb9f7f6-a53d-41b1-8403-cd6f181d0ca7&v=qf1&b=&from_search=1

http://www.slideshare.net/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (эта презентация поддерживает видеоруководство в YouTube)


1

Для некоторых случаев использования, которые вам нужны, особенно для аналитических запросов, вы можете запускать SQL-запросы на MongoDB с помощью этой оболочки от Postgres.


1

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

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

Я хотел бы предложить Couchbase всем, кто еще не пробовал его, но не на основе версии, показанной в отчете (2.5.1), потому что он почти на 2 ревизии отстает от того, где находится CB Server сегодня, приближается к выпуску 4.0 во 2П15 ,

http://www.couchbase.com/coming-in-couchbase-server-4-0

Другая часть, касающаяся Couchbase как поставщика / продукта, заключается в том, что это многофункциональный тип БД. Он может выступать в роли чистого K / V-хранилища, Document Oriented Database с многомерным масштабированием, Memcached, кэширования с сохранением, а также поддерживает ANSI 92-совместимый SQL с автоматическими объединениями, репликацией в кластеры DR одним нажатием кнопки и даже имеет мобильный компонент, встроенный в экосистему.

Если ничего другого, стоит проверить последние тесты:

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.