Які переваги використання без схем бази даних, такої як MongoDB, порівняно з реляційною базою даних?

Я звик використовувати реляційні бази даних, такі як MySQL або PostgreSQL, і в поєднанні з платформами MVC, такими як Symfony, RoR або Django, і я думаю, що це чудово працює.

Але останнім часом я багато чув про MongoDB, яка є нереляційною базою даних, або, процитувавши офіційне визначення ,

масштабована, високопродуктивна база даних, орієнтована на документи, з відкритим кодом, без схем.

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

У яких випадках використання MongoDB (або подібних баз даних) краще, ніж використання "класичних" реляційних баз даних? І які переваги MongoDB проти MySQL взагалі? Або принаймні, чому це так інакше?

Якщо у вас є вказівки на документацію та / або приклади, це також було б дуже корисно.

Ось деякі переваги MongoDB для створення веб-додатків:

1. Модель даних на основі документів. Основна одиниця зберігання аналогічна JSON, словникам Python, хешам Ruby тощо. Це багата структура даних, здатна вміщувати масиви та інші документи. Це означає, що ви часто можете представляти в одній сутності конструкцію, яка потребує декількох таблиць для правильного представлення в реляційній базі даних. Це особливо корисно, якщо ваші дані незмінні.
2. Глибокі можливості запитів. MongoDB підтримує динамічні запити в документах з використанням мови запитів на основі документів, яка майже така ж потужна, як SQL.
3. Немає міграцій схеми. Оскільки MongoDB не містить схем, ваш код визначає вашу схему.
4. Чіткий шлях до горизонтальної масштабованості.

Вам потрібно буде прочитати більше про це та пограти з ним, щоб отримати кращу уяву. Ось онлайн-демонстрація:

http://try.mongodb.org/

Є численні переваги.

Наприклад, ваша схема бази даних буде більш масштабованою, вам не доведеться турбуватися про міграції, код буде приємніше писати ... Наприклад, ось один із коду моєї моделі:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Додавання ключа - це просто додавання рядка коду!

Є також інші переваги, які з’являться в довгостроковій перспективі, наприклад, краща масштабованість та швидкість.

... Але майте на увазі, що нереляційна база даних не краща за реляційну . Якщо у вашій базі даних багато зв’язків та нормалізації, можливо, мало сенсу використовувати щось на зразок MongoDB. Вся справа у пошуку потрібного інструменту для роботи.

Щоб прочитати більше речей, я рекомендую поглянути на " Чому, на мою думку, Монго - це Бази даних, що Rails було для Frameworks " або цей пост на веб-сайті mongodb. Щоб захопитись і якщо ви говорите по-французьки, погляньте на цю статтю, яка пояснює, як налаштувати MongoDB з нуля.

Редагувати: Я ледь не забув розповісти вам про цей рейковий канал Райана . Це дуже цікаво і викликає бажання розпочати одразу!

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

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

Хтось називає це грубим недоліком, хтось - ні.

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

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

MongoDB був представлений на FLOSS Weekly цього тижня - http://twit.tv/floss105 База даних, що використовує подібну концепцію, - CouchDB, яка була представлена ​​на іншому FLOSS Weekly: http://twit.tv/floss36

Я думаю, що варто послухати їх, окрім посилань, наданих @marcgg

Мій досвід роботи з Postgres та Mongo після роботи з обома базами даних у моїх проектах.

Postgres (RDBMS)

Postgres рекомендується використовувати, якщо у ваших майбутніх додатках є складна схема, яка потребує великої кількості об'єднань, або всі дані мають зв'язки, або якщо ми важко пишемо. Postgres є відкритим вихідним кодом, швидшим, сумісним з ACID і використовує менше пам'яті на диску, а також забезпечує високу продуктивність для зберігання JSON, а також включає повну серіалізацію транзакцій з 3 рівнями ізоляції транзакцій.

