用户您好!请先登录!

分类目录数据库

SQL的反模式用法

01、LIMIT语句

分页查询是最常用的场景之一,但也通常也是最容易出问题的地方。比如对于下面简单的语句,一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引,性能迅速提升。

好吧,可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时,程序员仍然会抱怨:我只取10条记录为什么还是慢?

要知道数据库也并不知道第1000000条记录从什么地方开始,即使有索引也需要从头计算一次。出现这种性能问题,多数情形下是程序员偷懒了。

阅读更多

MySQL事务及ACID特性的实现原理

事务是 MySQL 等关系型数据库区别于 NoSQL 的重要方面,是保证数据一致性的重要手段。

MySQL 事务基础概念

事务(Transaction)是访问和更新数据库的程序执行单元;事务中可能包含一个或多个 sql 语句,这些语句要么都执行,要么都不执行。

作为一个关系型数据库,MySQL 支持事务,本文介绍基于 MySQL 5.6。首先回顾一下 MySQL 事务的基础知识。

阅读更多

NoSQL已过时

作者:Rick Negrin是MemSQL的产品管理团队负责人,他在微软工作过12年,曾是SQL Server团队的成员。

NoSQL 已死:我们不需要他了

是时候承认我们早就知道的一个事实了:NoSQL 是并不适合许多现代应用使用场景的工具,是我们该翻篇的时候了。

阅读更多

数据库索引那点事

一、引言

对数据库索引的关注从未淡出我们的讨论,那么数据库索引是什么样的?聚集索引与非聚集索引有什么不同?

希望本文对各位同仁有一定的帮助。有不少存疑的地方,诚心希望各位不吝赐教指正,共同进步。

二、B-Tree

我们常见的数据库系统,其索引使用的数据结构多是B-Tree或者B+Tree。

例如,MsSql使用的是B+Tree,Oracle及Sysbase使用的是B-Tree。所以在最开始,简单地介绍一下B-Tree。

阅读更多

数据库异地多活解决方案

异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种,与传统的灾备设计的最主要区别在于“多活”,即所有站点都是同时在对外提供服务的。

以一个简单的业务单元的IT系统为例,整个IT系统的异地多活方案如下图所示。

数据库异地多活解决方案「转」

整个方案将各站点分为:分流量层、应用层和数据层。

阅读更多

CouchDB-技术概述

1. 文档存储

一个承载着CouchDB服务器主机的数据库,以文档方式存储。每个文档在数据库中都有唯一的名称,CouchDB提供一个RESTful HTTP API来读取和更新(添加、编辑、删除)数据库文档。

文档是CouchDB中的主要数据单元,由任意数量的字段和附件组成。文档还包括数据库系统维护的元数据。文档字段是唯一命名的,并且包含不同类型的值(文本、数字、布尔值、列表等),并且没有对文本大小或元素数量的设置限制。

CouchDB文档更新模型是无锁且乐观的。文档编辑是通过客户机应用程序加载文档、应用更改并将它们保存回数据库来完成的。如果另一个编辑相同文档的客户端首先保存其更改,则客户端在保存时将获得编辑冲突错误。要解决更新冲突,可以打开最新的文档版本,重新应用编辑并再次尝试更新。

阅读更多

MongoDB和Cassandra的对比

MongoDB和Cassandra都属于NoSQL数据库系列,它们也恰好都是开源,但是,它们的相似之处仅此而已。

MongoDB和Cassandra之间的相似之处

在深入探讨MongoDB和Cassandra的不同之处之前,让我们先看看它们的相似之处。

显然,它们都是数据库。更重要的是,它们都是NoSQL数据库。NoSQL是一种数据库架构类型,其中数据主要以相对非结构化的方式存储。与更传统的SQL式数据库相比,NoSQL可以更有效地存储大量非结构化数据,企业在大数据操作中通常会涉及非结构化数据。

阅读更多

MongoDB、Cassandra和 Mysql的对比

1. 为什么是Nosql?

