Mysql 分布式数据库&x27；是不是？

INFORMIX-SQL 7.32（SE）Linux典当行应用程序

我有一些用户在方圆100英里内拥有几家当铺。每个当铺应用程序都与SE一起运行。这些所有者需要的唯一功能是：能够远程登录到任何商店，以便在工作日结束时查看交易、运行总计和合并每日总计。这可以通过拨号调制解调器实现，因为应用程序不需要显示BLOB。在一天结束时，每个商店的总数被卸载到一个平面文件中，并传输到所有者的系统中

---

我的所有者将通过转换为分布式数据库获得什么？。。是否能够查明某个门店的客户是否在另一个门店开展业务，或者另一个门店是否有所需的库存商品可供销售？（不重要，很少发生）。大多数顾客通常在同一家商店做生意，如果他们没有想要的东西出售，他们会去最近的竞争对手当铺。distributed db为实现第一段中描述的相同功能提供了哪些好处？。。当铺老板绝对拒绝通过互联网连接他们的生产系统！他们不信任它的安全性，甚至使用VPN、Cisco等，也不信任它的可靠性！在世界的这一地区，ISP的正常运行时间记录很差。我知道有几个应用程序因为通讯问题已经从网络转换成拨号

分布式数据库，更准确地说是Informix XPS和IDS，并不是只有一个优势。如果您只关心从不同的地方获取数据，那么只需一个设计策略就可以实现。如果您添加一个“branch_id”或类似的东西，您就完成了

分布式数据库有很多优点，从可用性到可扩展性。你必须先复习这些东西

很抱歉给出这样的答案，但要给您一个关于这个主题的直接答案确实很困难。

是一个基于对等的分布式数据库系统。任何数量的CouchDB主机（服务器和脱机客户端）都可以具有同一数据库的独立“副本副本”，其中应用程序具有完整的数据库交互（查询、添加、编辑和删除）。当重新联机或按计划时，数据库更改将双向复制

CouchDB具有内置的冲突检测和管理功能，复制过程是增量和快速的，只复制自上次复制以来更改的文档和单个字段。大多数应用程序不需要特别的规划来利用分布式更新和复制

---

与在相同的遗留模型和数据库上添加分布式功能的繁琐尝试不同，它是精心设计、工程和集成的结果。文档、视图、安全性和复制模型、专用查询语言、高效和健壮的磁盘布局都经过精心集成，形成了一个可靠和高效的系统。

如果数据库之间的正常运行时间不超过90%，那么分布式数据库就没有任何好处

一个主要好处是，当一台机器出现故障或不可用时，为大型企业提供“故障切换”。如果他们的数据库分布在三台或四台机器上，那么丢失一台不会影响他们的业务能力

---

第二个主要好处是数据库太大，一台服务器无法处理互联网规模的数据库（亚马逊、推特等）也有同样的流量。沃尔玛的流量也会达到这样的水平。几个店面操作就不会了。

我认为在这种情况下，分布式数据库操作几乎没有什么好处

如果您打算采用分布式操作，我可能会考虑使用简单的ER拓扑，其中“总部”存储是主（根）节点，其他存储是叶节点。然后将对单个存储数据库的更改复制到HQ节点；您可能也可能不将数据传播回其他存储区。特别是只有两个商店，实际上您可能只需将所有信息复制到两个商店；这将为您提供数据库的自动异地备份。（在这种情况下，您可能会将所有节点配置为根节点—至少，直到链增长到（比如）五到六个节点为止。）

这将为灾难恢复提供一定的恢复能力。它还可以让总部（特别是）了解每家商店的情况

---

我的印象是，您可能不是在平均讨论“每秒事务数”；单个存储的事务速率可能是每分钟几个事务，“很少”可能小于一个TPM。因此，网络带宽在任何时候都不太可能成为瓶颈，即使是拨号速度（尽管这可能是临界值）。

我会切换它（我不知道如何切换），但这似乎是服务器故障question@Justin-我不同意你认为这是一个错误导向的问题！。。这是一个“数据库设计”和连接问题。由于当前的应用程序是用Informix SQL编写的，我需要明确知道我可以在Informix或其他RDBMS中选择什么样的最佳替代方案。store_id是一个列，在我当铺应用程序的每个表中已经存在了20多年，我的用户一直在ETL'ng每日交易和总计。有谁能告诉我分布式数据库设计还有什么其他优势吗？弗兰克，我可以谈谈Informix，这是我唯一的经验。首先，主要的优势是在这个领域，你不必再担心设计了。这对你来说是透明的。只有DBA知道一个表在全国的多个商店中是零散的。其他优势？分布式查询、负载平衡、可用性、损坏恢复等（所有您在维基百科中找到的常见内容）。所以，问题是：你准备好了吗？你准备好花所需的钱了吗-