关于mysql中的表设计或选择Hbase

Question

我们的产品应用场景如下：

1. 商店信息。
2. 计数使用数约为8000万。
3. 用户有很多属性，大约1000万。属性可以是许多不同的类型：Date，Boolean，Long，Int ....或Null。

我们对这些信息的处理方式如下：

1. 获取一个用户的信息（多个属性）
2. 从计算属性中选择用户。例如：查找propertyA>10 && propertyB=true &&...
的用户

现在，我们使用的是Hbase 就像一个宽柱的桌子， 但我想可能是不合适的。 当我们得到一个或多个用户的信息时，它经常会超时，所以我们放入一个缓存 中间，但我们不能把所有信息都放在缓存中，然后超时仍然存在！ 所以，我认为也许hbase不是最好的机会，因为我们的数据不是太大而不能使用hbase？ 如果我们选择mysql？

如何解决我们的问题？

Answer 1

在得出任何结论之前，您需要分析一些事情，其中​​一些是：

1. 您的数据大小是多少？在记录数量方面，但在数据文件大小方面没有？
2. 您使用的是什么类型的HBase安装？它是独立的还是群集的？
3. 从HBase调用get / scan是否正在超时？

IMO，如果HBase不会给你带来任何良好的性能结果，那么它不会降低性能。但是，是的，任何NoSQL数据库的实际使用都将在数据繁殖的集群环境中进行。

如果您想使用mysql或任何其他RDBMS，那么您必须考虑数据库集群，表分片，负载平衡以及在应用程序级别实现缓存。

总的来说，我认为您应该查看HBase的安装并尝试根据您的应用进行调整。