1.1. Nosql在大数据处理相对于关系型数据库具有优势

  • 低延迟的读写速度: 大量数据的写入和读取可达 Wops/sec的速率
  • 海量的数据和流量:可以支持高效的查询,应对高并发请求。
  • 大规模集群的管理:分布式应用能更简单的部署和管理;
  • 关系型数据库由于存在类似Join这样多表查询机制,使得数据库在扩展方面很艰难;
  • 关系型数据库读写慢:这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等的并发问题,所以导致其读写速度下滑非常严重;

阅读更多

Kudu与HBase的简要分析与对比

Cloudera在2016年发布了新型的分布式存储系统——kudu,kudu目前也是Apache下面的开源项目。Hadoop生态圈中的技术繁多,HDFS作为底层数据存储的地位一直很牢固。而HBase作为Google BigTable的开源产品,一直也是Hadoop生态圈中的核心组件,其数据存储的底层采用了HDFS,主要解决的是在超大数据集场景下的随机读写和更新的问题。

Kudu的设计有参考HBase的结构,也能够实现HBase擅长的快速的随机读写、更新功能。那么同为分布式存储系统,HBase和Kudu二者有何差异?两者的定位是否相同?我们通过分析HBase与Kudu整体结构和存储结构等方面对两者的差异进行比较。

阅读更多

WiredTiger存储引擎原理

Mongodb-3.2已经WiredTiger设置为了默认的存储引擎,最近通过阅读wiredtiger源代码(在不了解其内部实现的情况下,读代码难度相当大,代码量太大,强烈建议官方多出些介绍文章),理清了wiredtiger的大致原理,并简单总结,不保证内容都是正确的,如有问题请指出,欢迎讨论交流。

按照Mongodb默认的配置,WiredTiger的写操作会先写入Cache,并持久化到WAL(Write ahead log),每60s或log文件达到2GB时会做一次Checkpoint,将当前的数据持久化,产生一个新的快照。Wiredtiger连接初始化时,首先将数据恢复至最新的快照状态,然后根据WAL恢复数据,以保证存储可靠性。
0102-zyd-MongoDB WiredTiger存储引擎实现原理-1

阅读更多

阿里基于HBase的大数据引擎Lindorm

注:Lindorm是阿里内部HBase分支的别称,在阿里云上对外售卖的版本叫做HBase增强版,之后文中出现的HBase增强版和Lindorm都指同一个产品。

2019年以来,Lindorm已经服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个BU,在今年的双十一中,Lindorm峰值请求达到了7.5亿次每秒,天吞吐22.9万亿次,平均响应时间低于3ms,整体存储的数据量达到了数百PB。这些数字的背后,凝聚了HBase&Lindorm团队多年以来的汗水和心血。

Lindorm脱胎于HBase,是团队多年以来承载数百PB数据,亿级请求量,上千个业务后,在面对规模成本压力,以及HBase自身缺陷下,全面重构和引擎升级的全新产品。相比HBase,Lindorm无论是性能,功能还是可用性上,都有了巨大飞跃。本文将从功能、可用性、性能成本、服务生态等维度介绍Lindorm的核心能力与业务表现,最后分享部分我们正在进行中的一些项目。

阅读更多

GridDB: The Fastest Open Source Time Serials Database for IoT and Big Data

Practical Introduction to Time Series Databases and Time Series Data

1. What is Time Series data?

Time series data is a series of values ​​where the time information (timestamp) corresponds to data recorded or an event that happened at that point in time. The data can have both regular and fluctuating intervals. For example, temperature recordings would be recorded at a set time, every minute or hour, while a stock price would be recorded every time a trade is completed.

Time Series data is usually a log or “append-only”, records are rarely updated except upon deletion when they expire. You wouldn’t update values in your web server logs and the same holds true for most Time Series data collections.

阅读更多

京东JDTX:强一致性、高性能的分布式事务中间件

导读:在分布式数据库、云原生数据库、NewSQL 等名词在数据库领域层出不穷的当今,变革——在这个相对稳定的领域已愈加不可避免。相比于完全革新,渐进式增强的方案在拥有厚重沉淀的行业则更受青睐。

