解决share nothing数据库瓶颈：实用方法大揭秘 (share nothing数据库瓶颈)

解决Share Nothing数据库瓶颈：实用方法大揭秘

Share Nothing数据库架构是一种常见的分布式数据库架构，它将数据库分割成多个部分，并通过网络互连。每个部分都有自己的CPU、内存和存储设备，而且它们之间并不共享任何数据或资源。这种架构的优点在于可扩展性、可靠性和简单性，但是也面临着一些挑战，其中更大的挑战就是如何处理Share Nothing数据库的瓶颈问题。在本文中，我们将探讨解决这种问题的几种实用方法。

方法一：垂直扩展

垂直扩展是一种简单而有效的方法，它可以增加单个服务器上的CPU、内存和存储资源，从而提高系统的处理性能。这种方法通常适用于中小型数据库应用程序，其中数据量不是很大，而且并发请求比较少。通过增加硬件资源，垂直扩展可以提高系统的吞吐量和响应时间。

方法二：水平扩展

水平扩展是一种更为强大的方法，它可以将数据分片到多个服务器上，并利用负载均衡来实现分布式数据访问。这种方法适用于大型数据库应用程序，其中数据量非常大，而且并发请求很多。通过增加服务器数量，水平扩展可以提高系统的可扩展性和容错性。

方法三：数据压缩

数据压缩是一种减少数据存储量的方法，它通过将数据压缩成较小的数据块，从而节省存储空间和网络带宽。这种方法适用于大型数据库应用程序，其中数据量非常大，并且有大量重复数据。通过数据压缩，可以显著减少存储开销和数据传输时间。

方法四：支持快照

支持快照是一种备份和恢复数据库的方法，它可以在不影响生产系统的情况下创建数据库的快照副本。这种方法适用于大型数据库应用程序，其中数据量非常大，并且需要频繁备份和恢复数据。通过支持快照，可以快速恢复数据库，并减少系统停机时间。

方法五：使用缓存

缓存是一种存储数据的临时性媒介，它可以减少数据库访问的频率，并提高系统的性能和响应时间。这种方法适用于大型数据库应用程序，其中数据访问频率很高，并且有大量重复数据。通过使用缓存，可以显著提高系统的性能，减少数据库瓶颈问题。

结论

综上所述，解决Share Nothing数据库瓶颈的方法有很多，包括垂直扩展、水平扩展、数据压缩、支持快照和使用缓存。选择哪种方法取决于数据库的规模、复杂度和访问模式。如果您正在面对Share Nothing数据库瓶颈问题，那么请根据自己的需求和资源，采取适当的措施来解决问题。同时，还可以通过使用性能分析工具和监控软件来监测系统性能，并进行优化操作。

相关问题拓展阅读：

• MySQL Cluster 越来越完善，为什么没有在工业界大规模应用
• oracle数据库经常会出现占用cpu100%的进程，然后系统就挂了，怎么找出引起这种故障的sql语句
• 什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS两者的优势

MySQL Cluster 越来越完善，为什么没有在工业界大规模应用

1.MySQL Cluster的技术复杂度太高，毕竟是Share-Nothing的分布式数据库产品，支持分布式事务，以及完全透明等；

　　2.MySQL Cluster的索引数据必须基于内存，元数据也是7.2版本才推出基于列的模式允许存储在磁盘上，这个功能其实没啥意义，要是能做到基于行的模式依据冷热，那就完全不一样；

　　3.MySQL Cluster的业务场景限制，更大的优点也是最致命的缺点，比如跨节点的JOIN，所以一直在提升这方面的算法和数据同步，对网络环境要求太高；

　　4.MySQL Cluster同NoSQL产品比较，以及去做NoSQL产品的事情，是一种自我定位失败；

　　5.国内非常缺乏这方面的技术人才，也缺乏实战的业务场景，故必须先对这些研究透彻和丰富解决方案才可行，以及需要有这方面的第三方公司，毕竟甲骨文在国内是没有任何技术服务团队的

　　1.MySQL Cluster的技术复杂度太高，毕竟是Share-Nothing的分布式数据库产品，支持分布式事务，以及完全透明等；

　　2.MySQL Cluster的索引数据必须基于内存，元数据也是7.2版本才推出基于列的模式允许存储在磁盘上，这个功能其实没啥意义，要是能做到基于行的模式依据冷热，那就完全不一样；

　　3.MySQL Cluster的业务场景限制，更大的优点也是最致命的缺点，比如跨节点的JOIN，所以一直在提升这方面的算法和数据同步，对网络环境要求太高；

　　4.MySQL Cluster同NoSQL产品比较，以及去做NoSQL产品的事情，是一种自我定位失败；

　　5.国内非常缺乏这方面的技术人才，也缺乏实战的业务场景，故必须先对这些研究透彻和丰富解决方案才可行，以及需要有这方面的第三方公司，毕竟甲骨文在国内是没有任何技术服务团队的

1.MySQL Cluster的技术复杂度太高，毕竟是Share-Nothing的分布式数据库产品，支持分布式事务，以及完全透明等；

