NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
大数据时代，企业对于DBA也提出更高的需求。同时，NoSQL作为近几年新崛起的一门技术，也受到越来越多的关注。本文分享两大方向内容：一、公司在KV存储上的架构演进以及运维需要解决的问题；二、对NoSQ
大数据时代，企业对于DBA也提出更高的需求。同时，NoSQL作为近几年新崛起的一门技术，也受到越来越多的关注。本文将基于个推SRA孟显耀先生所负责的DBA工作，和大数据运维相关经验，分享两大方向内容：
李飞飞，现任阿里巴巴集团副总裁、高级研究员，阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。
包括静态数据使用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。
关于昨天 Spanner 的文字，有人问 NewSQL 为什么会起名为 New，Spanner 的应用场景又是怎样的？那么这篇就顺着大数据的历史继续聊。
互联网系统架构中，承受着最大出力压力，最难以被伸缩的，就是数据存储部分，原因主要有两方面，一方面，数据存储需要使用硬盘，而硬盘的处理速度要比其他几种计算资源都要慢，比如说CPU、内存等；数据是一个公司最重要的资产，公司需要保证数据的高可用以及一致性，非功能性约束也要更高一些。
高并发经常会发生在有大活跃用户量和用户高聚集的业务场景中，如：秒杀活动、定时领取红包等。
1.NoSQL的诞生原因 随着互联网快速发展，各种类型的应用层出不穷，所以导致在这个云计算的时代，对技术提出了更多的需求，主要体现在下面这四个方面： 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度; 原因：当数据量达到一定规模时，由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重; 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量; 原因：有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的
hadoop是 Doug Cutting 在 Lucene 之后的一个项目 主要用于 计算 是一个 开源，可靠，可扩展 的分布式计算框架 主要有
差不多十年前，随着功能机的淘汰和智能机的普及，互联网开始进入移动互联网时代，最具代表性的产品就是微博、微信，以及后来的今日头条、快手等。这些移动互联网时代的新产品在过去几年间借着智能手机的风高速成长。
JDNoSQL平台是一个分布式面向列的KeyValue毫秒级存储服务，存储结构化数据和非机构化数据，支持随机读写与更新，灵活的动态列机制，架构上支持水平扩容，提供高并发、低延迟、高可用、强一致数据库服务，可满足各种业务场景。完善的平台支持，支持业务自助化建表，查看监控，在线DDL等。
关系数据库历史悠久，可以找到靠谱的DBA，保证关系数据库稳定性，安全性，完整性和性能，同时可以保证监控和分析关系数据库的瓶颈及设计的合理性。成熟的关系数据库有着自己完善的生态圈，用于保证高可用，数据备份，性能检测分析等成熟的工具。
1961年通用电气公司的Charles Bachman 成功地开发出世界上第一个网状DBMS也是第一个数据库管理系统——集成数据存储（Integrated Data Store，IDS） 层次型DBMS是紧随网状型数据库而出现的。最著名最典型的层次数据库系统是IBM 公司在1968 年开发的IMS （Information Management System）网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立性和抽象级别上仍有很大欠缺。
高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。
◆ 分表分库 上文讲到，查询分离的方案存在三大不足，其中一个就是：当主数据量越来越大时，写操作会越来越缓慢。这个问题该如何解决呢？可以考虑分表分库。 这里先介绍一下真实的业务场景，而后依次介绍拆分存储时如何进行技术选型、分表分库的实现思路是什么，以及分表分库存在哪些不足。 接下来进入业务场景介绍。 ◆ 业务场景：亿级订单数据如何实现快速读写 这次项目的对象是电商系统。该系统中大数据量的实体有两个：用户和订单。每个实体涵盖的数据量见表3-1。 表3-1 数据量 某天，领导召集IT部门人员开会，说：“根据市场
遇到1000万数据表 最近遇到一个问题，就是单表数据过1000万的存储及查询问题。举个例子：1000万的数据存在一个表中，字段4-5个样子，日常 开发中难免要做过滤、排序、分页。如果把这几个放在一起即要过滤又要排序，还要分页那么数据量大一些就会发现特别慢。 10多年前刚入行时就听许多的人讨论分页，说什么1000万大表分页存储过程啥的。我之后一直工作中也没怎么遇到大数据量的开发工作，也真是惭愧啊，现在算是补补课吧。 1000万数据分个页吧 常用的数据库产品对分页都是有一些支持的，SQL语句肯定是OK的，同样的
上文讲到，查询分离的方案存在三大不足，其中一个就是：当主数据量越来越大时，写操作会越来越缓慢。这个问题该如何解决呢？可以考虑分表分库。
本文由腾讯云+社区自动同步，原文地址 https://stackoverflow.club/article/tag_category_for_blogger/
前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服
差不多十年前，随着功能机的淘汰和智能机的普及，互联网开始进入移动互联网时代，最具代表性的产品就是微博、微信，以及后来的今日头条、快手等。这些移动化联网时代的新产品在过去几年间借着智能手机的风高速成长。
为什么使用MyCat 如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种 操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现 暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上 的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安 全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。如何使用关系型数据库解决 海量存储的问题呢？此时就需要做数据库集群，为了提高查询性能将一个数据库的数据分散到不同的数据库中 存储，为应对此问题就出现了——MyCat
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
数据库切分概述 数据切分概述 OLTP和OLAP 在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类 型：联机事务处理（OLTP）和联机分析处理（OLAP）。 联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间 内给出处理结果。 联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强 决策分析功能。 对于两者的主要区别可以
责编：乐乐 | 链接：my.oschina.net/u/3772106/blog/1793561
说到人工智能技术，首先会联想到深度学习、机器学习技术；谈到人工智能应用，很可能会马上想起语音助理、自动驾驶等等。实际上，人工智能要在行业中得到应用的先决条件是首先要对行业建立起认知，只有理解了行业和场景，才能真正智能化。简单的说，就是要建立行业知识图谱，才能给行业AI方案。
数据库的七种武器，是我在工作维护和接触到的七种常用数据库，包括4种常用的关系型数据库，3种常用nosql数据库。
在数据库圈子，大家都知道2016年 Uber 干出来一件大事件，把 PostgreSQL 切换到了 MySQL，当时社区里一阵喧哗。这里想带着大家思考一下选择的背后。
朱建平，TEG/云架构平台部/块与表格存储中心副总监。08年加入腾讯后，承担过对象存储、键值存储，先后负责过KV存储-TSSD、对象存储-TFS等多个存储平台。 NoSQL 技术和行业背景 NoSQL 是对不同于传统关系型数据库的一个统称，提出 NoSQL 的初衷是针对某些场景简化关系型数据库的设计，更容易水平扩展存储和计算，更侧重于实现高并发、高可用和高伸缩性。 NoSQL vs 关系型数据库 其实早几年大家看两者的区别是清晰的，关系型数据库就是用 SQL 语句操作，具有行列结构和预定义 scheme 的
像MongoDB, Cassandra, HBase, DynamoDB, 和 Riak这些NoSQL缺乏传统的原子事务机制，所谓原子事务机制是可以保证一系列写操作要么全部完成，要么全部不会完成，不会发生只完成一系列中一两个写操作；因为数据库不提供这种事务机制支持，开发者需要自己编写代码来确保一系列写操作的事务机制，比较复杂和测试。 这些NoSQL数据库不提供事务机制原因在于其分布式特点，一系列写操作中访问的数据可能位于不同的分区服务器，这样的事务就变成分布式事务，在分布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操作失败。 这种协调是昂贵的，会增加延迟时间，关键问题是，当协调没有完成时，其他操作是不能读取事务中写操作结果的，这是因为事务的all-or-nothing原理导致，万一协调过程发现某个写操作不能完成，那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重影响，不只是吞吐量还包括延迟时间，这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。 MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务，这是因为所有信息都和一个键key有关，这个键是存储在单个服务器上，这样基于单键的事务不会带来复杂的分布式协调。 那么看来扩展性性能和分布式事务是一对矛盾，总要有取舍？实际上是不完全是，现在完全有可能提供高扩展的性能同时提供分布式原子事务。 FIT是这样一个在分布式系统提供原子事务的策略，在fairness公平性, isolation隔离性, 和throughput吞吐量（简称FIT）可以权衡。 一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个，公平是事务之间不会相互影响造成延迟；隔离性提供一种幻觉好像整个数据库只有它自己一个事务，隔离性保证当任何同时发生的事务发生冲突时，能够保证彼此能看到彼此的写操作结果，因此减轻了程序员为避免事务读写冲突的强逻辑推理要求；吞吐量是指每单元时间数据库能够并发处理多少事务。 FIT是如下进行权衡： 1.保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量 2.保证公平性fairness和吞吐量, 牺牲隔离性isolation 3.保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness. 牺牲公平性：放弃公平性，数据库能有更多机会降低分布式事务的成本，主要成本是分布式协调带来的，也就是说，不需要在每个事务过程内对每个机器都依次确认事务完成，这样排队式的确认commit事务是很浪费时间的，放弃公平性，意味着可以在事务外面进行协调，这样就只是增加了协调时间，不会增加互相冲突事务因为彼此冲突而不能运行所耽搁的时间，当系统不需要公平性时，需要根据事务的优先级或延迟等标准进行指定先后执行顺序，这样就能够获得很好的吞吐量。 G-Store是一种放弃公平性的 Isolation-Throughput 的分布式key-value存储，支持多键事务(multi-key transactions)，MongoDB 和 HBase在键key在同样分区上也支持多键事务，但是不支持跨分区的事务。 总之：传统分布式事务性能不佳的原因是确保原子性（分布式协调）和隔离性同时重叠，创建一个高吞吐量分布式事务的关键是分离这两种关注，这种分离原子性和隔离性的视角将导致两种类型的系统，第一种选择是弱隔离性能让冲突事务并行执行和确认提交；第二个选择重新排序原子性和隔离性机制保证它们不会某个时间重叠，这是一种放弃公平的事务执行，所谓放弃公平就是不再同时照顾原子性和隔离性了，有所倾斜，放弃高标准道德要求就会带来高自由高效率。
Michael Kopp拥有十年以上C++、Java/JEE的架构及开发经验，现Compuware技术策略师，专攻大规模产品部署的架构和性能。 以下为译文： 传统企业数据库供应商经常提出NoSQL缺乏专业的监视和管理工具。它们的论点是：企业应用程序需要对数据库进行精细的调优和监视以保证性能和运转的稳定。NoSQL供应商的观点则是：这种程度的缺乏还并不能在解决方案上帮助到RDBMS。许多NoSQL供应商也尝试从它们提供的监视和管理软件等级上进行区分，比如：Cassandra、MongoDB、Hbase等等。当
以前使用对数据库进行操作来提高性能(例如：分库分表，读写分离等等)。现在使用NoSQL解决大量数据库的IO请求
大数据生态圈中有很多优秀的组件，可谓琳琅满目，按组件类别可分为存储引擎、计算引擎，消息引擎，搜索引擎等；按应用场景可分为在线分析处理OLAP型，在线事务处理OLTP型，以及混合事务与分析处理HTAP型等。有些组件主要存储日志数据或者只允许追加记录，有些组件可更好的支持CDC或者upsert数据。有些组件是为离线分析或批处理而生，有些则更擅长实时计算或流处理。本文整理了几个笔者认为非常重要且仍然主流的核心组件，供参考。
NoSQL并非字面的“不是SQL”或者“非SQL”，而是NoSQL=Not Only SQL，即“不仅仅是SQL”，是对不同于传统的关系型数据库的数据库管理系统的统称。
让我们聊聊微服务的老大难：分布式事务。这是个已经被无数次讨论的问题，网上文章多如牛毛。本文从业务底层视角出发，探讨分布式事务究竟难在何处，以及务实的解决之路走向何方，再加一根牛毛... 不过希望本文是比较不一样的视角，能给到读者不同的启发。
首先数据库是一个软件，最基础的功能就是数据存储和数据查询。对于数据的处理方式如果通泛来说是分为读和写，所以分布式方案的很多场景其实也是围绕着这两个维度来做的。
我们知道，为了应对不断增长的数据，我们对数据进行切分，存储在不同的数据库里，本文提到的数据库在非特定指明的情况下，均指一个逻辑数据库（是一组数据库，比如Master-Slave），而非单一各个物理数据库。
导语 | 让我们聊聊微服务的老大难：分布式事务。这是个已经被无数次讨论的问题，网上文章多如牛毛。本文从业务底层视角出发，探讨分布式事务究竟难在何处，以及务实的解决之路走向何方，再加一根牛毛……不过希望本文是比较不一样的视角，能给到读者不同的启发。 在微服务架构流行的背景下，分布式事务的文章多如牛毛，虽然很多将事务一致性与副本一致性混为一谈，也仍不可否认其中相当一部分文章、开源代码，也还是不错的。 然而当你跃跃欲试，期待将业界所谓成熟方案落地，可能很快就会发现现实的骨感 —— 对于大量互联网业务，尤其是在大并
由于距离2022年系统架构师考试还有几天，我紧急把本次重点押题的内容准备一份，希望可以帮助到需要的同学，希望本次考试可以成功上岸
面试的时候，经常会被面试官问到数据库优化方面的知识点。今天来总结一下数据库优化应该经过几个阶段，我觉得这样回答是一个比较优的答案。
内容来源：2017 年 11 月 18 日，百度数据库架构师严龙在“第七届数据技术嘉年华”进行《百度NewSQL-CockroachDB》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方、演讲者以及微信公众号——CockroachDB（微信id：CockroachDB）审阅授权发布。 阅读字数：3621 | 10分钟阅读 摘要 本次交流主要包括开源 NewSQL 数据库 Cockroach DB 关键技术分析以及 Cockroach DB 在百度内部的应用和实践。 嘉宾
从 Google 的 BigTable 开始，一系列可以进行海量数据存储与访问的数据库被设计出来，NoSQL 这一概念被提了出来。
作者：薛菲 审稿：张远园 Aileen 写在前面 这篇是小白学数据系列的NoSQL数据库的第二篇：进阶篇。数据分析方向的从业人员可以从中获取数据仓库软件市场的现状和分析，以增加自己的知识储备，为可能的技术转型打基础。而工程师可以找到关于NoSQL主流产品的分析介绍以及选择数据库的一些准则。NoSQL不是万能药，采用技术最好不要跟风，选择适合自己数据和应用的才是最好的哟~没有看过NoSQL基础篇的读者可以在文末的历史文章回顾中找到。 小白问：上次问了NoSQL，SQL的区别，好像有点忘了，我们可以温故而知
几年之前，曾不自量力的想要写一个兼容RDBMS和NoSQL的数据库，结果仅实现了一个Raft协议，写了一棵BTree，就放弃了。使用Golang写这个算是比较简单的了，但过程难以言诉，有点蚂蚁撼大树了。
很多刚入门的小伙伴可能会有疑惑，到底什么是NoSQL，很多人刚开始学习的时候很容易对NoSQL产生误会，其实NoSQL=Not Only SQL,它指的是“不仅仅是SQL”，那么它具体指代的是什么呢，它有哪些方面的特征呢，今天就和大家好好的聊一聊NoSQL。
Source What is the Serverless architecture? - Java Stack Flow Technology is rapidly growing day by d
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
