blocks|key|5187353|text|有一些存储技术，如JavaSpaces+(或商业实现，如Gigaspaces)，可提供对对象的高度可扩展、快速和安全的访问。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5187354|还有一些分布式缓存系统，比如memcached，它们提供了类似的方法。|5187355|当然，这两者都不是真正的数据库，但它们可以与数据库一起工作，以提供大量的水平可伸缩性，只要有合适的体系结构。真正的问题是，如果您想要数据库带来的所有ACID好处，就会有某些不可避免的性能损失。唯一的出路是找出不需要ACID的部分，并使用其他技术为这些部分提供服务。|5187356|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are storage techniques such as JavaSpaces (or a commercial implementation such as Gigaspaces) which provide highly scalable, fast &amp; secure access to objects.

There are also distributed cacheing systems such as memcached, which offer a similar approach.

Of course, neither of these are true databases, but they are things that can work in conjunction with databases to offer a large amount of horizontal scalability, given a suitable architecture. The real problem is that if you want all of the ACID goodness that comes with a database, there are certain unavoidable performance penalties. The only way out is to figure out the bits where you don't need ACID, and use other technologies to service those bits.

blocks|key|718417|text|Netezza和其他数据仓库设备以这种方式扩展，但它们不适合于OLTP和web应用程序工作负载。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|718418|entityMap|0|LINK|mutability|MUTABLE|url|http://www.netezza.com/^0|0|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="http://www.netezza.com/" rel="nofollow noreferrer">Netezza</a> and other datawarehouse appliances scale this way, but they are not good for OLTP and web app workloads.

blocks|key|3777030|text|用于跨多台计算机进行扩展的Oracle路由称为Real+Application+Clusters+(Oracle+RAC)。在其他地方有很多关于这方面的文档；您可以尝试从http://www.oracle.com/database/rac_home.html开始。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3777031|entityMap|0|LINK|mutability|MUTABLE|url|http://www.oracle.com/database/rac_home.html^0|2D|18|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

The Oracle route for scaling across multiple machines is called Real Application Clusters (Oracle RAC). There's no end of documentation on this elsewhere; you might try starting at <a href="http://www.oracle.com/database/rac_home.html" rel="nofollow noreferrer">http://www.oracle.com/database/rac_home.html</a>.

blocks|key|723680|text|Oracle+RAC+--真正的应用集群|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|723681|这很好用，您只需将框添加到您的集群。您可以从一个计算机故障转移到另一个计算机。这不是复制，所有的盒子都是同一逻辑单元的一部分。|723682|当然，这是相当挥霍无度的。|723683|entityMap^0|0|K|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

Oracle RAC -- Real Application Cluster

This works nicely, you just add boxes to your cluster. You can fail over from one box to the other. It's not replication, all the boxes are part of the same logical unit.

It's pretty spendy, of course.

blocks|key|5187536|text|Oracle+RAC是数据库中的Rolls+Royce，允许相对轻松地添加额外的硬件节点和硬件故障转移。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5187537|然而，与许可证成本相比，您的商用硬件成本将相形见绌。|5187538|为什么你觉得你需要水平缩放。具有40+DB和SAN存储的多CPU核心服务器可以支持非常大的数据库安装。|5187539|您能否提供任何规模和预期活动信息，以便更好地了解您的问题？|5187540|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Oracle RAC is the Rolls Royce of databases allowing extra hardware nodes to be added relatively easily and hardware failover.

However, your commodity hardware costs will be dwarfed by the licence costs.

Why dod you feel you need horizontal scaling. A multi CPU core server with 40GB RAM and SAN storage can support very sizeable DB installation.

Can you provide any sizing and expected activity information to allow better understanding of your problem?

blocks|key|2931999|text|别担心，好的解决方案马上就来了！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2932000|Couchdb和Hypertable是开源的，仍处于alpha阶段，但它们显然是为了简化商用软件的扩展而设计的。它们工作得很好，可能会改变你对数据库的看法。|offset|length|2932001|另外，如果让别人为你做分发是可以的，Google+AppEngine和Amazon+SimpleDB是非常便宜的分布式数据库服务，尽管它们现在都是测试版，所以有严格的限制。|2932002|entityMap|0|LINK|mutability|MUTABLE|url|http://incubator.apache.org/couchdb/|1|http://hypertable.org/|2|http://code.google.com/appengine/|3|http://www.amazon.com/SimpleDB-AWS-Service-Pricing/b?ie=UTF8&node=342335011^0|0|0|7|0|8|A|1|0|I|G|2|Z|F|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]|$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]|$D|17|E|18|1|19]]|A|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]|R|$5|K|L|M|A|$N|S]]|T|$5|K|L|M|A|$N|U]]]]

Don't worry, good solutions are coming!

<a href="http://incubator.apache.org/couchdb/" rel="nofollow noreferrer">Couchdb</a> and <a href="http://hypertable.org/" rel="nofollow noreferrer">Hypertable</a> are open source and still in alpha, but they are clearly designed to make scaling on commodity software simple. They work pretty well, and may change how you think about databases.

Also, if it's okay to let someone else do the distributing for you, <a href="http://code.google.com/appengine/" rel="nofollow noreferrer">Google AppEngine</a> and <a href="http://www.amazon.com/SimpleDB-AWS-Service-Pricing/b?ie=UTF8&amp;node=342335011" rel="nofollow noreferrer">Amazon SimpleDB</a> are extremely cheap distributed database services, though they're both in beta right now so strict limitations are imposed.

blocks|key|5187698|text|Oracle+Real+Application+Clusters。如果你想要最好的，那就看看吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5187699|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Oracle Real Application Clusters. If you want the best then take a look at it.