2.MySQL Cluster的索引数据必须基于内存，元数据也是7.2版本才推出基于列的模式允许存储在磁盘上，这个功能其实没啥意义，要是能做到基于行的模式依据冷热，那就完全不一样；

3.MySQL Cluster的业务场景限制，更大的优点也是最致命的缺点，比如跨节点的JOIN，所以一直在提升这方面的算法和数据同步，对网络环境要求太高；

oracle数据库经常会出现占用cpu100%的进程，然后系统就挂了，怎么找出引起这种故障的sql语句

在故障发生时，尝试用下面的语句抓取数据库引起故障的点。

/*********************************************************************************************/

在oracle中监控死锁

/*********************************************************************************************/

SELECT sn.username,

m.SID,

sn.SERIAL#,

m.TYPE,

DECODE(m.lmode,

0,

‘None’,

1,

‘Null’,

2,

‘Row Share’,

3,

‘Row Excl.’,

4,

‘Share’,

5,

‘S/Row Excl.’,

6,

‘Exclusive’,

lmode,

LTRIM(TO_CHAR(lmode, ‘990’))) lmode,

DECODE(m.request,

0,

‘None’,

1,

‘Null’,

2,

‘Row Share’,

3,

‘Row Excl.’,

4,

‘Share’,

5,

‘S/Row Excl.’,

6,

‘Exclusive’,

request,

LTRIM(TO_CHAR(m.request, ‘990’))) request,

m.id1,

m.id2

FROM v$session sn, v$lock m

WHERE (sn.SID = m.SID AND m.request != 0) –存在锁请求，即被阻塞

OR (sn.SID = m.SID –不存在锁请求，但是锁定的对象被其他会话请求锁定

AND m.request = 0 AND lmode != 4 AND

(id1, id2) IN (SELECT s.id1, s.id2

FROM v$lock s

WHERE request !=

AND s.id1 = m.id1

AND s.id2 = m.id2))

ORDER BY id1, id2, m.request;

/*********************************************************************************************/

定位引起oracle死锁的sql

/*********************************************************************************************/

select sql_text from v$sql where hash_value in

(select sql_hash_value from v$session where sid in

(select session_id from v$locked_object))

/*********************************************************************************************/

下面的SQL查询可以用于确定锁住数据库对象的锁：

/*********************************************************************************************/

select

c.owner,

c.object_name,

c.object_type,

b.sid,

b.serial#,

b.status,

b.osuser,

b.machine

from

v$locked_object a ,

v$session b,

dba_objects c

where

b.sid = a.session_id

and

a.object_id = c.object_id;

/*********************************************************************************************/

显示哪些会话被锁住

/*********************************************************************************************/

/* showlock.sql */

COLUMN o_name format a10

COLUMN lock_type format a20

COLUMN object_name format a15

SELECT RPAD (oracle_username, 10) o_name, session_id SID,

DECODE (locked_mode,

0, ‘None’,

1, ‘Null’,

2, ‘Row share’,

3, ‘Row Execlusive’,

4, ‘Share’,

5, ‘Share Row Exclusive’,

6, ‘Exclusive’

) lock_type,

object_name, xidusn, xidslot, xidsqn

FROM v$locked_object, all_objects

WHERE v$locked_object.object_id = all_objects.object_id;

/*********************************************************************************************/

显示所有的TM和TX锁

/*********************************************************************************************/

/* showalllock.sql */

SELECT SID, TYPE, id1, id2,

DECODE (lmode,

0, ‘None’,

1, ‘Null’,

2, ‘Row share’,

3, ‘Row Exclusive’,

4, ‘Share’,

5, ‘Share Row Exclusive’,

6, ‘Exclusive’

) lock_type,

request, ctime, BLOCK

FROM v$lock

WHERE TYPE IN (‘TX’, ‘TM’);

/*********************************************************************************************/

在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:

被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.

我们发现当一个session被kill掉以后，该session的paddr被修改，如果有多个session被kill，那么多个session

的paddr都被更改为相同的进程地址:

/*********************************************************************************************/

alter system kill session ‘sid,serial#’ ;

/*********************************************************************************************/

在oracle中kill掉的进程有时还需要等待pmon回滚数据库已经占有的资源

有时候我们需要使用下面的脚本找出那些已经在oracle中kill掉的进程，在操作系统中在kill一次

/*********************************************************************************************/

select p.addr from v$process p where pid 1

minus

select s.paddr from v$session s;

$ kill -9 &paddr

什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS两者的优势

NewSQL是对一类现代

关系型数据库

的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“

应用程序

逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。

在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对

海量数据

的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。

NoSQL的

拥趸

普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和

关系模型

，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它

数据模型

 (如 key/value，graphs 和Documents)。

两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。

在21世纪00年代末，市面上已经有许多供用户选择的

分布式数据库

产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。

一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到

中间件

时代，开发支持

分布式事务

的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。

NewSQL数据库设计针对的读写事务有以下特点：

1、耗时短。

2、使用索引查询，涉及少量数据。

3、重复度高，通常使用相同的查询语句和不同的查询参考。

也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的

数据库系统

确实都有这样的特点。

关于share nothing数据库瓶颈的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。