用户您好!请先登录!

分类目录数据库

Canel + Kafka用于数据库同步实践

在微服务拆分的架构中,各服务拥有自己的数据库,所以常常会遇到服务之间数据通信的问题。比如,B服务数据库的数据来源于A服务的数据库;A服务的数据有变更操作时,需要同步到B服务中。

第一种解决方案:

在代码逻辑中,有相关A服务数据写操作时,以调用接口的方式,调用B服务接口,B服务再将数据写到新的数据库中。这种方式看似简单,但其实“坑”很多。在A服务代码逻辑中会增加大量这种调用接口同步的代码,增加了项目代码的复杂度,以后会越来越难维护。并且,接口调用的方式并不是一个稳定的方式,没有重试机制,没有同步位置记录,接口调用失败了怎么处理,突然的大量接口调用会产生的问题等,这些都要考虑并且在业务中处理。这里会有不少工作量。想到这里,就将这个方案排除了。

阅读更多

用ShardingSphere数据脱敏

安全控制一直是治理的重要环节,数据脱敏属于安全控制的范畴。对互联网公司、传统行业来说,数据安全一直是极为重视和敏感的话题。数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。涉及客户安全数据或者一些商业性敏感数据,如身份证号、手机号、卡号、客户号等个人信息按照相关部门规定,都需要进行数据脱敏。

在真实业务场景中,相关业务开发团队则往往需要针对公司安全部门需求,自行实行并维护一套加解密系统,而当脱敏场景发生改变时,自行维护的脱敏系统往往又面临着重构或修改风险。此外,对于已经上线的业务,如何在不修改业务逻辑、业务SQL的情况下,透明化、安全低风险地实现无缝进行脱敏改造呢?

阅读更多

面向数据的架构

面向数据的架构(Data-Oriented Architecture)由 Rajive Joshi在RTI 的2007 年白皮书中首次提出,而维也纳大学(University of Vienna)的Christian Vorhemus 和Erich Schikuta 在2017 年的 iiWAS 论文中又再次对其进行了描述。 DOA 是对传统二分法的颠覆,它介于单体架构和微服务(Microservices)、面向服务的架构(Service-Oriented Architecture)之间。单体架构由一个单体二进制文件(binary)和数据存储组成;微服务、面向服务的架构由许多小型的、分布式的、独立的二进制文件组成,并且每个二进制文件都有自己的数据存储。在面向数据的架构中,单体数据存储是系统中状态的唯一来源,并由松耦合无状态的微服务对其进行操作。

阅读更多

PostgreSQL for Serverless (ServerlessDB)

不久前,腾讯云发布了国内第一款 Serverless 数据库 —— PostgreSQL for Serverless(ServerlessDB),在业界受到众多数据库开发者的广泛关注,它基于 PostgreSQL 数据库实现按需分配资源,能够做到安全隔离、弹性扩容、按需付费、原生 SQL 支持。在本文中,腾讯云 ServerlessDB 产品负责人从租户隔离技术、快速扩缩容能力、连接池管理等方面,详细解密这款数据库背后的设计细节,希望能够为所有开发者带来启发。

如何实现真正的自动扩缩容?

相比较于传统数据库,云数据库的弹性扩缩容和按量计费能够帮助用户按需使用云资源,避免资源浪费的同时大幅节省了成本。在系统实现原理上,目前云数据库提供的这类“弹性方案”本质上是一种策略上的弹性,即开发者需要先行预估自己的产品负载量,例如一款游戏什么阶段玩家特别多,什么时候人潮回落,在设定好数据库需求的方案后,对应进行手动的容量调整。

阅读更多

UUID在MySQL中的使用性能

如果你在网上快速的做一个关于 UUID 和 MySQL 的搜索,你会得到相当多的结果。以下是一些例子:

  • 存储 UUID 和 生成列
  • 在 MySQL 中存储 UUID 的值
  • 说明 InnoDB 中的主键模型及其对磁盘使用的影响
  • 主键选型之战 UUID vs. INT
  • GUID / UUID 的性能突破
  • 到底需不需要 UUID?

另:以上文章链接请在文章结尾处查看

那么,像这样一个众所周知的话题还需要更多关注吗?显然是的。

阅读更多

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服务器协议,该协议实际上与任何其他语言兼容。

阅读更多


1 2