База данных nosql хороша для управления транзакциями онлайн-денег

Ответ 1

Нет баз данных NoSQL для решения нескольких задач, главным образом:

• (buzz) BigData​​strong >= > подумайте о TB, PB и т.д.

• Работа с распределенными системами/datasets = > говорит, что у вас есть 42 продукта, поэтому 13 из них будут жить в чикагском центре обработки данных, 21 в Нью-Йорке, а другой и 8 в Японии, но один раз вы запрашиваете все 42 продукта, вам не нужно будет знать, где они находятся: NoSQL DB. Это также позволяет задействовать намного больше мощности мозга (серверов) для решения сложных вычислительных задач [кажется, это не подойдет вашему варианту использования, но интересно отметить)

• Разделение = > с тем, чтобы ваша БД была легко распределена, кроме этих классных 8 продуктов в Японии, также позволяет легко реплицировать данные, поэтому эти 42 продукта будут тиражироваться с коэффициентом 3, например, что означало бы, что у вас будет 3 копии для каждого продукта. Следовательно, если что-то снижается, нет проблемы = > здесь доступна реплика. Это то, где базы данных NoSQL действительно сияют против RDBMS. Предоставлено, вы можете осколочно, разбивать и кластеризовать Oracle/MySQL/PostgreSQL/и т.д. НО, но это несколько более сложных процессов и, как правило, головная боль для большинства людей, которых вы использовали.

(на ваши вопросы)

• Ежедневно будет минимум 1000 пользователей

  1000 пользователей ежедневно являются крайне низким объемом, если вы не выбрали решение NoSQL, которое было написано вчера в 3 часа ночи в качестве концепции доказательства, здесь не должно быть никаких проблем. Но если вы добьетесь успеха и у вас будет 100 000 000 пользователей через пару месяцев, NoSQL будет проще масштабировать.

• Будет ли проблема доступности?

  Решения Solid NoSQL позволяют указать что-то, что называется quorum: "Количество реплик, которые должны отвечать на запрос чтения или записи до того, как он считается успешным". Некоторые решения также делают что-то, называемое hinted handoff: "соседние узлы временно захватывают операции хранения для отказавшего node". В общем, вы должны иметь возможность контролировать доступность в зависимости от ваших требований.

(из ваших комментариев)

• Мы планируем расширить. И не хотите, чтобы база данных была ограничением.

Expanding - очень относительный член. "Финансовая индустрия довольно расширена", и они по-прежнему в основном используют СУБД для повседневных операций. Facebook использует MySQL. Основные банки, для которых я работал, используют Oracle/MySQL/PostgreSQL/DB2/и т.д., И только некоторые из них используют NoSQL, но НЕ для данных, которые требуют 100% -ной согласованности все время. Даже Facebook использует Cassandra только для таких вещей, как "Inbox Search". Но если по расширению вы имеете в виду больше данных и больше пользователей (запросы, подключения и т.д.), NoSQL будет намного проще масштабировать. Опять же, это не значит, что вы не можете масштабировать РСУБД, это просто более утомительно/сложно.

• Из того, что я прочитал, в SQL-базе данных нам не нужно много думать о схеме

По моему опыту, если я создаю какую-либо хорошую систему, я ВСЕГДА должен думать о схеме. Базы данных NoSQL позволяют вам быть более гибкими с данными, которые вы сохраняете, но это не значит, что вы должны меньше думать о схеме. Подумайте, например, индексировать данные или оштрафовать их на несколько кластеров или даже контракты/интерфейсы, которые вы можете подвергать клиентам, и т.д.

• Техобслуживание, требуемое для базы данных NoSQL, очень мало

Я бы не сказал, что это правда в целом, если мы не говорим о BigData. Например, возьмите PostgreSQL. Это чрезвычайно удивительная часть программного обеспечения, с которой легко работать и обслуживать. Еще один плюс для RDBMS world = > люди чувствуют себя LOT более комфортно с SQL. По этой причине, например, ребята из Cassandra выпустили CQL в 0.8, что является очень ограниченным подмножеством SQL. Такие термины, как maintenance, также должны стоять плечом к плечу с такими терминами, как Talent, Knowledge, Expertise. Так как если вы используете Cassandra, например, эта девушка очень "очень хороша", но не для парней из DataStax, у которых есть Expertise, но вам придется заплатить за это.

Ваш главный вопрос

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

Не зная, что такое ваш продукт, трудно сказать, будет ли база данных NoSQL соответствовать/не подходит. Если основной целью продукта является "онлайн-транзакция с деньгами", я бы предложил в отношении базы данных NoSQL (по крайней мере, сегодня в 2011 году). Если "Онлайн-денежная транзакция" является лишь одним из требований, но не "ядром" вашего продукта, в зависимости от того, что такое "ядро", вы можете определенно дать NoSQL-базе данных попробовать и, например, использовать внешнюю службу для обработки (например, Google Checkout и т.д.) ваши транзакции с гарантированной согласованностью.

Как техническая нота, если проблема, которую вы пытаетесь решить, может быть решена с помощью дистрибутива, я бы рекомендовал базы данных, написанные в Erlang (например, Riak, CouchDB и т.д.), поскольку Erlang как язык уже успешно решает большинство распространенных вещей на протяжении десятилетий.

Ответ 2

MarkLogic - это база данных NoSQL с транзакциями ACID, которые используются для управления как виртуальной валютой в играх, так и реальной банковской сделкой.