Використовуйте випадки для NoSQL [закрито]

Останнім часом NoSQL приділяє багато уваги нашій галузі. Мені дійсно цікаво, які думки народів стосуються найкращих випадків його використання над реляційним сховищем бази даних. Що має спонукати розробника думати, що конкретні набори даних більше підходять до рішення NoSQL. Мене особливо цікавлять MongoDB та CouchDB, оскільки вони, мабуть, отримують найбільше висвітлення щодо розвитку PHP, і на цьому я зосереджуюсь увагу.

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

Такий підхід аналогічний тому, щоб взяти машину і намагатися використовувати її, щоб тягнути свій візок по дорозі, як кінь.

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

Як засновник Joomla я упереджений :-), але приходжуючи з простору CMS, щось на зразок MongoDB - це срібна куля, оскільки вміст дуже природно відображає документи.

Інший чудовий випадок для MongoDB - це аналітика в режимі реального часу, оскільки MongoDB має дуже високу ефективність та масштабність, особливо щодо одночасності. На веб-сайті MongoDB.org є приклади, які демонструють ці ознаки.

Я погоджуюся з думкою про те, що кожна база даних має власні цілі та випадки використання; відповідно прийняти призначення кожної бази даних для оцінки.

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

Існує також чудове написання того, яка база даних NoSQL найкраще підходить до типу проекту: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

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

Те, що мені подобається в NoSQL, не має нічого спільного з продуктивністю і всім пов'язаним із зручністю використання. З магазинами документів просто легше працювати, коли ваші атомні одиниці даних схожі на документи, тому що серіалізувати до об'єктів і з них тривіально. Це просто веселіше, і це важливий фактор для особистих чи побічних проектів.

Я вже деякий час використовую БД NoSQL, і це мій внесок у тему:

Чудовим випадком використання бази даних NoSQL є додаток для створення статистики та / або звітів , особливо, коли дані надаються від сторонніх джерел.

У такій ситуації, як база даних NoSQL може стати чудовим вибором

Розглянемо, наприклад, MongoDB :

Коли ви отримаєте свої дані в JSON (він може надходити від стороннього API або бути експортований з sql-додатку) в MongoDB досить важко імпортувати та оновлювати дані 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:

• Відсутність транзакцій. Програма не виконує записи, а лише читає, тому транзакції нам взагалі не потрібні

• Відсутність з'єднань між таблицями: нам не потрібні об'єднання, оскільки ми можемо використовувати надмірність для зберігання наших денормалізованих даних у колекціях. Оскільки ми читаємо лише дані, нам не потрібно турбуватися про синхронізацію денормалізованих даних серед оновлень.

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

Я просто пишу це, бо якби я читав щось подібне кілька разів тому, це врятувало б мені деякий час для проведення досліджень

Сподіваюсь, комусь це буде корисно

Я настійно рекомендую цю розмову Мартіна Фаулера:

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

РЕЗЮМЕ: Мартін дає швидке ознайомлення з базами даних NoSQL: звідки вони походять, характер моделей даних, які вони використовують, та інший спосіб, яким ви повинні думати про послідовність. Виходячи з цього, він окреслює, які обставини вам слід розглянути, використовуючи їх, чому вони не зроблять реляційні бази даних застарілими та важливий наслідок стійкості поліглоту.

Він малює приємну картину того, що таке NoSQL, різних категорій та речей, які кожен повинен зрозуміти, приходячи із світу реляційних баз даних. З повагою

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

Відео Edureka у ютубі щодо NoSQL - одні з найкращих навчальних уроків.

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

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

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

Хороші презентації доступні на слайдсхар.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 (Ця презентація підтримує відеоурок у ютубі)

У деяких потрібних випадках використання, особливо для аналітичних запитів, ви можете запускати SQL запити на MongoDB за допомогою цього обгортка з Postgres.

Оскільки на ринку зараз існує набагато більше баз даних 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, Документоорієнтована база даних з багатовимірним масштабуванням, Memcached, кеш-пам'ять з наполегливістю і підтримує сумісний з ANSI 92 SQL з автоматичним приєднанням, реплікація в кластери DR натисканням кнопки та навіть має мобільний компонент, вбудований в екосистему.

Якщо нічого іншого, варто перевірити останні показники:

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