nosql

最近与同行科技交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。 本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。 NewSQL数据库先进在哪儿？ 首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。 NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：

qps多少才算高并发 首先是无状态前端机器不足以承载请求流量，需要进行水平扩展，一般QPS是千级。 然后是关系型数据库无法承载读取或写入峰值，需要数据库横向扩展或引入nosql，一般是千到万级。 之后是单机nosql无法承载，需要nosql横向扩展，一般是十万到百万QPS。 最后是难以单纯横向扩展nosql，比如微博就引入多级缓存架构，这种架构一般可以应对百万到千万对nosql的访问QPS。 当然面向用户的接口请求一般到不了这个量级，QPS递增大多是由于读放大造成的压力，单也属于高并发架构考虑的范畴。 PV和QPS 比如微博每天1亿多pv的系统一般也就1500QPS，5000QPS峰值。 比如有人说： 2C4G机器单机一般1000QPS。 8C8G机器单机可承受7000QPS。 php怎么处理高并发问题？ 通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量，用户高聚集的业务场景中。 处理高并发的业务逻辑是: 前端:异步请求+资源静态化+cdn 后端:请求队列+轮询分发+负载均衡+共享缓存 数据层:redis缓存+数据分表+写队列 存储:raid阵列+热备 网络:dns轮询+DDOS攻击防护 php处理高并发问题的方法 1、应用和静态资源分离 将静态资源（js，css，图片等）放到专门的服务器中。 2、页面缓存

“灵魂拷问： 解决数据库读写瓶颈有哪些解决方案呢? 这些方案解决了什么问题呢? 这些方案有那些优势和劣势呢? 一个可以抵抗高并发流量系统的背后必定有一个高性能的数据库集群，就像每一个成功的男人背后总有一个强势的女人一样。数据库集群在部署模式上属于分布式，但是CAP原则却不适用于分布式数据库。 分库分表作为一种普遍的解决方案，几乎已经成为面试者吹水的利剑，却很少有人在意它所带来的副作用。其实分库分表是利用了分治的思路来解决数据库的瓶颈问题，这种方案同时解决了并发读和并发写的瓶颈，利用数据分片的方式，以堆积硬件的方式来抵抗了高流量的冲击，当然带来了某些业务需要跨库查询，跨表join等问题，不过这些问题总能以别的解决方案来应对。 数据库读写分离是解决数据库性能瓶颈的另外一个方案，和分库分表方案相比较，他们有着本质的区别。分库分表会把数据分散在多个库表中，然后利用数据分片的规则来读取和写入数据，而读写分离是利用“冗余”的方式来应对大流量的冲击。 读写分离原理 读写分离的基本原理是将数据读写分散到不同的数据库节点上，写操作一般只发生在主节点，可以接受少量延迟的读操作发生在从节点上 image 至于读写分离的实现方式： 多台数据库服务器组件成集群，并配置主从关系 主节点负责读写操作，从节点只负责读操作 主节点通过数据复制机制，把数据从主节点同步到所有的从节点

润乾报表、帆软报表、Smartbi、永洪 BI、亿信 BI 这几款国内产品都把中国复杂报表作为宣传点。我们以常见的多源分片为报表为用例，来对比评测这些产品的处理能力（由于时间和知识限制，个别很偏的功能点可能会有遗漏）。 内容比较长，如果不想看细节，可以直接跳到最后看结论。 用例说明 报表式样 数据结构 [订单表] 主数据存储在订单表中，该表通过雇员 ID 和销售员表关联，通过产品 ID 和产品表关联。 [销售员表] 销售员表中存储职务、姓名，报表左下角统计数据时按照职务和姓名统计，该表通过雇员 ID 和订单表关联。 [产品表] 产品表中包含类别 ID 和产品 ID，并且是一对多关系，报表中需要按照类别分组，也就是要按该类别下多个产品的信息汇总。通过产品 ID 和订单表关联 [类别表] 这是一个中文字典表，通过它将类别 ID 映射成中文名称。 假定数据都来自数据库，可用 SQL 语句取出。 报表特点分析 1、 这是一个典型的多源分片报表，报表可以分成左上、右上、左下、右下四片区域，每片数据来自不同数据表（甚至可能不同数据库），需要实现多个数据集之间的关联。 2、 对字段数据的处理，数据库中存储的是订购日期，报表中需要按照年、月分组统计，需要根据日期解析出年、月，汇总区域是金额，数据库中存储的是单价、数量，需要对字段进行相乘操作。 3、 上表头中的产品类别需要按确定的次序排列