同所有分布式领域的解决方案相同,分而治之的透明化数据分片方案,是新一代数据库解决海量数据的核心理念。水平拆分使得分布式事务的重要性,较之垂直拆分的业务系统进一步提升。另外,弹性扩(缩)容、HTAP 等概念也是新一代数据库的关注重点。京东数科开源的 Apache ShardingSphere 在数据分片方面已逐渐成熟,在此场景之上开发的分布式事务中间件 JDTX 与之共同组成了分布式数据库的内核拼图。

JDTX 是由京东数科的数据研发团队倾力打造的分布式事务中间件。本次分享是 JDTX 首次公开出现在大众视野面前,分享内容涵盖 JDTX 的核心设计理念及相关的技术实现难点,希望能为打造分布式事务解决方案的团队提供一些思路。

阅读更多

分布式事务原理及实现方式

一个复杂的系统往往都是从一个小而简的系统发展衍化而来,为了满足日益增长的业务需求,不断的增加系统的复杂度,从单体架构逐步发展为分布式架构,而分布式系统架构的设计主要关注:高性能,高可用,高拓展,俗称的“三高”。

分布式事务(分布式系统中数据一致性问题)

高可用是指系统无中断的执行功能的能了,代表了系统的可用程度,是进行系统设计时必须要遵守的准则之一。

而高可用的实现方案,无外乎就是冗余,就存储的高可用而言,问题不在于如何进行数据备份,而在于如何规避数据不一致对业务造成的影响。

对于分布式系统而言,要保证分布式系统中的数据一致性就需要一种方案,可以保证数据在子系统中始终保持一致,避免业务出现问题,这种实现方案就叫做分布式事务,要么一起成功,要么一起失败,必须是一个整体性的事务。

阅读更多

KeyDB: Low TCO Redis™ Compatible Key Value Store

What is KeyDB?

KeyDB is an in-memory, high performance database with support for numerous data types, on-disk persistence and high availability. Compatible with Redis™ API and protocols, KeyDB is a drop-in replacement for your existing Redis™ deployments with numerous enhancements, higher performance, and lower Total Cost of Ownership (TCO).

Designed for use as both a cache as well as use as a primary database, KeyDB is a fast and versatile NOSQL database useful in many applications. Its low resource requirements and high-speed mean fewer instances to manage and much lower costs. KeyDB looks to fully utilize the hardware provided to your instances enabling a higher throughput and efficiency.

阅读更多

Youtube开源的高性能水平扩展MySQL平台

一、什么是Vitess?

vitness.jpg

Vitess是用于部署,扩展和管理MySQL实例的大型群集的数据库解决方案。它在架构上可以像在专用硬件上一样有效地在公共或私有云架构中运行。它结合了NoSQL数据库的可伸缩性,并扩展了许多重要的MySQL功能。Vitess可以帮助我们解决以下问题:

  1. 通过允许您对MySQL数据库进行分片来扩展规模,同时将应用程序更改降至最低。
  2. 从裸机迁移到私有云或公共云。
  3. 部署和管理大量MySQL实例。

Vitess包括使用本机查询协议的兼容JDBC和Go数据库驱动程序。另外,它实现了MySQL服务器协议,该协议实际上与任何其他语言兼容。

阅读更多

MySQL与PostgreSQL的选择

如果打算为项目选择一款免费、开源的数据库,那么你可能会在MySQL与PostgreSQL之间犹豫不定。

MySQL与PostgreSQL都是免费、开源、强大、且功能丰富的数据库。你主要的问题可能是:哪一个才是最好的开源数据库?MySQL还是PostgreSQL呢?该选择哪个开源数据库呢?

在选择数据库时,你所做的是个长期的决策,因为后面如果再改变决定将是非常困难且代价高昂的,你希望一开始就选择正确。

两个流行的开源数据库MySQL与PostgreSQL常常成为最后要选择的产品,本文对这两个数据库的高层次概览将会有助于你选择最适合自己需要的。

阅读更多

GraphQL 的工具库

