数据库节点扩容原理有哪些，为什么数据库不能通过不断的添加服务器节点来实现扩展

1，为什么数据库不能通过不断的添加服务器节点来实现扩展

数据库是可以通过不断添加服务器节点来实现扩展的，即使是MySQL也有集群模式，更不用说那些天生就是为了分布式优化的数据库了比如MongoDB，memcache，更不用说那些生来就是分布式的数据库了Hive，Impala。这种分布式数据库都可以部署在数千台服务器上。

为什么数据库不能通过不断的添加服务器节点来实现扩展

2，如何使得数据库的空间可以无限扩展

表空间是建立在数据文件上的，数据文件自动扩展即可。普通文件表空间是32G，Oracle10g新增的表空间类型：大文件(Bigfile)表空间。大文件表空间从某种角度来说提高了Oracle在VLDB上的管理能力。只有自动段空间管理的LMT(LocallyManagedTablespaces)支持BIGFILE表空间。大文件表空间只能包含一个文件，但是文件可以达到4G个数据块大小。(以下用BFT指代BIGFILETablespace。)

如何使得数据库的空间可以无限扩展

3，sql server 扩展存储过程是怎样的

根据我的了解，sql 的存储过程没有办法像我们开发工具(比如 visual studio系列) 那样自由调试(包含：立即窗口、监视等)的。即便如此，你还是可以通过输出的变量值来判断其是否按照预定的目标运行。比如，你想得到存储过程中 @abc 的变量值。做法如下：在存储过程中写入： select @abc as abc 然后你在查询分析器里面运行： exec 存储过程参数1,参数2，……参数n 即可得到 @abc 的输出内容；采用此方法虽然没有vs 方便，但也可以取到变量的数据！总之，祝你好运！

存储过程的优点(1)执行速度快。存储过程创建是就已经通过语法检查和性能优化，在执行时无需每次编译。存储在数据库服务器，性能高。(2)允许模块化设计。只需创建存储过程一次并将其存储在数据库中，以后即可在程序中调用该过程任意次。存储过程可由在数据库编程方面有专长的人员创建，并可独立于程序源代码而单独修改。(3)提高系统安全性。可将存储过程作为用户存取数据的管道。可以限制用户对数据表的存取权限，建立特定的存储过程供用户使用，完成对数据的访问。存储过程的定义文本可以被加密，使用户不能查看其内容。

sql server 扩展存储过程是怎样的

4，如何进行mysql的动态扩容和缩容

mysql在线扩容和缩容一般涉及到的内容，主要包括三个方面，1.在线也就意味着需要把增量的数据重新分布到新的拓扑结构中,我们一般称做增量复制，2.原有的数据需要一条不漏的扫出来重新分布到新的拓扑结构中,这个一般叫做全量复制，3.全量做完，增量正在同步，把应用的数据路由拓扑切到新的路由拓扑上来，并且做到无数据丢失，这个我们叫做停写切换。做好这三个方面的工作，能够达到的效果就是应用在最后切换数据分布拓扑的时刻，只要停写非常短的时间(秒级别)就能够做到无数据丢失的扩容和缩容。增量同步一般有2种方式，一种是应用端或者数据库前端做trigger,记录变更数据的特征值log(比如pk,sharding key)，然后异步复制到新的拓扑结构中。另外一种方式是通过分析mysql的binlog再进行不同数据拓扑的复制。两者本质上来说应该是一样的，后者可能更加简便，并且对应用无侵入，前者虽然也能够做到，实际实现或者推广和操作上都有不少阻力，最起码解析binlog方式是mysql一上去，更新的log已经天然存在与binlog中了。增量同步的两种方式如果要考虑到同步的可伸缩性(也就是多台机器可以同时消费相同的变更日志)，需要在原数据中添加数据的版本信息防止更新乱序，或者通过唯一键进行复制机器的sharding,也就是不同进程(线程)同时消费相同的更新日志，必须让同一条记录的更新落在同一个线程里面，如果还需要保证复制的事务，那么实现会非常复杂，一般不会去支持多线程下复制的事务。全量复制，也就是扫描需要复制的表的数据进行重新分布，主要存在的问题是复制速度和对数据库的写入压力的矛盾，其实能够做到整个拓扑连数据库都全部换掉，来达到对正在使用数据库的0影响，这个是一种可行的方案，另外是分时段调整复制线程数，一般单线程复制对于数据库的影响不会很大，在凌晨再转换成多线程方式达到提速的目标。扩容或者缩容在最后阶段如何切换，这个涉及到的问题主要是如何避免新更新进来以至于增量没完没了，方式有很多，最简单的方法就是停掉应用，一般时间只有几分钟是可以接受的。另外一种是逻辑停写，因为我们迁移的时候是有一个规则去重新散列数据，也就是如果新的规则和旧的规则两者算出来的结果不一致，那么这个数据就是需要被迁移的，如果在停写的时刻，向前端抛错即可。逻辑停写最大的好处就是避免PE的介入，并且配合动态的数据路由数据推送，可以完全避免重新发布达到扩容或者缩容，这个就是真正的在线扩容，停写不可避免（等待延迟的增量同步完成），但是不影响读。数据扩容或者缩容，我们觉得不应该排入业务的开发日程中，而是由数据管理团队对应用透明地进行这种操作，最后介入的人员只是DBA而已。但是不像一些nosql一样按容量或者完全透明的split,数据库的sharding还是按照应用的数据特性（pk,user_id,gmt_create等等不同字段，自选策略）进行sharding,应用知道他们的某条数据具体存在哪个机器哪张表上，这个无论对于开发还是测试或者DBA都是一件不错的事情。

