Чи є щось новаторське щодо NoSQL? [зачинено]

Я дуже солідний хлопець з реляційних баз даних і розумію аж до 3-ї нормальної форми, ціную коріння алгебраїчної теорії множин SQL і, ймовірно, можу відновити розбите серце (чи ні).

Я не з'ясував реляційну структуру баз даних ДЛЯ ночей побачень з моєю дружиною, але я думав про проекти реляційних баз даних про ночі побачень з моєю дружиною ..

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

Чи NoSQL - це супер оболонка для структури даних? На мій погляд, дані в кінцевому рахунку повинні мати структуру, яку потрібно отримати, і пошук має бути визначений якоюсь мовою.

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

Існує більше типів баз даних, ніж реляційних, наприклад ієрархічні бази даних . Незважаючи на архаїчність за сьогоднішніми мірками, він дійсно добре поєднувався зі структурами даних своїх даних (наприклад, записи COBOL ). Справа в тому, що дані в базі даних були змодельовані близько до того, як записи були викладені на мовах програмування, які їх використовували.

Швидкий перехід до винаходу реляційних баз даних , де нарешті база даних відокремлена, і при належній нормалізації це чудовий спосіб візуалізації більшості типів даних та зв'язків між даними. Це зрозуміти дуже просто порівняно з іншими типами баз даних. Однак у цьому абсолютно не вдається зберігати дані таким чином, щоб відображати об’єкти та класи в програмі. Отже, винахід об'єктно-реляційного відображення . Іншими словами, дизайн бази даних насправді перешкоджає дизайну програми, яка її використовує, саме тому нам потрібні бібліотеки ORM, такі як Hibernate. Хоча чистий і послідовний, у моїй думці завжди є той сумний сумнів, що щось там не зовсім правильно.

Це породило ще два типи баз даних, об’єктних баз даних та NoSQL .

Обидві намагаються вирішити проблеми, що вводяться реляційними базами даних, не піддаючи нас страхітливим жахам ієрархічних баз даних. Дані все ще зберігаються у сховищах, які смутно нагадують таблиці, але насправді більше схожі на програмування структур даних, ніж реляційні таблиці. Хоча об'єктні бази даних дотримуються в основному чітко визначених правил, я розумію, що NoSQL є досить довільним. Наприклад, таблиця може бути візуалізована як хеш-таблиця або масив. Існує непростий, чітко визначений спосіб їх запиту за допомогою довільного інструменту, аналогічного Oracle SQL Developer або SQL Server Management Studio .

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

Існують мови для запиту NoSQL. Однак не існує універсальної мови, такої як SQL для реляційних баз даних.

Пізнє редагування:

Хоча я досить добре знайомий з базами даних NoSQL, це питання стало поштовхом для мене, щоб придбати якісну книгу з цієї теми та почати її читати з можливою метою стати справжнім експертом з цієї теми. Решта коментарів ґрунтується на NoSQL Distilated: Короткий посібник із світу, що розвивається на основі поліглоту, від Прамода Садалажа та Мартіна Фаулера .

Автори констатують, що реляційні бази даних не добре підходять до кластерів, здатних обслуговувати дані, необхідні для таких сайтів, як Amazon та Google: NoSQL був розроблений, щоб відповідати цій ніші, послаблюючи сумісність і довговічність в ACID, щоб сервер великої кількості запитів, які значною мірою використовують статичні дані (отже, транзакції ACID не так важливі).

Крім того, вони стверджують, що бази даних NoSQL працюють без схеми (стор. 10), яка дозволяє базам даних NoSQL легше змінювати структуру даних. Я не впевнений, що наявність чи відсутність формальної схеми має значення в цьому плані, оскільки бази даних SQL дозволяють також змінювати схеми. Незважаючи на те, два відомих автори висловлюють претензію, тому її варто вивчити.

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