要回答这个问题，首先要明确啥程度算“零编码”？ 以 Excel 为例，如果把写 Excel 公式（包括复杂一些的）看做零编码；而把写 Excel VBA 看做编码的话， 报表开发是可以零编码的！ 但是，这有个前提：在数据（集）准备好的情况下才可以零编码！ 为什么这么说？ 我们知道报表开发主要分两个阶段： 第一阶段是为报表准备数据，也就是把原始数据通过 SQL/ 存储过程加工成数据集； 第二阶段是使用已准备的数据编写表达式做报表呈现。在报表工具提供的 IDE 里可视化地画出报表样式，然后再填入一些把数据和单元格绑定的表达式就可以完成报表呈现了，虽然表达式可能比较复杂，但相对硬编码要简单得多（Excel 公式和 VBA 的关系）。所以说这个阶段是能做到“零编码”的。 那报表数据准备怎么办？ 很遗憾，这个阶段没法零编码，一直以来只能硬编码，想想我们报表里写的嵌套 SQL、存储过程、JAVA 程序就知道了。为什么报表工具发展这么多年报表呈现已经完全工具化而报表数据准备的手段还这样原始呢？因为这个阶段太复杂了，不仅涉及计算逻辑的算法实现，还涉及报表性能（要知道大部分报表性能问题都是数据准备阶段引起的）。 那报表数据准备是不是没办法了呢？ 虽然不能做到零编码，但可以朝着简单化的方向努力，将数据准备阶段也工具化，这样可以使用工具提供的便利来简化报表数据准备阶段的工作，从而进一步简化报表的开发。

企业上云是比较热门的话题也是趋势，越来越多的企业放弃传统IDC选择上云，新手站长网告诉你企业为什么要上云？企业上云的好处和优势有哪些： 企业为什么要上云？ 企业上云也是企业集成发展的趋势，国内外很多企业相继投入了云的怀抱，诸如飞利浦关闭中国数据中心整体搬迁至阿里云。新手站长网来说说企业为什么要上云？ 一：降低企业技术开发成本 企业上云能够降低企业的技术开发成本，大多数中小企业并没有庞大的IT预算开支，处理技术采购方面问题的精力也相当有限。我们需要将有限的资金用到真正需要的方面。这也中小企业的共同点。使用云计算服务比购买一般的物理硬件要便宜得多，那么中小企业就可以摆脱很多不必要的开支。 二：丰富的产品线一站式上云 云计算提供的不仅仅是云服务器的计算服务，还有更多的周边云产品。以阿里云为例，ECS云服务器是企业上云的基本单元，如果想用户的应用场景需要更高的容灾能力，您可以将ECS部署在不同的可用区；如果想要将数据库分离出去，您可以选择云数据库，云数据库从RDS到NoSQL云数据库版本丰富；您可以使用对象存储OSS，搭配阿里云CDN，提高网络速度；如果您被同行或他人攻击，您还可以接入云盾安全类产品等等。新手站长网就不多赘述，有问题可以参考阿里云官方文档 三：企业云计算的灵活性 “云”带给了更大的灵活性和移动性，使用云，可以让企业在一台机器上开始工作并且在另外一台机器上完成它

图数据库基本概念 图形数据库是 NoSQL 数据库的一种类型，它应用图形理论存储实体之间的关系信息。最常见的例子，就是社会网络中人与人之间的关系。关系型数据库用于存储关系型数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷。Google的图形计算系统名为 Pregel。 目前主流的图数据库有：Neo4j，FlockDB，GraphDB，InfiniteGraph，Titan，JanusGraph，Pregel等。 下面介绍几个图数据库中的几个基本概念： RDF ：RDF(Resource Description Framework)，即资源描述框架，其本质是一个数据模型（Data Model）。它提供了一个统一的标准，用于描述实体/资源。简单来说，就是表示事物的一种方法和手段。RDF 形式上表示为 SPO 三元组，有时候也称为一条语句（statement），知识图谱中我们也称其为一条知识。RDF 由节点和边组成，节点表示实体/资源、属性，边则表示了实体和实体之间的关系以及实体和属性的关系。 RDF 没有外键和主键，它使用的是 URI ，万维网的标准引用格式。通过 URI，一个三元组库可以直接链接到任何三元组库的其他任何数据。 属性图 ：属性图是由 顶点（Vertex），边（Edge），标签（Lable），关系类型 还有 属性（Property

女主宣言 1998年，加州大学的计算机科学家 Eric Brewer 提出分布式系统有三个指标，即CAP，而这三个指标不能同时做到。今天小编就为大家分享分布式相关理论，希望能对大家有所帮助。 PS：丰富的一线技术、多元化的表现形式，尽在“ 360云计算 ”，点关注哦！ 1 前言 CAP、BASE、最终一致性是NoSQL数据库的三大理论基石。 2 CAP理论 CAP理论是一个非常知名的理论。在进行分布式系统设计的时候，我们一定会涉及到三个方面的性质。哪三个方面呢？ C : 一致性（Consistency）。指任何一个读操作总能读到之前完成的写操作的结果。也就是说在我们分布式环境中，多点的数据必须是一致的。所有节点在同一时间要具有相同的数据。 A : 可用性（Availability）。指快速的获取数据，可以在确定时间内返回操作结果，保证每个请求不管成功还是失败都有响应。 P : 分区容忍性（Partition tolerance）。指当网络出现分区的情况（即系统中的一部分节点无法和其他节点进行通信）分离的系统也能够正常运行。即：系统中任意信息丢失不会影响系统正常运作。 我们理想的目标是：希望设计一个分布式系统能够同时满足CAP。但是理论和实践都证明，这是不可能的，鱼和熊掌不可兼得。只能三者取其二，必须要牺牲一个性质，来成就另外两个性质。 CAP Theorem