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

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

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

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

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

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

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

Я бы предложил эту статью Рика Каттелла о разных хранилищах данных (например, NoSQL), их отличиях и некоторых их случаях использования: http://www.cattell.net/datastores/index.html

хорошая запись при использовании NoSQL в TekPub

http://blog.wekeroad.com/2010/05/19/no-sql-in-the-wild

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

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

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

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

Рассмотрим, например, MongoDB:

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

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

Например, используя Агрегирующая структура:

$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:

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

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

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

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

Надеюсь, что это будет полезно кому-то.

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

Видео 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)

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

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

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

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

Поскольку на рынке появилось много новых баз данных 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 в 2H15.

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

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