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

Ответ 1

EDIT: март 2013 г.

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

Здесь оригинальная статья для интересующихся:

http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/(ссылка archive.org)

Ответ 2

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

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

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

• Вам действительно нужен уровень производительности, который RDBMS не может выполнить?
• Вам нужна надежность, которую предоставляет СУБД?

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

http://www.mongodb.org/display/DOCS/Production+Deployments

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

Ответ 8

Да, http://myestoreapp.com использует MongoDB для всего. Проверьте это; не стесняйтесь снимать любые вопросы.