blocks|key|2932074|text|如果您真的认为可以向外扩展一个像样的多核“大铁盒”，那么您可以考虑对数据进行分区。这是一种与数据库无关的向外扩展的好方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2932075|所有水平的数据库都会带来严重的成本。|2932076|除非你有大量的$$来解决这个问题，否则就忘了RAC吧，虽然它很好，但是一旦你扩展到超过2个节点，它就会变得非常昂贵。|2932077|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you seriously think you will out scale a decent multicore "Big Iron" box, then you think about partitioning your data. This is a good, database agnostic way to scale out.

All databases which horizontally will come at a serious cost. 

Unless you have mega $$'s to throw at the problem, forget about RAC. While its very good, its VERY expensive once you scale beyond 2 nodes.

blocks|key|723774|text|如果你真的沿着RAC路线走下去，值得记住的是，它不会永远水平扩展。即使是销售人员也承认，90%25的rac客户是4个或更少的节点。一旦你走得更远，你得到的回报就会递减。因此，rac可能适用于您，但不能保证它就是答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|723775|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you do go down the RAC route it's worth remembering that it doesnt scale horizontally forever. Even the sales guys admit 90% of rac customers are 4 nodes or less. Once you go more than that you get diminishing returns. So rac may work for you, but it's not guaranteed to be the answer.

blocks|key|5187848|text|MySQL：http://www.mysql.com/why-mysql/scaleout.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5187849|限制是它在以读为主的工作负载下工作得最好。您通常有一个接收所有写入的“主”，以及许多复制写入的“从”。然后，将读取内容分布到所有数据库中。|5187850|MySQL复制是异步的，因此您可能必须处理时间延迟问题(在复制写操作之前，先向主服务器写入数据，然后从从服务器读取数据)。|5187851|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mysql.com/why-mysql/scaleout.html^0|6|18|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

MySQL: <a href="http://www.mysql.com/why-mysql/scaleout.html" rel="nofollow noreferrer">http://www.mysql.com/why-mysql/scaleout.html</a>

Limitations are that it works best with read-mostly workloads. You typically have one 'master' that receives all the writes, and many 'slaves' that replicate the writes. Then you distribute the reads over all the databases.

MySQL replication is asynchronous, so you will probably have to deal with time lag problems (you write to the master, and then read from a slave before the write has been replicated).

blocks|key|2932326|text|Oracle+RAC根本不能横向扩展，因为所有Oracle实例共享相同的数据存储。是的，使用SAN可以获得一个大容量的数据库，但它根本就不具有可扩展性。换句话说，Oracle+RAC仍然是一种向上扩展的方法。因此，对于向外扩展或水平扩展，您必须按功能对数据进行分区，这意味着将不同的表组放在不同的数据库中；或者对每个表进行数据分区，这意味着将一个表划分为具有相同模式但存储在不同数据库中的多个子表。这样，您就得到了一个向外扩展的解决方案。在这方面有很多资源。在Web2.0网站架构的博客领域，Sharding已经是一个时髦的词了。由于数据库本身不直接支持分片，因此您必须构建自己的解决方案。但正如我所说的，已经有很多经验教训。对于oracle，分区表是可能的。对于mysql，请检查this+question|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2932327|entityMap|0|LINK|mutability|MUTABLE|url|http://highscalability.com/unorthodox-approach-database-design-coming-shard|1|https://stackoverflow.com/questions/810085/mysql-proxy-alternatives-for-database-sharding^0|6U|8|0|9H|D|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Oracle RAC is not horizontally scalable at all, because all Oracle instances share the same data storage. Yes, with SAN stuff u can get a large size DB, but it's just not scalable at all. In other words, Oracle RAC is still a scale-up approach. So for scaling-out or horizontally scaling, you have to partition your data by function that means put different groups of tables in different databases; or partition your data per table that means partition one table into multiple subtables with the same schema but store in different databases. In this way, you get a scaling-out solution. There are many resources on that. <a href="http://highscalability.com/unorthodox-approach-database-design-coming-shard" rel="nofollow noreferrer">Sharding</a> has been a buzz word for a while in web 2.0 website architecture blog sphere.
Because Sharding is not directly supported by database itself, you have to build your own solution. But as I said, there are many lessons already. For oracle, partitioning table is possible. For mysql, check <a href="https://stackoverflow.com/questions/810085/mysql-proxy-alternatives-for-database-sharding">this question</a>

blocks|key|718726|text|MongoDB是水平扩展的最好的数据库之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|718727|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mongodb.org/^0|0|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="http://www.mongodb.org/" rel="nofollow">MongoDB</a>
is one of the best database that scales horizontally.

blocks|key|3777735|text|您可能会看到用于OLAP的DashDB+--+IBM将其与Cloudant+for+OLTP配对。https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3777736|entityMap|0|LINK|mutability|MUTABLE|url|https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en^0|1D|36|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You might look at DashDB for OLAP -- IBM pairs it with Cloudant for OLTP.
<a href="https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en" rel="nofollow">https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en</a>

Generally the database server is the biggest, most expensive box we have to buy as scaling vertically is the only option. Are there any databases that scale well horizontally (i.e. across multiple commodity machines) and what are the limitations in this approach?

Can you recommend a database that scales horizontally?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

通常情况下，数据库服务器是我们必须购买的最大、最昂贵的盒子，因为垂直扩展是唯一的选择。是否有水平伸缩良好的数据库(即跨多台商用机器)？这种方法的限制是什么？

问你能推荐一个水平伸缩的数据库吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你能推荐一个水平伸缩的数据库吗？EN