Есть ли любые веб-сайты электронной коммерции, которые используют [закрытые] базы данных NoSQL

Накладные расходы, которые делают РСУБД такой медленной, гарантируют атомарность, согласованность, изоляцию, долговечность, также известную как ACID . Некоторые из этих свойств очень важны для приложений, которые имеют дело с деньгами. Вы не хотите потерять ни одного заказа, когда погаснет свет.

Базы данных NoSQL обычно жертвуют некоторыми или всеми свойствами ACID в обмен на значительное сокращение накладных расходов. Для многих приложений это нормально - если несколько «копий» пропадут, когда погаснет свет, это не проблема.

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

1. Вам действительно нужен уровень производительности, который не может обеспечить РСУБД?
2. Вам нужна надежность, которую обеспечивает РСУБД?

Честно говоря, ответ на № 2, вероятно, утвердительный, что исключает большинство решений NoSQL. И если вы не имеете дело с уровнями трафика, сопоставимыми с amazon.com, RDBM даже на скромном оборудовании, вероятно, удовлетворит ваши потребности в производительности, особенно если вы ограничитесь простыми запросами и правильно индексируете. Что делает ответ на №1 «нет».

Вы могли бы , однако, рассмотреть возможность использования СУБД для данных транзакций и базы данных NoSQL для некритических данных, таких как страницы продуктов, отзывы пользователей и т. Д. Но тогда у вас будет вдвое больше хранилища данных программное обеспечение для установки, и любые отношения между данными в двух хранилищах данных должны будут управляться в коде - не будет никакого СОЕДИНЕНИЯ вашей базы данных NoSQL с вашей СУБД. Это, вероятно, приведет к ненужному уровню сложности.

В конце концов, если РСУБД предлагает функции, которые вам необходимы для обеспечения надежности, и она работает приемлемо для тех видов нагрузки, с которыми вы столкнетесь, РСУБД, вероятно, является лучшим выбором.

Работа с финансовой информацией - одна из областей, где SQL действительно является правильным инструментом для работы. Большинство систем NOSQL были разработаны для улучшения масштабируемости за счет принятия более высокого риска потери или несогласованности данных. У них также, как правило, ограниченные возможности для создания отчетов по всем записям, поскольку на типичном большом веб-сайте вам нужно только достаточно данных в индексе, чтобы найти и отобразить одну запись - остальные могут быть полностью недоступны, пока вы не узнаете, какую запись ищите. для.

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

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

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

Настоящий вопрос, ИМО, заключается в том, сможете ли вы жить с ограничениями, которые накладывает на вас база данных NoSQL, в частности, с общим отсутствием специальных запросов.Например, если вы когда-либо хотели знать всех людей, которые когда-либо покупали продукт «X», вам придется встроить в свой уровень доступа к данным счетчик для этого с первого дня (или запустить очень дорогой ] последовательный поиск каждой прошлой транзакции). В обычной базе данных SQL вы можете просто добавить индекс и выполнить запрос, и все готово (или даже не добавляйте индекс, если он разовый). Или, может быть, вы хотите узнать всех людей, которые купили продукт Y до того, как вышла последняя версия (чтобы вы могли отправить им напоминание об обновлении или что-то еще): опять же, вы должны спланировать это заранее с помощью базы данных NoSQL, но это тривиально с реляционной базой данных.

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

Вы, ребята, должны это проверить:

Подтверждение репликации через getlasterror

MongoDB находится на грани обеспечения длительной записи. Я думаю, что это основная проблема, с которой люди обсуждают эту тему w.r.t. Деньги. Транзакционная часть менее важна из-за особенностей вложенного документа.

Gilt.com использует Voldemort для обработки корзины / инвентаря при огромной нагрузке. Подробности смотрите в презентации с London QCon 2010 - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe

Я бы также повторил тот факт, что "NoSQL" означает не "No SQL", а "Not Only SQL", и что вместо того, чтобы рассматривать любую технологию как полную замену любой другой, вы должны искать лучший инструмент для работы. Хранилища данных NoSQL не являются хорошими хранилищами данных и, вероятно, не подходят для хранения пользовательских транзакций, но они очень хороши в определенных нишевых областях - см. пример Gilt Groupe выше.

Другим ярким примером является домашняя страница BBC - не транзакционная, но тем не менее интересная. Они используют CouchDB для хранения предпочтений пользователей. К сожалению, похоже, что они разрушились под нагрузкой.

[UPDATE: Я также могу подтвердить, что ASOS Marketplace использует некоторые компоненты NoSQL - http://bagcheck.com/bag/9206-asos-marketplace-technology ]