Есть ли надежная (односерверная) альтернатива MongoDB?

Мне нравится идея баз данных документов, особенно MongoDB. Это позволяет ускорить разработку, поскольку нам не нужно настраивать схему базы данных. Однако MongoDB не поддерживает транзакции с несколькими документами и не гарантирует, что изменения будут записаны на диск сразу же, как и обычные базы данных (я знаю, что вы можете сделать время между флешами довольно маленьким, но оно по-прежнему не является гарантией).

Большинство наших проектов не настолько велики, что им нужны такие вещи, как многосерверные среды. Поэтому помня об этом. Есть ли один сервер MongoDB-подобных баз данных документов, поддерживающих многодокументные транзакции и надежную покраску на диск?

ОТВЕТЫ

Ответ 1

Очень короткий ответ на ваши конкретные (но короткие) требования:

Существуют ли какие-либо единственные серверные базы данных в формате MongoDB, которые поддерживают транзакции с несколькими документами и надежную очистку на диске?

  • RavenDB [1] поддерживает многоточечные транзакции [2]. К сожалению, я не знаю, что он справляется с долговечностью.

  • CouchDB [3] обеспечивает долговременную запись, но никаких транзакций с несколькими документами

  • RethinkDB [4] обеспечивает долговременную запись, но не транзакции с несколькими документами.

Итак, вы можете задаться вопросом, что отличает эти 3 решения? В большинстве случаев их поддержка запросов (я бы сказал, что RethinkDB имеет самый продвинутый вариант, охватывающий почти все типы запросов: подзапросы, JOINs, агрегации и т.д.), Их история (читай: готовность к производству - здесь я вероятно, говорят, что CouchDB лидирует), их модель распределения (вы упомянули, что вам неинтересно), их лицензирование (RavenDB: коммерческая, CouchDB: Apache License, Rethinkdb: AGPL).

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

Ответ 2

Возможно, стоит посмотреть ArangoDB. Это многомодельная база данных с гибкой моделью данных для документов, графиков и ключевых значений. Что касается ваших конкретных требований, база данных ArangoDB имеет полные ACID-транзакции, которые могут охватывать несколько документов в одной коллекции, а также в нескольких коллекциях (см. Транзакции в ArangoDB). То есть вы можете выполнить группу манипуляций с вашими документами вместе в транзакции и иметь гарантированную атомарность и изоляцию. Если вы дополнительно установили waitForSync: true (как описано ниже на указанной странице), вы получаете гарантированную синхронизацию с диском перед завершением отчетов о транзакциях. Обратите внимание, что это происходит автоматически, если ваша транзакция охватывает несколько коллекций.

Ответ 3

У меня есть некоторый опыт работы с CouchDB и ArangoDB, которыми я могу поделиться:

Вы можете запустить CouchDB с включенной долговечностью (delayed_commits = false), чтобы он также синхронизировал ваши данные с диском. Однако это глобальная настройка, поэтому она влияет на все записи. AFAIK вы не можете установить его на уровне каждой коллекции (термин CouchDB для "коллекции" будет "базой данных" ).

Что касается операций с несколькими документами: CouchDB имеет MVCC, поэтому чтение нескольких документов из одной базы данных обеспечивает согласованный результат даже перед лицом параллельных авторов. Запись нескольких документов в одну и ту же базу данных также может быть выполнена транзакцией для особых случаев, например. при использовании API объемных документов. Но в CouchDB нет возможности выполнять операции с несколькими базами данных. Это просто не предназначено.

В ArangoDB: в ArangoDB вы можете включить непосредственную синхронизацию с диском на уровне каждой коллекции: вы можете включить его для коллекций, в которые вы не можете переносить потерю данных. Вы можете немедленно отключить синхронизацию для не- важные коллекции по соображениям производительности. Затем он будет часто синхронизировать изменения с диском, но не сразу. Он предоставляет транзакции с несколькими документами и несколькими коллекциями.

Ответ 5

Я бы предложил вам посмотреть на Couchbase.

Couchbase может запускаться на одном сервере, и вы можете добавлять узлы позже, если хотите.

Couchbase интегрирован с memcached, поэтому вы быстро используете кеширование общих данных, с надежным методом записи обновлений на диск.

У них также есть новый язык запросов (в разработке, но вы можете его использовать сейчас) под названием NQL ( "Nickel" ), который дает вам SQL-доступ, если это важно для вас.

При использовании репликации с несколькими ретрансляторами вы можете синхронизировать две базы данных на разных компьютерах или центрах обработки данных, что хорошо для резервного копирования на удаленном сервере. Это также позволяет вам добавлять эластичный поиск, если вы хотите иметь полнотекстовую поисковую систему для этих типов запросов.

Короче говоря, Couchbase - довольно полное решение, все с открытым исходным кодом и имеет интеллектуальную (на мой взгляд) архитектуру для решения типичных проблем с распределенными базами данных (например: каждый документ "принадлежит" данным node, поэтому все изменения идут на этот node, а затем обновления реплицируются, это лучше, я думаю, чем сказать Riak, где вы можете иметь обновления, переходите к двум узлам, а затем должны быть согласованы.)

Вы можете использовать Couchbase на одном node, чтобы запустить базу данных для многих проектов, разделив проекты на разные ведра.

Ответ 6

существует так много баз данных nosql, и определенно трудно выбрать один. Вам придется придумать надлежащие требования и точно знать, что вы хотите. Следующая ссылка сравнивала почти все популярные базы данных nosql http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Надеюсь, это поможет.