额

5，如何对SQL Server数据库进行横向扩展

一般人们会选择纵向扩展（scale up）SQL Server数据库，而非横向扩展（scale out）。纵向扩展很容易：增加硬件、处理能力、内存、磁盘和提高网络速度。其原理就是仍然在一台服务器上运行数据库，但是增加了服务器的处理能力和资源。这种方法很昂贵，但是非常简单直接。　　采用云技术　　有时候，最简单的方法就是将问题交由其他人处理。微软的Windows Azure云服务包含一个基于云的SQL Server版本SQL Azure.这在技术上并非真正意义的横向扩展，因为它是一种无限纵向扩展方法。所以，转移到Azure并不需要对您的应用程序进行大改动。实际上，您只需要将应用程序迁移到SQL Azure,然后支付存储、处理和数据传输费用。这些都是收费服务，但是您不需要再担心扩展问题。　　复制　　SQL Server原生复制是一种支持横向扩展的解决方案，与数据库的创建和使用方式有关。您只需要在多台服务器上复制多个数据库副本，然后将不同的用户指向各台服务器。这种方法通常最适合支持地理位置分散的用户，如亚洲办公室的用户使用服务器1,而北美办公室的用户则使用服务器2.每一台服务器都拥有完整的数据副本，并且会复制伙伴服务器的所有修改。　　这种方法不支持自动负载均衡，并且最适合用在用户固定只使用一部分数据的情况。换而言之，如果亚洲用户只需要编辑与他们办公室相关的数据--例如，主要是亚洲客户的信息，那么复制能够保证其他数据库副本也包含这些记录的副本。如果所有用户都需要编辑完整的数据集，那么复制就变得有一些复杂，因为SQL Server必须在支持用户的同时，编辑位于不同服务器的同一个数据。　　SQL Server的合并复制能够处理这种冲突，但是您必须进行一些自定义合并编程，这意味着您的开发人员必须开发一些算法，确定用户并发访问数据时谁获取编辑权限。客户应用程序也需要增加编程；使它们不仅向数据库提交数据修改，也要循环检查这些修改是否被其他并发用户重写。用户也需要重新培训，因为客户端应用程序可能会提示："您正在编程的数据已经发生变化。您需要重新检查，确定您的编辑是否仍然有效。"　　联合数据库　　另一个重要的横向扩展方法是联合。通过这种方法，您可以将数据库划分到多台服务器上。垂直分割将同一个表的不同行保存到不同的服务器上。同时，地理分区是最常用的方法：将所有亚洲数据记录保存在一台服务器上，而所有欧洲数据则保存在另一台服务器上。这种方法不同于整体复制：每一个位置的服务器都不具备完整的数据库，而只拥有该位置的数据。通过实现一种SQL Server分布式分区视图而形成完整的表，用户就可以浏览一个"联合"或组合的数据视图。水平分割则将表的字段保存在不同的服务器上，因此各台服务器一起协作构成组合的表。　　这些数据库的创建并不简单，其中涉及一种整体操作。您需要掌握关于数据访问和使用的详细信息，才能够实现正确的部署。此外，您还需要一位SQL Server数据库架构师，他应该全面理解这些技术，分析您的业务情况，并且能够正确地创建这些组件。　　在一些情况中，实现这种横向扩展对客户端应用程序的改动很小。对于本身在设计上大量使用视图和存储过程进行数据访问的应用程序，更是如此。因为这些元素只是是在后台抽象，在客户端上不会发生变化。但是，这些应用程序并不常见；通常，实现横向扩展都需要修改客户端程序，使客户端与后台结构分离。　　横向扩展并不简单　　毫无疑问，实现SQL Server横向扩展非常复杂--这也是Azure等云数据库系统流行的原因之一。此外，有一些第三方供应商能够帮助实现横向扩展技术，而不需要完全依赖SQL Server的原生特性。您需要自己下功夫了解这些方法，理解数据访问和使用方法，这样才能够选择最符合您要求的方法。

文章TAG：数据库节点扩容原理有哪些为什么数据库不能通过不断的添加服务器节点来实现扩展