2
Насправді FoundationDB був сумісний із кислотою. Тепер Apple схопила його
—
Користувач без капелюха
Відповіді:
Я опублікую це як відповідь суто для підтримки розмови - Тім Махі , nawroth та CraigTP запропонували життєздатні бази даних. CouchDB був би моїм перевагою завдяки використанню Erlang , але там є й інші.
Я б сказав, що ACID не суперечить і не заперечує концепцію NoSQL ... Хоча, здається, існує тенденція, що слідує за думкою, висловленою голубом , я б стверджував, що поняття є різними.
NoSQL принципово стосується простої ключа-значення (наприклад, Redis) або схеми в стилі документа (зібрані пари ключів-значень у моделі «документ», наприклад, MongoDB) як прямої альтернативи явній схемі в класичних RDBMS. Це дозволяє розробнику ставитися до речей асиметрично, тоді як традиційні двигуни застосовують жорстку однаковість у моделі даних. Причина, чому це так цікаво, полягає в тому, що він пропонує інший спосіб боротьби зі змінами , а для великих наборів даних він пропонує цікаві можливості для вирішення обсягів та продуктивності.
ACID забезпечує принципи, що регулюють, як зміни застосовуються до бази даних. Дуже спрощеним чином, він заявляє (моя власна версія):
Розмова стає трохи більш збудливою, коли мова йде про ідею поширення та обмеження . Деякі двигуни RDBMS надають можливість застосовувати обмеження (наприклад, зовнішні ключі), які можуть мати елементи розповсюдження (a la kascade ). Простіше кажучи, одна "річ" може мати зв'язок з іншою "річчю" в базі даних, і якщо ви зміните атрибут одного, він може зажадати змінити інший (оновити, видалити, ... безліч варіантів). Бази даних NoSQL , будучи переважно (на даний момент) зосередженими на великих обсягах даних та великому трафіку, схоже, вирішують ідею розподілених оновлень, які відбуваються у (з погляду споживача) довільних часових рамках. Це в основному спеціалізована форма реплікації, керована черезтранзакції - тому я б сказав, що якщо традиційна розподілена база даних може підтримувати ACID, то це може бути і база даних NoSQL.
Деякі ресурси для подальшого читання:
ОНОВЛЕННЯ (27 липня 2012 р.): Посилання на статтю у Вікіпедії було оновлено, щоб відображати версію статті, яка була актуальною після опублікування цієї відповіді. Зауважте, що поточна стаття у Вікіпедії була детально переглянута!
Ну, відповідно до старішої версії статті у Вікіпедії про NoSQL :
NoSQL - це рух, що сприяє слабко визначеному класу нереляційних сховищ даних, які розриваються з довгою історією реляційних баз даних та гарантіями ACID.
і також:
Ця назва була спробою описати появу все більшої кількості нереляційних, розповсюджених сховищ даних, які часто не намагалися надати гарантії ACID.
і
Системи NoSQL часто надають слабкі гарантії узгодженості, такі як можлива узгодженість та транзакції, обмежені одними елементами даних, навіть якщо можна накладати повні гарантії ACID, додаючи додатковий проміжний рівень.
Так, в двох словах, я б сказав , що один з головних переваг «NoSQL» сховище даних є явним відсутністю в ACID властивостей. Крім того, IMHO, чим більше намагається реалізувати та застосовувати властивості ACID , тим далі від "духу" сховища даних "NoSQL" ви отримуєте, і чим ближче до "справжнього" RDBMS ви отримаєте (відносно кажучи, звичайно ).
Однак, все, що сказано, "NoSQL" - це дуже розпливчастий термін і є відкритим для індивідуальних інтерпретацій, і сильно залежить від того, наскільки ви маєте пуристську точку зору. Наприклад, найсучасніший RDBMS системи практично не дотримуються всі з Кодд «s 12 правил його реляційної моделі !
Приймаючи прагматичний підхід, може здатися, що CouchDB Apache наближається до втілення як відповідності ACID, зберігаючи при цьому слабко пов'язаний, нереляційний "NoSQL" менталітет.
Будь ласка, переконайтеся, що ви прочитали вступ Мартіна Фаулера про бази даних NoSQL . І відповідне відео.
Перш за все, ми можемо виділити два типи баз даних NoSQL:
За дизайном більшість баз даних, орієнтованих на графік, - це кислотні !
Тоді, що з іншими типами?
У базі даних, орієнтованих на агрегат, ми можемо розмістити три підтипи:
Ми називаємо тут агрегатом - це те, що Ерік Еванс визначив у своїй Дизайні, керованій доменом, як самодостатню сутність та ціннісні об'єкти в заданому обмеженому контексті.
Як наслідок, сукупність - це сукупність даних, з якими ми взаємодіємо як одиниця. Агрегати утворюють межі для операцій ACID з базою даних. (Мартін Фаулер)
Отже, на рівні Aggregate можна сказати, що більшість баз даних NoSQL можуть бути настільки ж безпечними, як і ACID RDBMS , з відповідними налаштуваннями. З першоджерела, якщо ви налаштуєте ваш сервер на найкращу швидкість, ви можете потрапити на щось некислоту. Але реплікація допоможе.
Моє головне - ви повинні використовувати бази даних NoSQL такими, якими вони є, а не як (дешеву) альтернативу RDBMS. Я бачив занадто багато проектів, що зловживають відносинами між документами. Це не може бути кислотна. Якщо ви залишаєтесь на рівні документа, тобто на загальних кордонах, вам не потрібна жодна транзакція. І ваші дані будуть настільки ж безпечними, як і з базою даних ACID, навіть якщо це не справді ACID, оскільки ці транзакції вам не потрібні! Якщо вам потрібні транзакції та оновлення декількох "документів" одночасно, ви більше не перебуваєте у світі NoSQL - тому замість цього використовуйте двигун RDBMS!
деякі оновлення 2019 року: Починаючи з версії 4.0, для ситуацій, які потребують атомарності для оновлення декількох документів або узгодженості між читаннями для декількох документів, MongoDB забезпечує транзакції з кількома документами для наборів реплік .
FoundationDB сумісний з кислотними кислотами:
Він має належні транзакції, тому ви можете оновлювати кілька різних елементів даних ACID. Це використовується як основа для підтримки показників на більш високому шарі.
У цьому питанні хтось повинен згадати OrientDB : OrientDB - це база даних NoSQL, одна з небагатьох, яка повністю підтримує транзакції ACID. Кислота не тільки для RDBMS, оскільки вона не входить до реляційної алгебри. Тому можливо мати базу даних NoSQL, яка підтримує ACID.
Ця особливість є тією, яку я найбільше сумую в MongoDB
ACID і NoSQL є повністю ортогональними. Одне не означає іншого.
У мене на столі блокнот, я використовую його для ведення записів про речі, які мені ще належить робити. Цей ноутбук - це база даних NoSQL. Я запитую його за допомогою лінійного пошуку з "кешем сторінки", тому мені не завжди потрібно шукати кожну сторінку. Він також сумісний з кислотними кислотами, оскільки я гарантую, що я пишу лише по одній справі за один раз і ніколи, поки я її читаю.
NoSQL просто означає, що це не SQL. Багато людей плутаються і думають, що це означає масштабне масштабування-дикий захід-супер-швидке зберігання. Це не так. Це не означає зберігання ключових значень або можливу послідовність. Все це означає, що це "не SQL", на цій планеті багато баз даних, і більшість з них не є SQL [потрібне цитування] .
Ви можете знайти багато прикладів в інших відповідях, тому мені не потрібно їх перераховувати тут, але є бази даних, що не належать до SQL, з відповідності ACID для різних операцій, деякі - лише ACID для запису одного об’єкта, а деякі гарантують набагато більше. Кожна база даних різна.
"NoSQL" не є чітко визначеним терміном. Це дуже розпливчаста концепція. Як таке, навіть неможливо сказати, що є, а що не є продуктом "NoSQL". Не майже всі товари, що мають типову марку з етикеткою, - це магазини, що мають ключову цінність.
Дід NoSQL: ZODB сумісний з кислотними кислотами. http://www.zodb.org/
Однак це лише Python.
Як один із розробників NoSQL (я був першим учасником Apache CouchDB, і спікер на першій події NoSQL, що відбулася в CBS Interactive / CNET в 2009 році) я з задоволенням бачу, що нові алгоритми створюють можливості, які раніше не існували . Протокол Calvin пропонує новий спосіб думати про фізичні обмеження, такі як CAP і PACELC .
Замість активної / пасивної реплікації асинхронізації або активної / активної синхронної реплікації Calvin зберігає правильність та доступність під час відключення реплік, використовуючи протокол, подібний RAFT, для підтримки журналу транзакцій. Крім того, транзакції обробляються детерміновано у кожній репліку, знімаючи потенціал для тупикових ситуацій, тому згода досягається лише одним раундом консенсусу. Це робить його швидким навіть у багатьох хмарах у всьому світі.
FaunaDB - єдина реалізація бази даних, що використовує протокол Calvin, що робить його унікальним для робочих навантажень, які потребують цілісності даних, схожих на мейнфрейм, із шкалою та гнучкістю NoSQL.
Якщо ви шукаєте сховище ключів / цінностей, сумісне з ACID, є Berkeley DB . Серед баз даних графіків принаймні Neo4j та HyperGraphDB пропонують транзакції ACID (HyperGraphDB фактично використовує БД Берклі для зберігання на низькому рівні).
Цю концепцію учасники Вікіпедії визначають як:
[…] Клас сучасних систем управління реляційними базами даних, які прагнуть забезпечити однакову масштабовану продуктивність систем NoSQL для обробки робочих навантажень в режимі он-лайн (OLTP), зберігаючи гарантії ACID традиційної системи баз даних.
[1][2][3]
[1]Ненсі Лінч та Сет Гілберт, «Вигадування пивоварів та можливість послідовних, доступних, толерантних до розділів веб-служб» , ACM SIGACT News, том 33, випуск 2 (2002), стор. 51-59.
[2] "Теорема CAP Brewer" , julianbrowne.com, отримано 02 березня 2010 року
[3] "Теорема CAP пивоварів про розподілені системи" , royans.net
MongoDB оголосив, що його версія 4.0 буде сумісною з ACID для транзакцій із кількома документами.
Версія 4.2. передбачається підтримувати його в налаштованих умовах.
https://www.mongodb.com/blog/post/multi-document-transaction-in-mongodb
Згадувалося про FoundationDB, і на той час воно не було відкритим кодом. Він був відкритий джерелом Apple два дні тому: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Я вважаю, що це сумісно з кислотою.
Щоб додати до списку альтернативних варіантів, GTM має ще одну повністю сумісну з ACID базу даних .
Hyperdex Warp http://hyperdex.org/warp/ Warp (функція ACID) є власником, але Hyperdex безкоштовний.
db4o
На відміну від стійкості або серіалізації в рулоні, db4o є безпечним для транзакцій ACID і дозволяє здійснювати запити, реплікацію та зміни схем під час виконання
Tarantool - це повністю база даних ACID NoSQL. Ви можете видавати CRUD-операції або збережені процедури, і все буде працювати у суворій відповідності з властивістю ACID. Ви також можете прочитати про це тут: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic також є компліментом ACID. Я думаю, що це один з найбільших гравців зараз.
BergDB - це невелика база даних NoSQL з відкритим кодом, що відкрита, розробляється з самого початку для здійснення транзакцій ACID. Власне, BergDB є "більш" ACID, ніж більшість баз даних SQL, в тому сенсі, що єдиний спосіб змінити стан бази даних - це запуск транзакцій ACID з найвищим рівнем ізоляції (термін SQL: "серіалізаційний"). З брудними читаннями, не повторюваними чи фантомними читаннями не виникне жодних проблем.
На мою думку, база даних все ще є високоефективною; але не вірте мені, я створив програмне забезпечення. Спробуйте самостійно.
Багато сучасних рішень NoSQL не підтримують транзакції ACID (атомно-ізольовані багатоклавішні оновлення), але більшість з них підтримують примітиви, які дозволяють здійснювати транзакції на рівні програми.
Якщо сховище даних підтримує ключову лінійність та порівняння та встановлення (атомність рівня документа), тоді достатньо здійснити транзакції на стороні клієнта. Більше того, у вас є кілька варіантів:
Якщо вам потрібен рівень ізоляції серіалізуемого, ви можете дотримуватися того самого алгоритму, який використовує Google для системи Percolator або Lab Cocroach Lab для CockroachDB . Я про це робив блог і створював поетапну візуалізацію , сподіваюся, це допоможе вам зрозуміти головну ідею алгоритму.
Якщо ви очікуєте високої суперечки, але добре, що ви маєте рівень читання ізоляції, який прочитував, тоді перегляньте транзакції RAMP Пітера Бейліса.
Третій підхід полягає у використанні компенсаційних транзакцій, також відомих як схема саги. Це було описано наприкінці 80-х у статті Sagas, але стало більш актуальним із збільшенням розподілених систем. Будь ласка, дивіться розмову про застосування картини саги для натхнення.
У список сховищ даних, що підходять для клієнтських транзакцій, входять Кассандра з легкими транзакціями, Riak зі стійкими відрами, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB та інші.
YugaByte DB підтримує розподілені txns , сумісні з ACID , а також сумісність Redis та CQL API на рівні запитів.
VoltDB - абітурієнт, який претендує на відповідність ACID, і хоча він все ще використовує SQL, його цілі однакові з точки зору масштабованості.
Вузол LevelUP є транзакційним і побудований на leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB - це база даних NoSQL і має трансакції ACID .
Не тільки NoSQL не відповідає ACID за дизайном. Рух NoSQL охоплює БАЗУ (в основному, м'який стан, подія консистенції), яка стверджується, що протилежна ACID. Базу даних NoSQL часто називають базою даних, яка складається з часом. Щоб зрозуміти відмінності, вам слід детальніше ознайомитися з теоремою CAP (також теоремою Брювера)
Відвідайте http://www.julianbrowne.com/article/viewer/brewers-cap-theorem