可扩展数据库技术和体系结构

Question

我一直在努力学习更多关于分布式系统中数据库扩展的知识，而且我一直停留在关系数据库管理系统和NoSQL之间。

一些在线文章指出，NoSQL是现代大数据的解决方案。其他人认为NoSQL只是一种炒作，RDBMS可以通过良好的设计实现可扩展性，而且它提供了良好的数据结构。

与其阅读其他人的观点，我更愿意自己来判断这两者，但我并不完全理解可伸缩的关系数据库管理系统和可伸缩的NoSQL所需要的是什么。

我已经对RDBMS做了更多的解读，而且这个解决方案似乎需要利用memcache和切分来减少数据库大小和DB查询的数量。还有其他花招吗？你还能用有很多列的表吗？还是使用更少的列和更多的联接？

至于NoSQL，我读过一些关于MongoDB的文章。据我所知，它鼓励数据聚合。但是，这如何使其更具可伸缩性呢？我也开始学习卡桑德拉，因为我读到它比MongoDB扩展得更好，但我不知道它是如何更可伸缩的。

我非常感激一个基本的(或者高级的，如果你有耐心地把它打印出来的话)关于扩展关系数据库管理系统和NoSQL的精简单单的解释，或者在线的好文章或者解释这个主题的书籍。:)

Answer 1

我将不讨论如何通过自己实现事物和在中间放置一个memcache服务器来进行扩展，.我就把盒子里的东西盖起来.

让我们首先从关系数据库管理系统开始

我认为建立一个关系数据库管理系统集群比一个NoSQL集群要复杂得多，但这只是我的观点。通常你拥有的是一个主人和多个奴隶。你必须把你所有的写作发送给主人，并且可以从你想读的任何奴隶那里读到东西。由于您有RDBMS和ACID，系统应该以某种方式保证您不会读取旧数据。因此，这里的问题是，假设您的应用程序只写一次并经常读取(通常是这样)。出于这些目的，一个用于读/写的服务器和多个用于读取的服务器是很棒的。问题是，如果你写的太频繁，以至于你无法在一台机器上跟上它们。这是你的瓶颈。除了从甲骨文构建解决方案之外-这是巨大的-还有http://www.scalearc.com/可以缓存查询，.帮你处理一下。

NoSQL

没有一个由所有DBs实现的NoSQL模式。每个系统都有点不同。例如，MongoDB非常类似于关系数据库管理系统，它也只有一个主数据库和几个可以复制数据的从服务器，但是您还可以创建碎片。数据在碎片之间分割，并复制到奴隶中。因此，您可以有多个不同的主人，负责较小的部分。之后，当您阅读时，您可以选择是从多个从、从主还是从任何从中读取--这取决于您迫切需要最新的数据。

另一方面，卡桑德拉的工作方式完全不同。我不确定您是否可以写入多个服务器，也不确定它是如何工作的，但基本上服务器保存了所有写入的日志。因此，即使它们不能立即处理写入，它们也存储在日志中，以便仍然给出快速响应。之后，当你阅读的时候，你可以再说一遍你有多么迫切的想要新的数据，如果你真的想要最新的数据，卡桑德拉将需要检查日志，如果有任何的更新，它将花费你大量的时间。

像ElasticSearch、CouchDB、CouchBase这样的键值存储再次以不同的方式工作.在这里，对项的散列进行散列，并根据散列发送到一个将负责该项的节点。这样，当您在键被写入之后读取时，您将再次获得最新的信息，因为您将从同一个节点读取。这个设计的思想是，没有一个单一的键将对每个人都感兴趣，但是负载将被分配。这些也是我认为最适合扩展的DB，并且使得向集群添加更多的服务器变得最容易，但是您失去了复杂查询的功能，就像在MongoDB和Cassandra中一样--当然还有RDBMS。ElasticSearch有一些简单的搜索查询，而CouchDB和CouchBase只有由MapReduce生成的视图，在这些视图中，如果数据适合视图，就可以获取所需的数据。否则，您只能通过密钥访问它。

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis -是对最常见的NoSQL DB、它们的优点和缺点以及最常见的使用场景的非常全面的总结。

最后，问题是，你为什么要扩大规模？你在数据库里有多少条记录？几百万根本就不是问题。对于一个功能足够强大的服务器上的大多数RDBMS来说，几百万也不是问题。如果设计得当的话，DB和它的指数，即使是每年10亿个记录，也应该是可以的。