Я думаю, ви б точно хотіли переглянути цей документ Еріка Мейєра та Гевіна Бірмана під назвою "Всупереч поширеній думці, що SQL і NoSQL - це лише дві сторони однієї монети" . Коротше кажучи, він стверджує, що математично кажучи обидва підходи базуються на одній і тій же теорії, але з деякими відмінностями.

На мою думку, декілька цікавих відмінностей полягають у наступному: напрямки міжхрестових залежностей (FK у SQL) є протилежними у SQL та NoSQL, і тип колекцій не обмежується встановленням у NoSQL (а отже, деякі теоретико-множинні операції може більше не застосовуватися у світі NoSQL, але деякі інші все ще діють). Ще один цікавий момент статті - мова єдиного запиту, запропонована для запитів як SQL, так і NoSQL баз даних. Він називається LINQ, і якщо ви думаєте, що, можливо, ви чули це ім'я раніше, ви маєте рацію: це мова запиту Microsoft від C #.

Відповідь Сніговика правильно описує, як SQL і NoSQL відрізняються у структурі даних і як до них звертатися. Однак, ймовірно, ще важливішою відмінністю є їх відповідна проблемна область.

NoSQL не є наступником SQL. Скоріше, різні галузі NoSQL жертвують деякими якостями SQL, щоб бути кращими в інших . Теорема CAP стверджує, що жодна розподілена система баз даних не може задовольнити всі наступні властивості:

• Послідовність
• Доступність
• Толерантність до розділів

Таким чином, деякі варіанти NoSQL натомість відповідають принципу BASE , що послаблює обмеження завжди повної послідовності ACID , що є основою для класичних баз даних SQL. Втрачаючи деякі гарантії послідовності, вони отримують можливість поєднувати високу доступність та толерантність до розділів у широко розповсюджених системах, таких як веб-сайти з великою кількістю даних та запитів користувачів, але мало попиту на ідеальну послідовність. Таким чином, такі бази даних NoSQL лежать в основі Google , Facebook та Amazon . Отже, щоб відповісти на ваше запитання: Так, NoSQL є першочерговим в тому, що він в значній мірі дозволяє такі масові веб-сервіси.

Це лише один приклад, оскільки NoSQL - це різноманітне поле, і його варіанти охоплюють майже всі можливі комбінації параметрів у трикутнику CAP .

Поширені випадки використання NoSQL є новаторськими у збільшенні їх продуктивності порівняно зі звичайними базами даних на основі SQL. У цьому є кілька факторів.

Один - ведення господарства. Більшість NoSQL є відкритим кодом і їх можна встановити на робочій станції або VM за допомогою декількох команд і працювати з розумними за замовчуванням поза коробкою. На мій досвід, навіть Postgres і MySQL не так; конфігурація, як правило, необхідна для роботи навіть на робочій станції для цілей розробки.

Ще одна зручна розробка, так як інші відповіді були детально описані. Можливості індексації JSON Монго або семантика ключа / значення Redis і Riak, можливо, є певними веб-пунктами, щоб виконати роботу, а API - це просто. Деякі NoSQL надають свої власні API RESTful, тоді як для SQL, як правило, їх потрібно писати самостійно.

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

Також, пов’язане з вищезазначеним, для невеликих додатків (наприклад, внутрішніх служб або служб додатків до додатків) команда може мати змогу створити виробничу базу даних NoSQL без залучення своїх команд DBA і без пошкодження продуктивності та цілісності проблеми в результаті. Професійним DBA може це не сподобатися, але розробники, які розглядають DBA як джерело перешкод (правильне чи неправильне), іноді розглядають NoSQL як спосіб обійти необхідність мати справу з ними. Я визнаю це - одного разу я змінив невелику програму з Postgres на SQLite, щоб вирізати змагальну DBA, і я вирішив застосувати на Mongo, а не на Oracle, щоб уникнути процесів затвердження DBA та обмежень доступу. Без жодних несприятливих наслідків в будь-якому випадку.