SQL与NoSQL的库存管理系统 [英] SQL vs NoSQL for an inventory management system

问题描述

我正在开发一个基于JAVA的Web应用程序。主要目标是在称为渠道的多个网站上销售产品的库存。我们将担任所有这些渠道的经理。
我们需要的是：

1. 排队管理每个频道的广告资源更新。




3. 在缓存中保存会话ID和其他快速访问数据。


4. 提供

我正在寻找的解决方案是postgres（我们的db到现在为止同步复制模式），NoSQL解决方案如Cassandra，Redis，CouchDB和MongoDB。

我的约束是：

1. 工作队列应按顺序执行，最好不要丢失。


2. 快速开发和未来维护。

我可以接受任何建议。提前感谢。

解决方案

1. 排队管理每个

这不一定是数据库问题。您可能最好查看邮件系统（例如RabbitMQ）

1. 具有正确快照的库存表




b
$ b

会话数据应该放在更适合任务的单独数据库中（例如memcached，redis等）
没有一个适合所有的DB










1. 提供一个面向Facebook的信息中心（XMPP），让卖家更新asap。



我的约束是：
1.库存更新不能丢失。




有3种方法可以回答这个问题：




1. 此功能必须由您的申请提供。数据库可以保证坏记录被拒绝和回滚，但不能保证每个查询都被输入。
   应用程序必须足够聪明才能识别发生错误的时间，然后重试。




2. 某些DB将记录存储在内存中，然后刷新内存到磁盘，这可能导致在电源故障的情况下的数据丢失。 （例如Mongo默认使用这种方式，除非你启用日志记录）CouchDB总是添加到记录（即使一个删除是附加到记录的标志，所以数据丢失是非常困难的））




3. 一些DB设计非常可靠，即使地震，飓风或其他自然灾害发生，它们仍然耐用。这些包括Cassandra，Hbase，Riak，Hadoop等。




>








1. 工作队列应按顺序执行，最好不要丢失。






大多数NoSQL解决方案都希望并行运行。所以你有两个选择。
1.使用一个DB为每个查询锁定整个表（慢）
2.构建你的应用程序以更聪明或事件化（客户端顺序排队）






1. 轻松/快速开发和日后维护。






一般来说，你会发现SQL在开始时更快，但是更改可能更难实现
noSQL可能需要更多的计划，但更容易执行即席查询或模式更改。





您可能需要问自己的问题更像：




1. 我需要对Map / Reduce更加适合的强烈查询或深入分析吗？




2. 我经常更改我的模式？




3. 我的数据是高度关系的吗？




4. 我选择的数据库后面的供应商有足够的经验来帮助我，当我需要它吗？




5. 我需要特殊功能，如地理空间索引，全文搜索等吗？




6. 到实时我需要我的数据吗？如果我没有看到最新的记录显示在我的查询，直到1秒后，它会伤害吗？什么级别的延迟可以接受？




7. 在故障切换方面我真正需要什么




8. 我的数据有多大？会适合内存吗？将它适合在一台计算机上？




9. 我的数据会多久更新一次？




如果你有多个客户（渠道），每个都有自己的库存模式，一个基于文档的数据库可能有它的优势。我记得有一次我看着一个电子商务系统的库存，它有近235张表！
再次，如果你有某些关系数据，一个SQL解决方案也可以有一些优点。





我可以肯定看到如何构建一个解决方案mongo，沙发，riak或orientdb与给定的约束。但至于哪个是最好的？我会尝试直接与数据库厂商交谈，或者观看nosql磁带




I am developing a JAVA based web application. The primary aim is to have inventory for products being sold on multiple websites called channels. We will act as manager for all these channels. What we need is:

1. Queues to manage inventory updates for each channel.
2. Inventory table which has a correct snapshot of allocation on each channel.
3. Keeping Session Ids and other fast access data in a cache.
4. Providing a facebook like dashboard(XMPP) to keep the seller updated asap.

The solutions i am looking at are postgres(our db till now in a synchronous replication mode), NoSQL solutions like Cassandra, Redis, CouchDB and MongoDB.

My constraints are:

1. Inventory updates cannot be lost.
2. Job Queues should be executed in order and preferably never lost.
3. Easy/Fast development and future maintenance.

I am open to any suggestions. thanks in advance.

解决方案

1. Queues to manage inventory updates for each channel.

This is not necessarily a database issue. You might be better off looking at a messaging system(e.g. RabbitMQ)

1. Inventory table which has a correct snapshot of allocation on each channel.
2. Keeping Session Ids and other fast access data in a cache.

session data should probably be put in a separate database more suitable for the task(e.g. memcached, redis, etc) There is no one-size-fits-all DB

1. Providing a facebook like dashboard(XMPP) to keep the seller updated asap.

My constraints are: 1. Inventory updates cannot be lost.

There are 3 ways to answer this question:

1. This feature must be provided by your application. The database can guarantee that a bad record is rejected and rolled back, but not guarantee that every query will get entered. The app will have to be smart enough to recognize when an error happens and try again.

2. some DBs store records in memory and then flush memory to disk peridocally, this could lead to data loss in the case of a power failure. (e.g Mongo works this way by default unless you enable journaling. CouchDB always appends to the records(even a delete is a flag appended to the record so data loss is extremely difficult))

3. Some DBs are designed to be extremely reliable, even if an earthquake, hurricane or other natural disaster strikes, they remain durable. these include Cassandra, Hbase, Riak, Hadoop, etc

Which type of durability are your referring to?

1. Job Queues should be executed in order and preferably never lost.

Most noSQL solutions prefer to run in parallel. so you have two options here. 1. use a DB that locks the entire table for every query(slower) 2. build your app to be smarter or evented(client side sequential queuing)

1. Easy/Fast development and future maintenance.

generally, you will find that SQL is faster to develop at first, but changes can be harder to implement noSQL may require a little more planning, but is easier to do ad hoc queries or schema changes.

The questions you probably need to ask yourself are more like:

1. "Will I need to have intense queries or deep analysis that a Map/Reduce is better suited to?"

2. "will I need to my change my schema frequently?

3. "is my data highly relational? in what way?"

4. "does the vendor behind my chosen DB have enough experience to help me when I need it?"

5. "will I need special feature such as GeoSpatial indexing, full text search, etc?"

6. "how close to realtime will I need my data? will it hurt if I don't see the latest records show up in my queries until 1sec later? what level of latency is acceptable?"

7. "what do I really need in terms of fail-over"

8. "how big is my data? will it fit in memory? will it fit on one computer? is each individual record large or small?

9. "how often will my data change? is this an archive?"

If you are going to have multiple customers(channels?) each with their own inventory schemas, a document based DB might have it's advantages. I remember one time I looked at an ecommerce system with inventory and it had almost 235 tables! Then again, if you have certain relational data, a SQL solution can really have some advantages too.

I can certainly see how I could build a solution using mongo, couch, riak or orientdb with the given constraints. But as for which is the best? I would try talking directly DB vendors, and maybe watch the nosql tapes

这篇关于SQL与NoSQL的库存管理系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！