GraphQL 是 Facebook 内部从 2012 年开始开发的项目,于 2015 年公开发布。2018 年 11 月 7 日,GraphQL 的控制权被移交给由 Linux 基金会托管的 GraphQL 基金会。随后 GraphQL 日益普及,一个富有活力的生态系统也随之迅速成长。

GraphQL 本质上是“API 的查询语言,以及使用你为数据定义的类型系统执行查询的服务端运行时”。它不依赖任何数据库或存储,而是由你的代码和数据来支持。GraphQL 查询是发送到运行时的字符串,它向客户端返回 JSON。

这种简单有效的设计催生了一个充满活力生态系统,社区有大批关于它的内容、演讲和指南,当然还有一系列开源工具、客户端、编辑器和库,增强并完善实践中的 GraphQL 工作流程。

这里收集了一些最出色的 GraphQL 工具和库,内容涵盖客户端库、IDE 及好用的集成。

1. Apollo 服务器和客户端

APOLLO 平台是 GraphQL 的一个实现,帮助用户管理从云到 UI 的各类数据。它可以渐进引入,可以在包括 REST API 和数据库在内的现有服务上另起一层运行。

阅读更多

微服务分布式事务中的Saga模式

该文是基于《微服务模式》作者Chris Richardson的QCONSF 2017会议上的PPT文章(这里)和其 Eventuate Tram Saga框架之上,对Saga模式进行的原理性解说,其中包含banq个人经验总结和见解,请从批判性视角看待。Chris Richardson的另外一本书籍《POJO in Action》曾经是帮助Spring成功挑战了EJB2。

在微服务环境下为什么不能使用ACID事务?因为每个微服务都拥有自己的私有数据库,比如订单服务有自己的订单数据库,而客户服务有自己的客户数据库,如果有一个业务操作需要跨订单和客户一起操作,那么一般使用JTA+XA方式跨订单数据库和客户数据库操作:

@ Transactional //事务元注解
public void crossAction(XX){
    //事务开始

    //这里ORDERS是属于订单服务的私有数据库
    SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ?

    //这里CUSTOMERS是属于客户服务的私有数据库
    SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID=?

    INERT INTO ORDERS .....

    //提交事务

}
<p>

以上JTA操作如果结合XA数据源配置,将会实现2PC两段事务提交。

阅读更多

Mycat: MySql的最佳伴侣

Mycat 是什么?从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了 MySQL 协议的的 Server,前端用户可以把它看作是一个数据库代理,用 MySQL 客户端工具和命令行访问,而其后端可以用 MySQL 原生(Native)协议与多个 MySQL 服务器通信,也可以用 JDBC 协议与大多数主流数据库服务器通信, 其核心功能是分表分库,即将一个大表水平分割为 N 个小表,存储在后端 MySQL 服务器里或者其他数据库里。

Mycat 发展到目前的版本,已经不是一个单纯的 MySQL 代理了,它的后端可以支持 MySQL、SQL Server、 Oracle、DB2、PostgreSQL 等主流数据库,也支持 MongoDB 这种新型 NoSQL 方式的存储,未来还会支持更 多类型的存储。

阅读更多

蚂蚁金服OceanBase的高可用及容灾方案

众所周知,作为生产系统中极为关键的核心软件,数据库产品的高可用性一直是使用者极为关注的功能点。尤其是在金融这样一个特殊的领域里,无论是从监管的要求来看,还是从业务需求本身来看,都需要提供24*7持续不间断的服务,这就对金融行业中数据库产品的高可用性提出了很高的要求,不但需要应对个别硬件故障的情况,还必须能够应对机房整体故障和城市灾难等极端情况,保证数据库在各种意外情况下都能持续提供服务,即具备机房级容灾能力和城市级容灾能力。

本文的主要目的,是总结和回顾一下传统数据库产品常用的高可用及容灾方案,并向读者介绍一下以OceanBase为代表的分布式数据库常用的方案,希望能够起到抛砖引玉的作用,引发读者关于新型分布式架构下高可用及容灾方案的思考。

阅读更多


1 2