爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~
时间真的存在吗？有观点认为，时间只是人类构想出来的一种概念，是用来衡量事物变化的标准。对于数据库来说，时间伴随着数据并进。让我们进入MySQL时间漩涡中看一看。
Unix时间戳（英文为Unix epoch, Unix time, POSIX time 或 Unix timestamp），是从1970年1月1日（UTC/GMT的午夜）开始到现在所经过的秒数（格林威治时间1970年01月01日00时00分00秒、北京时间1970年01月01日08时00分00秒)，不考虑闰秒。
我们都知道，在分布式系统中，分布式 ID 有很多特殊的要求，其中之二就是要求各个 ID 必须全局唯一，且 ID 能够趋势递增。那么 MongoDB 作为一个分布式 NoSQL 数据库，它的 ObjectID 是一段字符串，是 UUID 吗？不同机器生产的 ID 会相同吗？这段字符串排序没有纯数字主键好排吧？等等，带着这样的疑问，我们一起来看看 Mongo 的 ObjectID 到底有何神秘之处！
从上次文章我们知道了最上游的数据采集流程，知道日志数据是如何产生并且传输到我们服务器进行存储的。到了我们的服务器中，会存储在不同的数据库中，数据库是分布在不同系统中，所以需要不断地进行数据流转，不同集群之间、不同地域、不同数据库类型等等之间的数据同步备份，也是十分重要并且我们必须了解的环节。
说MVCC(Multiversion concurrency control，多版本并发控制)之前，先从数据库的ACID说起。ACID其中一个就是I。也就是Isolation，隔离性。
表命名的规则分为3个层级，层级之间通过_分割，例如b_r_identity、d_l_identity。规约为:
Select UNIX_TIMESTAMP(‘2006-11-04 12:23:00’);
最近工作中遇到两例mysql时间戳相关的问题，一个是mysql-connector-java和msyql的精度不一致导致数据查不到；另一例是应用服务器时区错误导致数据查询不到。
爱可生上海研发中心成员，研发工程师，主要负责 DMP 平台监控告警功能的相关工作。
在项目开发中，一些业务表字段经常使用日期和时间类型，而且后续还会牵涉到这类字段的查询。关于日期及时间的查询等各类需求也很多，本篇文章简单讲讲日期及时间字段的规范化查询方法。
由于es官网叫停river类的导入插件，因此原始的elasticsearch-jdbc-river变更为elasticsearch-jdbc，成为一个独立的导入工具。官方提到的同类型工具还有logstash，个人觉得logstash在做数据库同步的时候并不是很好用，有太多坑要填。
今天是SQL知识大全的第五讲，主要内容是和时间函数相关，主要包括了常用的时间函数，时间提取函数，时间计算函数以及时间和时间戳之间的转换。
在我们项目开发中，数据库及表的设计可以说是非常重要，我遇到过很多库表设计比较杂乱的项目，像表名、字段名命名混乱、字段类型设计混乱等等，此类数据库后续极难维护与拓展。我一直相信只有优秀的库表设计才能发挥出MySQL最大的性能，前面有篇文章也分享了数据库的使用规范，本篇文章主要讲几个库表设计的小技巧，希望对大家有所启发。
同样 v5 Hudi 规范说，确保时间戳是单调的实现是实现者的责任。非单调时间戳违反了规范。即便如此，也需要了解多个写入端之间时间戳冲突的影响。
在第 1 部分中，我们构建了一个逻辑模型，用于说明写入时复制表在 Apache Hudi 中的工作方式，并提出了许多关于并发控制类型、时间戳单调性等方面的一致性问题。在第 2 部分中，我们研究了时间戳冲突、它们的概率以及如何避免它们（并符合 Hudi 规范）。在第 3 部分中，我们将重点介绍模型检查 TLA+ 规范的结果，并回答这些问题。
一、ObjectId的组成 首先通过终端命令行，向mongodb的collection中插入一条不带“_id”的记录。然后，通过查询刚插入的数据，发现自动生成了一个objectId “5e4fa350b636f733a15d6f62”这个24位的字符串，虽然看起来很长，也很难理解，但实际上它是由一组十六进制的字符构成，每个字节两位的十六进制数字，总共用了12字节的存储空间。相比MYSQL int类型的4个字节，MongoDB确实多出了很多字节。不过按照现在的存储设备，多出来的字节应该不会成为什么瓶颈。不过MongoDB的这种设计，体现着空间换时间的思想。 ObjectId的官方规范 1)Time 时间戳。将刚才生成的objectid的前4位进行提取“5e4fa350”，然后按照十六进制转为十进制，变为“1582277456”，这个数字就是一个时间戳。通过时间戳的转换，就成了易看清的时间格式2020-02-21 17:30:56， 2)Machine 机器。接下来的三个十六进制就是“b636f7”，这三个是所在主机的唯一标识符，一般是机器主机名的散列值，这样就确保了不同主机生成不同的机器hash值，确保在分布式中不造成冲突，这也就是在同一台机器生成的objectId中间的字符串都是一模一样的原因。 3)PID 进程ID。上面的Machine是为了确保在不同机器产生的objectId不冲突，而pid就是为了在同一台机器不同的mongodb进程产生了objectId不冲突，接下来的“af71”两位就是产生objectId的进程标识符。 4)INC 自增计数器。前面的九个字节是保证了一秒内不同机器不同进程生成objectId不冲突，这后面的三个字节“5d6f62”是一个自动增加的计数器，用来确保在同一秒内产生的objectId也不会发现冲突，允许256的3次方等于16777216条记录的唯一性。 总的来看，objectId的前4个十六进制字符是时间戳，记录了文档创建的时间；接下来3个十六进制字符代表了所在主机的唯一标识符，确定了不同主机间产生不同的objectId；后2个是进程id，决定了在同一台机器下，不同mongodb进程产生不同的objectId；最后通过3个是自增计数器，确保同一秒内产生objectId的唯一性。ObjectId的这个主键生成策略，很好地解决了在分布式环境下高并发情况主键唯一性问题，值得学习借鉴
一个MongoDB可以建立多个数据库，MongoDB默认数据库为"db"，该数据库存储在data目录中。
前一篇写了PHP的时间函数（还是草稿)，这一篇就写Mysql的时间函数吧。最近做的项目，关乎权限，于是自然而然的就与有效期联系在了一起。其 中有一个功能是生成特殊表格，可以根据用户的选择，按周、月、季
MySQL是最流行的关系型数据库管理系统，在WEB应用方面MySQL是最好的RDBMS应用软件之一。
Hudi 更复杂并不意味着 Iceberg 更好，只是需要更多的工作来内化设计。复杂性的一个关键原因是 Hudi 在核心规范中加入了更多功能。Iceberg 目前只是一种表格式，而 Hudi 是一种具有多种查询类型的完全成熟的托管表格式。如果精通 Delta Lake 内部结构，会发现 Hudi 的设计与 Delta Lake 的设计有许多相似之处。
最近在项目中用了UUID的方式生成主键，一开始只是想把这种UUID的方式生成主键记录下来，在查阅资料的过程中，又有了一些新的认识和思考。
上一篇文章 Kafka Connect JDBC Source MySQL 全量同步 中，我们只是将整个表数据导入 Kafka。这对于获取数据快照很有用，但并不是所有场景都需要批量全部同步，有时候我们可能想要获取自上次之后发生的变更以实现增量同步。JDBC Connector 提供了这样的能力，将表中自上次轮询以来发生更改的行流式传输到 Kafka 中。可以基于递增的列（例如，递增的主键）或者时间戳列（例如，上次更新的时间戳）来进行操作。Kafka Connect JDBC Source 提供了三种增量同步模式：
一直以来 MySQL 复制延迟观测是不完善的，既无法观测到真实的主从延迟，也无法支持复杂的复制拓扑环境，常用的 second_behind_master 指标更多是判断是否存在回放延迟，以及趋势变化。你无法直观的观测到事务精确的延迟情况，因为 slave 无法获知事务在 master 上的提交时间。
本文将详细剖析Canal在初次启动时如何定位同步位点，行为思路先源码，再辅以流程图进行说明，并在总结部分使用思维导图进行总结，试图引发各位的讨论。
每次放长假的在家里的时候，总想找点简单的例子来看看实现原理，这次我们来看看 Go 语言雪花算法。
1中的now()函数，返回当前时间的长日期，和2018-05-08 08:26:30格式相同
科技的发展，我们越来越多的接触电子合同，比如金融借贷合同、员工劳务合同等。当我们拿到一个电子合同的时候，怎么判断这个合同是否真实有效呢？
有这样一个需求，网络4G设备在运行时会上下线，会报错，当上下线或者报错时会将时间戳提交到管理系统，管理系统需要记录这些时间戳，那么该如何记录呢？
Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？
这个也是线上非常常见的一个问题，就是多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。
转载自 https://www.cnblogs.com/wangyongwen/p/6265126.html
多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。
在 MyISAM Static 上的所有字段有固定宽度。动态 MyISAM Dynamic 表将具有像 TEXT，BLOB 等字段，以适应 不同长度的数据类型。
公司业务使用到Greenplun数据库，根据查询的时间戳来不断的将每个时间段之间的数据，进行数据交换，但是今天发现，mysql的时间戳没有小数点后6位，即精确度到毫秒级的，所以对于这个问题，将和Greenplum数据库的时间戳后6位保持一样。当然了最大位数是6位，也可以是1-6之间的整数。可以根据自己的业务进行设计。这样进行查询每个时间段之间的数据就不会出现丢失数据和重复数据的情况了。
“时间戳”是个听起来有些玄乎但实际上相当通俗易懂的名词，我们查看系统中的文件属性，其中显示的创建、修改、访问时间就是该文件的时间戳。对于大多数一般用户而言，通过修改“时间戳”也许只是为了方便管理文件等原因而掩饰文件操作记录。但对于应用数字时间戳技术的用户就并非这么“简单”了，这里的“时间戳”（time-stamp）是一个经加密后形成的凭证文档，是数字签名技术的一种变种应用。在电子商务交易文件中，利用数字时间戳服务（DTS：digita1timestampservice）能够对提供电子文件的日期和时间信息进行安全保护，以防止被商业对手等有不良企图的人伪造和串改的关键性内容。
时间戳字段在MySQL中经常使用到，比如需要记录一行数据创建的时间或修改的时间时，我们通常会使用时间戳即timestamp字段。本篇文章主要介绍timestamp字段的使用方法及相关参数，希望大家读完能对timestamp有更深的认识。
Working with time zones, timestamps and datetimes in Laravel and MySQL - Advanced and Qualified electronic signature marketplace (eideasy.com)
消息队列，既然是队列就能保证消息在进入队列，以及出队列的时候保证消息的有序性，显然这是在消息的生产端(Producer)，但是往往在生产环境中有多个消息的消费端(Consumer)，尽管消费端在拉取消息时是有序的，但各个消息由于网络等方面原因无法保证在各个消费端中处理时有序。
Timestamp 类型在MySQL中通常用于存储日期和时间。然而，Timestamp类型的一个限制是其存储范围，它使用4字节（32位）整数来表示秒数，从而导致在2038年01月19日03:14:07之后无法正确存储时间戳。这是因为32位整数最大可表示的秒数是2^31 - 1，即2147483647秒，相当于约68年。因此，如果使用了timestamp类型则需要考虑在达到时间范围前进行相应处理。
通常的命名方式是：ODS_应用系统名(或缩写)_数据库类型_(数据库名称可省略)_数据表名_加载方式（增量还是全量），表名不能太长，一般不超过30字。如：
在今年上半年的数据库使用状况调查中，笔者收集了众多国内外知名互联网公司的数据库使用情况，其中，国外GitHub、Airbnb、Yelp、Coursera均在使用MySQL数据库，国内阿里巴巴、去哪儿网、腾讯、魅族、京东的部分关键业务同样使用了MySQL数据库。同时，MySQL也是众多数据库排行榜单的第一名，这个开发者和一线互联网企业都在用的开源数据库，你了解多少？这份MySQL自测卷，你会多少呢？
用线上升级平台代码练手，学习JAVA。飞哥建议我们自己从头再搭建一套，提高会大。我自己作为一个JAVA出身的人，用了几天时间学会PHP的经验来看。最好，先在原来代码基础上改些东西。熟悉了基本语法之后再来重新搭建一套。如果本来就是一头雾水，再加上全身心投入的时间不够充裕的话，可能会欲速而不达。 第一步，让原代码跑起来。这一步宗鉴已经运行成功了。其实JAVA就学会了五分之四了。因为不管PHP还是JAVA就是一个工具。我一个做JAVA的，做PHP的项目也不比JAVA慢。因为一个小型WEB项目架构就是：WE
在MySQL中实现数据的时间戳和版本控制，可以通过以下两种方法来实现：使用触发器和使用存储过程。
在2005、2006年期间，谷歌内部大规模使用了 MySQL 数据库。其中Google Adwords （谷歌广告部门）使用了 90 多个 MySQL Shards（分片）集群方案存储数据，是谷歌内部使用 MySQL 数据库的最大的部门之一。由于系统维护的原因，谷歌广告部门重新规划了 MySQL 集群，整个过程花了 2 年时间。因为谷歌知道它们的数据增长的非常快，再使用 MySQL 这类数据库到未来的某个时刻会非常痛苦。这就是 Spanner 的诞生原因。
一般情况下，我们在定义表模型的时候，会使用time.Time，但是会根据当前时间存储。返回给前端的时候做时区转换会比较复杂，所以一般用int64:
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