Ответ 7

Berkeley DB - это тот, который мы использовали. Он поддерживает ACID. У него действительно есть транзакции, но что касается вашего термина "многодокумент", я не совсем уверен. Я предполагаю, что до тех пор, пока каждая база данных (то есть отдельный документ) разделяет одну и ту же среду BDB (т.е. Где хранятся транзакции), возможно, она получает то, что вы хотите. Однако у BDB есть и другие компромиссы. С полной долговечностью и высоким concurrency, фиксации довольно медленные.

Ответ 8

Попробуйте: http://www.orientdb.org/

"OrientDB обладает гибкостью баз данных Document и мощью баз данных Graph для управления отношениями. Он может работать в режиме без схемы, полной схемы или комбинации обоих. Поддерживает расширенные функции, такие как ACID Transactions, Fast Индексы, Родные и SQL-запросы. Он импортирует и экспортирует документы в JSON. OrientDB использует новый алгоритм индексирования MVRB-Tree, полученный из дерева Red-Black Tree и из дерева B + с преимуществами: быстрой вставки и сверхбыстрого поиска".

Ответ 9

Вам не нужно настраивать схемы в хранилищах данных документов, но это не значит, что вам не нужна какая-то схема, поскольку вы, вероятно, хотите сделать что-то значимое для своих данных. Кажется, вам нужна база данных ACID. Если у вас есть реляционные данные, и вам нужны транзакции с этими данными, это очень похоже на то, что вам нужна реляционная база данных.

С базами данных "NoSQL", такими как Mongo, вы отказываетесь от ACID для таких функций, как много записываемых реплик, осколок и быстрый доступ к данным документа. Похоже, вы не пользуетесь этим, поэтому зачем брать компромисс? В последнее время многие люди используют гибридные подходы к PostgreSQL, сохраняя документы в реляционной таблице как blobs JSON. При этом у вас может быть преимущество хранения ваших данных в виде неструктурированных столбцов, где это не требуется.

Итак, если у вас есть несколько документов, которые необходимы для транзакции при обновлении, вы можете вывести из строки ключи и иметь столбец "документ" или что-то еще, где это просто капля JSON, где вы сериализуете и десериализуете его. Это не критикует Mongo или другие хранилища документов как базу данных, но это просто не очень хороший выбор для транзакционных данных с несколькими документами. MarkLogic Я считаю, что ACID также работает над несколькими документами.

Я думаю, что многие люди находят обращение с mongodb из-за отсутствия схемы, но я думаю, что в конце концов они доберутся, пытаясь обуздать реляционную модель. Так как всегда выбор БД зависит от того, как ваши данные.

Ответ 10

Если бы я был вами, я бы внимательно посмотрел на Солра. Базовый уровень данных (Lucene) на сегодняшний день является самым зрелым из баз данных NoSQL, а Solr делает установку, настройку и интеграцию однолучевого магазина lucene тривиальным.

В ответ на ваш вопрос он поддерживает транзакции, определяемые пользователем. Оптимизированный для чтения характер Lucene может сделать его непригодным для многих приложений, но большинство из них хорошо подходят для Solr/Lucene + [SQL, Cassandra, CouchDB, RDF] в зависимости от требований.

Лично я склонен начинать с Solr + SQL или Solr + RDF, но я знаю некоторых людей, которые любят весь стиль NodeJS + CouchDB, и я убежден в ценности гибкости, которая предоставляет.

Суть в том, что есть достаточное количество NoSQL и SQL-расширений, которые заботятся о целостности данных, чтобы удовлетворить любые требования, которые у вас есть, без необходимости компрометации вас или данных ваших пользователей.

Ответ 11

Лично я считаю, что вам действительно нужно проверить, каковы ваши требования.

В связи с динамикой работы ОС вашего сервера сложно сказать, что все "сразу" переходит на диск, даже когда вы рассказываете об этом. конечно, я знаю, что технологии ACID, такие как SQL, уязвимы для частичной коррупции через недоработанный бизнес и проигрывают операции в определенном окне, когда один сервер опускается, к сожалению, это одна из проблем использования одного сервера; у вас нет выбора, кроме как принять его.

Я должен отметить, что транзакция не гарантирует, что ваш сервер получит все данные до сбоя (http://en.wikipedia.org/wiki/Database_transaction), я имею в виду то, что если сервер умирает частично через транзакцию?

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

На самом деле из-за веса некоторых транзакций и количества запросов, выполняемых в них, я полагаю, что вы можете получить большее окно операционных потерь с помощью транзакций, чем вы могли бы из 60 мс писать в окно диска на MongoDB время от времени. Но, конечно, это зависит от злоупотреблений, однако, как и хранимые процедуры, это злоупотребление является обычным явлением.

Транзакции сияют при каскадных удалениях и типичных сценариях, таких как перенос денег на банковский счет, однако каскадируемые удаления обычно лучше выполняются (как это делают большинство сайтов) с помощью cronjob с приложением, маркирующим строку как удаленное (чтобы избежать отката транзакция, показывающая удаленные данные обратно пользователю); таким образом вы можете сделать много вещей, чтобы обеспечить согласованность, которую вы не можете выполнять в режиме реального времени, пока пользователь использует ваше приложение.

Итак, вы действительно должны задаться вопросом, зачем вам нужна технология и что ей удастся сделать, поскольку краткость вашего вопроса говорит мне, что вы совершенно не уверены в своих требованиях.