Чому я повинен використовувати базу даних на основі документа, як CouchDB, а не використовувати реляційну базу даних. Чи є якісь типові програми або домени, де база даних на основі документа більше підходить, ніж реляційна база даних?
Відповіді:
Напевно, не варто :-)
Друга найбільш очевидна відповідь - ви повинні використовувати її, якщо ваші дані не є реляційними. Зазвичай це виявляється в тому, що немає простого способу описати ваші дані як набір стовпців. Хороший приклад - база даних, де ви фактично зберігаєте паперові документи, наприклад, скануючи офісну пошту. Дані - це відсканований PDF, і у вас є деякі метадані, які завжди є (відскановані, відскановані, тип документа) та безліч можливих полів метаданих, які існують колись (номер клієнта, номер постачальника, номер замовлення, зберігайте у файлі до, Повний текст OCRed тощо). Зазвичай ви не знаєте заздалегідь, які поля метаданих ви додасте протягом наступних двох років. Такі речі, як CouchDB, працюють набагато приємніше для такого роду даних, ніж реляційні бази даних.
Мені також подобається, що мені не потрібні бібліотеки клієнтів для CouchDB, крім клієнта HTTP, який сьогодні включений майже в кожну мову програмування.
Напевно, найменш очевидна відповідь: Якщо ви не відчуваєте болю за допомогою RDBMS, залишайтеся з ним. Якщо вам завжди доводиться працювати навколо RDBMS, щоб виконати свою роботу, база даних, орієнтована на документи, може бути вартим ознайомлення.
Для більш детального списку перевірте цю публікацію Річарда Джонса .
CouchDB (з їх веб-сайту )
Сервер бази даних документів, доступний через API RESTful JSON. Як правило, до реляційних баз даних не просто отримують доступ через сервіси REST, але потребують набагато складнішого API SQL. Часто ці API (JDBC, ODBC тощо) досить складні. REST досить простий.
Спеціальний та без схем із рівним адресним простором. Реляційні бази даних мають складну, фіксовану схему. Ви визначаєте таблиці, стовпці, покажчики, послідовності, представлення даних та інші речі. Диван не вимагає такого рівня складного, дорогого, крихкого розширеного планування.
Поширений, із надійною, поступовою реплікацією з двонаправленим виявленням та керуванням конфліктами. Деякі комерційні продукти SQL пропонують це. Через API SQL та фіксованих схем це складно, складно і дорого. Для Couch це здається простим і недорогим.
Запит та вміст індексів, що містить механізм звітування, орієнтований на таблицю, який використовує Javascript як мову запитів. Як і SQL та реляційні бази даних. Тут нічого нового.
Так. Чому CouchDB?
Для тупого зберігання та обслуговування даних інших серверів.
Останні кілька тижнів я грав із додатком, що реалізовує життя, який опитує мої канали (смачні, Flickr, Github, twitter ...) та зберігає їх у couchdb. Краса couchdb полягає в тому, що він дозволяє мені зберігати оригінальні дані в оригінальній структурі без накладних витрат. Я додав поле "class" до кожного документа, зберігаючи вихідний сервер, і написав клас візуалізації javascript для кожного джерела.
Узагальнюючи, щоразу, коли ваш сервер спілкується з іншим сервером, зберігання без схем є найкращим, оскільки у вас немає контролю над схемою. В якості бонусу couchdb використовує вбудовані протоколи серверів та клієнтів - JSON для представлення та HTTP REST для транспорту.
Приходить швидка розробка додатків.
Коли я постійно розвиваю свою схему, мені постійно страждає необхідність підтримувати схему в MySQL / SQLite. Хоча я ще не надто багато робив з CouchDB, мені подобається, як просто розвивати схему під час процесу RAD.
Випадок, коли ви, можливо, не хочете використовувати нереляційну базу даних, це коли у вас багато стосунків багато-багато; Мені ще належить розібратися в тому, як створити хороші функції MapReduce навколо таких відносин, особливо якщо вам потрібно мати метадані у відносинах. Я не впевнений, але я не думаю, що функції CouchDB Map можуть викликати власні запити в базі даних, оскільки це може призвести до нескінченних циклів.
Використовуйте базу даних на основі документа, коли вам не потрібно зберігати дані в таблицях з полями однакового розміру для кожного запису. Натомість у вас є необхідність зберігати кожен запис як документ, який має певні характеристики. Будь-яка кількість полів будь-якої довжини може бути динамічно додана до документа в будь-який час без необхідності спочатку "змінювати таблицю". Поля в документах також можуть містити декілька даних.
Детальніше про smdelfin: гнучкість. Ви можете зберігати дані в будь-якій структурі (неструктурованої та всі), і кожен документ може бути абсолютно іншим. CouchDB спеціально корисний, оскільки за допомогою їх індексів "view" ви можете відфільтрувати конкретні документи та запитувати саме цей вид, коли вам потрібні ці підмножини вашої бази даних.
Моя найбільша переможна точка баз даних документів, які зберігають дані у форматі JSON: це рідний формат JavaScript. Тому веб-додатки JavaScript дуже добре працюють з CouchDB. Нещодавно я створив веб-додаток, що використовує CouchDB, і це швидко реагує на ракету, а також може працювати з постійно змінюваною структурою даних.
Бази даних, що базуються на документах, мають велику перевагу перед реляційними базами даних, оскільки вони не потребують визначення схеми вперед - перш ніж мати можливість вводити будь-які дані.
Також вам слід використовувати базу даних документів, якщо ваші дані не є реляційними і не можуть зберігатися в таблиці, а є набором зображень або, наприклад, газетними статтями.
Ще однією перевагою є легкість використання баз даних на основі документів у веб-розробці. Для більш поглибленого порівняння моделей баз даних NoSQL перевірте це джерело: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf