SQL против NoSQL для системы управления запасами

Question

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

1. Очереди для управления обновлениями инвентаризации для каждого канала.
2. Таблица инвентаризации с правильным снимком распределения по каждому каналу.
3. Сохранение сеансаИдентификаторы и другие данные быстрого доступа в кеше.
4. Предоставление панели управления в стиле Facebook (XMPP), чтобы держать продавца в курсе как можно скорее.

Решения, на которые я смотрю, - это postgres (нашидо сих пор в режиме синхронной репликации), решения NoSQL, такие как Cassandra, Redis, CouchDB и MongoDB.

Мои ограничения:

1. Обновления инвентаря не могут быть потеряны.
2. Очереди заданий должны быть выполнены по порядку и желательно никогда не теряться.
3. Простая / быстрая разработка и дальнейшее обслуживание.

Я открыт для любых предложений.заранее спасибо.

Answer 1

1. Очереди для управления обновлениями инвентаря для каждого канала.

Это не обязательно проблема базы данных.Возможно, вам лучше взглянуть на систему обмена сообщениями (например, RabbitMQ)

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

данные сеанса, вероятно, следует поместить в отдельную базу данных, более подходящую для этой задачи (например, memcached, redis и т. д.)-all DB

1. Предоставление Facebook-панели управления (XMPP), чтобы держать продавца в курсе как можно скорее.

Мои ограничения: 1. Обновления инвентаря не могут быть потеряны.

Есть 3 способа ответить на этот вопрос:

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

2. некоторые БД хранят записи в памяти, а затем перезаписывают память на диск, это может привести к потере данныхв случае сбоя питания.(например, Mongo работает таким образом по умолчанию, если вы не включите ведение журнала. CouchDB всегда добавляет к записям (даже удаление - это флаг, добавляемый к записи, поэтому потеря данных чрезвычайно затруднительна))

3. Некоторые БД спроектированы так, чтобы быть чрезвычайно надежными, даже если в результате землетрясения, урагана или другого стихийного бедствия они остаются долговечными.К ним относятся Cassandra, Hbase, Riak, Hadoop и т. д.

К какому виду долговечности вы относитесь?

1. Очереди заданий должны выполняться впорядок и желательно никогда не теряется.

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

1. Простая / быстрая разработка и будущееобслуживание.

Как правило, сначала вы обнаружите, что SQL быстрее разрабатывается, но для реализации изменений может оказаться сложнее, для noSQL может потребоваться немного больше планирования, но это проще сделать ad hocзапросы или изменения схемы.

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

1. "Будут ли мне нужны интенсивные запросы или глубокий анализ, что Map /Reduce лучше подходит для? "

2. " мне нужно будет часто менять свою схему?

3. "Являются ли мои данные высоко реляционными?каким образом? "

4. " Достаточно ли у продавца за моей выбранной БД опыта, чтобы помочь мне, когда мне это понадобится? "Понадобятся ли мне специальные функции, такие как GeoSpatial indexing, полнотекстовый поиск и т. д.? "

5. " Насколько близко к реальному времени мне понадобятся мои данные?Будет ли больно, если я не увижу последние записи в моих запросах до 1 секунды позже?какой уровень задержки приемлем? "

6. " что мне действительно нужно с точки зрения переключения при сбое "

7. " насколько велик мойданные?это поместится в памяти?это будет соответствовать на одном компьютере?каждая отдельная запись большая или маленькая?

8. "как часто меняются мои данные? это архив?"

Если вы собираетесьчтобы иметь несколько клиентов (каналов?), каждый из которых имеет свои собственные схемы инвентаризации, БД на основе документов может иметь свои преимущества.Я помню, как однажды я посмотрел на систему электронной коммерции с инвентарем, и в ней было почти 235 таблиц!Опять же, если у вас есть определенные реляционные данные, решение SQL может действительно иметь некоторые преимущества.

Я, конечно, могу видеть, как я мог бы построить решение, используя mongo, couch, riak или orientdb с заданными ограничениями. А что для чего лучше? Я бы попытался поговорить напрямую с поставщиками БД и, возможно, посмотреть ленты nosql

Answer 2

Решение ваших ограничений:

1. Большинство решений NoSQL предоставляют настраиваемый компромисс между согласованностью и производительностью.Например, в MongoDB вы можете решить, насколько длительной должна быть запись.Если вы хотите, вы можете заставить запись быть fsync'ed на всех ваших серверах наборов реплик.С другой стороны, вы можете отправить команду и даже не ждать ответа сервера.

2. Выполнение очередей заданий по порядку кажется проблемой кода приложения.Я бы сказал, что отметка времени в БД и тип запроса order by должны подходить для большинства приложений.Если у вас есть несколько серверов приложений и ваши очереди должны быть идеальными, вам придется использовать действительно распределенный алгоритм , который обеспечивает упорядочение, но это не типичное требование, и это действительно очень сложно.

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

В целом, я бы сказал, что вы можете сделать это обоими способами.NoSQL больше ориентирован на код, а транзакции и реляционная целостность в основном управляются вашим кодом.Если вам неудобно с этим, перейдите на реляционную БД.

Однако, если ваши данные становятся огромными, вам придется кодировать часть этой логики вручную, потому что вы, вероятно, не захотите делать это.соединения в реальном времени в базе данных строк 10B.Тем не менее, вы можете реализовать это и с помощью SQL.

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

Answer 3

NoSQL не подходит для этого приложения.

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

Нет причин, по которым вы не можете использовать оба - хранить реляционные данные в реляционных базах данных и нереляционные данные в хранилищах ключ / значение.