Найбільша перевага перебування в Postgres полягає в тому, що ми маємо найкраще з обох світів. Ми можемо зберігати дані в JSONB з обмеженнями, послідовністю та швидкістю. З іншого боку, ми можемо використовувати всі функції SQL для інших типів даних. Основний механізм дуже стабільний і добре справляється з великим діапазоном обсягів даних. Він також працює на ваш вибір обладнання та операційної системи. Postgres забезпечує можливості NoSQL, а також повну підтримку транзакцій, зберігаючи документи JSON з обмеженнями на дані полів.

Загальні обмеження для Postgres

Масштабування Postgres по горизонталі значно складніше, але здійсненне.

Швидкого зчитування неможливо досягти повністю за допомогою Postgres.

БЕЗ баз даних SQL

Mongo DB (Wired Tiger)

MongoDB може перемогти Postgres у розмірі "горизонтальної шкали". Зберігання JSON - це те, що оптимізовано для Монго. Mongo зберігає свої дані у бінарному форматі, який називається BSONb, що є (приблизно) лише двійковим поданням надмножини JSON. MongoDB зберігає об'єкти точно так, як вони були розроблені. За даними MongoDB, для програм, що вимагають інтенсивного запису, Монго каже, що новий движок (Wired Tiger) дає користувачам до 10-кратного збільшення продуктивності запису (я повинен спробувати це), із зменшенням обсягу зберігання на 80 відсотків, що сприяє зниженню витрат на зберігання , досягти більшого використання обладнання.

Загальні обмеження MongoDb

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

Окремі технології NoSQL не відповідають стандартам ACID, оскільки вони жертвують критичним захистом даних на користь високої продуктивності для неструктурованих додатків. Застосувати ACID до баз даних NoSQL не складно, але це зробило б базу даних повільною та негнучкою до певної міри. “Більшість обмежень NoSQL були оптимізовані в нових версіях та випусках, які значною мірою подолали попередні обмеження”.

Вся справа в компромісах. MongoDB швидкий, але не КИСЛИЙ, у нього немає транзакцій. Це краще, ніж MySQL, в одних випадках використання і гірше в інших.

Рядки нижче, написані MongoDB: остаточний посібник.

Є кілька вагомих причин:

1. Зберігання різних видів документів в одній колекції може бути кошмаром для розробників та адміністраторів. Розробники повинні переконатися, що кожен запит повертає лише документи певного типу або що код програми, що виконує запит, може обробляти документи різної форми. Якщо ми запитуємо дописи в блозі, це клопітка відсіяти документи, що містять дані про автора.
2. Отримати список колекцій набагато швидше, ніж отримувати список типів у колекції. Наприклад, якби у нас у колекції був ключ типу, який повідомляв, чи є кожен документ «обробленим», «цілим» чи «кремезним мавпою», було б набагато повільніше знайти ці три значення в одній колекції, ніж мати три окремі колекції та запитувати їх імена
3. Групування документів одного виду в одній колекції дозволяє визначити місцезнаходження даних. Отримання кількох дописів у блозі з колекції, що містить лише дописи, швидше за все, вимагатиме менше пошуків диска, ніж отримання тих самих дописів із колекції, що містить дописи та дані про автора.
4. Ми починаємо нав'язувати якусь структуру нашим документам, коли створюємо індекси. (Це особливо актуально у випадку унікальних індексів.) Ці індекси визначаються для кожної колекції. Поміщаючи в одну колекцію лише документи одного типу, ми можемо ефективніше індексувати наші колекції

Після питання про бази даних із текстовим сховищем), я зазирнув до MongoDB та подібних систем.
Якщо я правильно зрозумів, вони повинні бути простішими у використанні та налаштуванні та набагато швидшими. Можливо, також більш безпечний, оскільки відсутність SQL перешкоджає введенню SQL ...
Очевидно, MongoDB використовується переважно для веб-додатків.
По суті, і вони заявляють, що самі по собі ці бази даних не підходять для складних запитів, видобутку даних тощо. Але вони блискучі при швидкому отриманні великої кількості плоских даних.

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