结合使用关系数据库和键值存储 [英] Using a relational database and a key-value store in combination

问题描述

我正在工作的项目的要求似乎指向将关系数据库(例如 postgre、MySQL)与键值存储(例如 HBase、Cassandra)结合使用.除了少量的相互依赖外，我们的数据几乎可以很好地分解为两种数据模型之一.

The requirements for the project I'm working seem to point to using both a relational database (e.g. postgre, MySQL) in combination with a key-value store (e.g. HBase, Cassandra). Our data almost breaks nicely into one of the two data models with the exception of a small amount of interdependence.

这不是将关系数据库塞进键值存储的尝试；它们彼此独立.

This is not an attempt to cram a relational database into a key-value store; they are independent of each other.

有什么重要的理由不这样做吗?

推荐答案

我在 SQL DBMS 领域工作，所以要考虑到这种偏见，但是...

I work in SQL DBMS territory, so take that bias into account, but...

和 Shiraz Bhaiji 一样，我担心除了少量的相互依赖".有很多事情需要考虑，而这些问题的答案将帮助您决定要做什么.

As with Shiraz Bhaiji, I worry about the "except for a small amount of interdependence". There are a number of things to think about, the answers to which will help you determine what to do.

• 如果相互依赖出现问题会怎样?(客户亏钱 - 那么你需要在整个过程中使用 DBMS；你亏钱 - 可​​能是一样的；有人报告说他们有 3045 分，而他们真的有 3046 分 - 也许这无关紧要.)
• 当出现问题时，修复烂摊子"有多难?
• 有多少工作在键值存储上，有多少在 DBMS 上?
• 是否可以通过将某些内容从键值存储转移到 DBMS 来消除相互依赖?
• DBMS 用作键值存储时有多慢?(你确定没有办法让它足够接近平价吗?)
• 在灾难恢复场景中会发生什么?同步备份?

如果您对这些和相关问题有足够的答案，那么可以采用混合设置 - 您已经考虑过，权衡了风险，形成了判断，并且继续进行是合理的.如果您没有答案，请获取.

If you have adequate answers to these and related questions, then it is OK to go with the mixed setup - you've thought it through, weighed the risks, formed a judgement, and it is reasonable to go ahead. If you don't have answers, get them.

这篇关于结合使用关系数据库和键值存储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！