Базы данных NoSQL предназначены для решения нескольких задач, в основном:
(гудение) BigData => думать о ТБ, ПБ и т. Д.
Работа с Распределенными системами / наборы данных => скажем, у вас есть 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: « соседние узлы временно принимают операции хранения для отказавшего узла ».В общем, вы должны иметь возможность контролировать доступность в зависимости от ваших требований.
(из ваших комментариев)
- Мы планируем расширение.И не хочу, чтобы база данных была ограничением
Expanding - это очень относительный термин.«Финансовая индустрия довольно расширена», и они по-прежнему в основном используют RDBMS для повседневных операций.Facebook использует MySQL.Крупные банки, на которых я работал, используют Oracle / MySQL / PostgreSQL / DB2 / и т. Д., И только некоторые из них используют NoSQL, но НЕ для данных, которые все время требуют 100% -ной согласованности.Даже Facebook использует Cassandra только для таких вещей, как «поиск по входящим сообщениям».Но если под расширением вы подразумеваете больше данных и больше пользователей (запросов, соединений и т. Д.), То NoSQL будет намного легче масштабировать.Опять же, это не означает, что вы не можете масштабировать RDBMS, это просто более утомительно / сложно.
- Из того, что я прочитал, ни в одной базе данных SQL нам не нужно думать осхема много
По моему опыту, если я строю какую-либо хорошую систему, я ВСЕГДА должен подумать о схеме.Базы данных NoSQL позволяют вам быть немного более гибким с данными, которые вы сохраняете, но это не значит, что вам следует меньше думать о схеме.Подумайте, например, об индексации данных, о разделении их на несколько кластеров, или даже о контрактах / интерфейсах, которые вы можете предоставить клиентам и т. Д.
- Обслуживание, необходимое для базы данных NoSQL, оченьменьше
Я бы не сказал, что это вообще так, если только мы не говорим о BigData. Возьмите PostgreSQL для примера. Это чрезвычайно классная программа, с которой легко работать и поддерживать. Еще один плюс к миру СУБД => люди чувствуют НАМНОГО более комфортно с SQL. По этой причине, например, ребята из Cassandra выпустили CQL в 0.8, что является очень ограниченным подмножеством SQL. Такие термины, как maintenance, также должны стоять плечом к плечу с такими терминами, как Talent, Knowledge, Expertise. Поскольку, например, если вы используете Cassandra, эта девушка очень «требовательна», но не для парней из DataStax, у которых есть Expertise, но вам придется заплатить за это.
Ваш главный вопрос
- Я читал в блоге, что база данных NoSQL не очень хороша для онлайн-транзакций, т. Е. Где целостность данных имеет первостепенное значение. (Мой продукт имеет онлайн-транзакции)
Не зная точно, что представляет собой ваш продукт, трудно сказать, подойдет ли / не будет база данных NoSQL. Если основной целью продукта является «Денежная операция в Интернете», то я бы предложил против базы данных NoSQL (по крайней мере, сегодня в 2011 году). Если «онлайн-транзакция с деньгами» является лишь одним из требований, а не «ядром» вашего продукта, в зависимости от того, что такое «ядро», вы, безусловно, можете попробовать базу данных NoSQL и, например, использовать внешнюю службу для обработки. (например, Google Checkout и т. д.) ваши транзакции с гарантированной согласованностью.
В качестве технического примечания, если проблема, которую вы пытаетесь решить, выигрывает от решения с помощью дистрибутива, я бы порекомендовал базы данных, написанные на Erlang (например, Riak, CouchDB и т. Д.), Поскольку Erlang как язык уже успешно решается. большинство распределенных вещей в течение десятилетий.