随笔分类 -  SQL Server

数据库学习经验
摘要:(一)好好的系统,为什么要分库分表? 咱们先介绍下在分库分表架构实施过程中,会接触到的一些通用概念,了解这些概念能够帮助理解市面上其他的分库分表工具,尽管它们的实现方法可能存在差异,但整体思路基本一致。因此,在开始实际操作之前,我们有必要先掌握这些通用概念,以便更好地理解和应用分库分表技术。 我们结 阅读全文
posted @ 2023-06-24 07:55 古道轻风 阅读(188) 评论(1) 推荐(0) 编辑
摘要:前言:ETL(是Extract-Transform-Load的缩写,即数据抽取、转换、装载的过程),对于企业应用来说,我们经常会遇到各种数据的处理、转换、迁移的场景。今天特地给大家汇总了一些目前市面上比较常用的ETL数据迁移工具,希望对你会有所帮助。 阅读全文
posted @ 2023-04-19 08:33 古道轻风 阅读(2156) 评论(0) 推荐(0) 编辑
摘要:近期将ERP后台从MSSQL SERVER过渡到了MYSQL,确实经历了一番波折,转换过程虽然极其痛苦,这里也不卖惨了。将过程记录一下,有人愿意的话共同学习。 前面分享过操作系统和数据库的安装,倒是没啥需要注意的地方,前面说的极其痛苦,是从数据导完开始的,暂时还体会不到,本篇介绍一下如何将数据从MSSQL SERVER导出到MySQL数据库。 阅读全文
posted @ 2023-03-16 08:16 古道轻风 阅读(812) 评论(0) 推荐(0) 编辑
摘要:SqlServer属于商业数据库,不可能像Mysql等数据库一样,去解析相关的数据库binlog,从而实现增量数据的回放,结合应用属性,最后确定采用离线迁移方式,从SqlServer中将表数据全部读出,然后将数据写入到pg中,采用此种方案的弊病就是程序端需停止写入(应用可将部分数据缓存到本地),等待数据库迁移完成后,程序端再迁移至PostGresql,迁移方法如下 阅读全文
posted @ 2023-02-08 08:20 古道轻风 阅读(2462) 评论(0) 推荐(1) 编辑
摘要:本文从 5W1H 角度介绍了分库分表手段,其在解决如 IO 瓶颈、读写性能、物理存储瓶颈、内存瓶颈、单机故障影响面等问题的同时也带来如事务性、主键冲突、跨库 join、跨库聚合查询等问题。anyway,在综合业务场景考虑,正如缓存的使用一样,本着非必须勿使用原则。如数据库确实成为性能瓶颈时,在设计分库分表方案时也应充分考虑方案的扩展性,或者考虑采用成熟热门的分布式数据库解决方案,如 TiDB。 阅读全文
posted @ 2023-01-03 13:40 古道轻风 阅读(307) 评论(0) 推荐(0) 编辑
摘要:近年来,有关数据泄露相关的新闻事件屡见不鲜,不断地引发大众的讨论和担忧。各家企业都或多或少在承受相关的数据安全风险,这种可能性会给企业运行带来额外的风险,包括大众的质疑以及政府的处罚等。 Facebook超5亿用户个人数据遭到泄露; Elector Software投票应用泄露超650万以色列选民个人数据; T-Mobile数据失窃,超过1亿用户的个人信息被泄露售卖; 亚马逊因违反GDPR被重罚7.46亿欧元…… 从现有的事件统计来看, 数据库未得到正确配置和黑客攻击相对来说是比较主要的诱因;在这种严峻的个人信息保护形势背景下,各国都在强化健全相关的法律合规机制。 阅读全文
posted @ 2022-12-25 17:19 古道轻风 阅读(484) 评论(0) 推荐(0) 编辑
摘要:"天底下没有完美的数据库,也许Oracle是个例外”,前阵子几个DBA在讨论国产化替代时,有人就这么说。确实是的,Oracle算是比较完美的数据库产品了,不过现在很多用户都在面临从Oracle数据库向其他数据库迁移的问题。中国电信已经宣布了今年年底前全线下架Oracle数据库,全部用国产或者开源数据库替代。本周和中国电信的朋友交流的时候,他们说已经完成了数百套系统从Oracle数据库的迁移,最晚到8月份,这个任务就能够完成了。 阅读全文
posted @ 2022-12-13 20:57 古道轻风 阅读(362) 评论(0) 推荐(0) 编辑
摘要:分库分表,是企业里面比较常见的针对高并发、数据量大的场景下的一种技术优化方案,也是一个非常高频的面试题。但是,因为很多人其实并没有非常丰富的分库分表的经验,所以能把这个问题回答得比较好的人其实还挺少的。 那么,本文就来试图把关于分库分表的事情,一次性讲个清楚。 阅读全文
posted @ 2022-11-22 23:47 古道轻风 阅读(944) 评论(0) 推荐(1) 编辑
摘要:数据库选型是一件很大的事情,也是一件很头疼的事情。 很多企业并没有数据库的选型标准,或者并不了解业务需要什么样的数据库。 很多企业的数据库是开发说了算,熟悉什么就用什么,很多选型失误,导致后期非常尴尬的局面。 那么数据库选型要注意什么呢? 列举一些例子,取自如下文档 阅读全文
posted @ 2022-10-17 13:08 古道轻风 阅读(530) 评论(0) 推荐(0) 编辑
摘要:随着系统运行时间的推移,数据库日志文件会变得越来越大,这时我们需要对日志文件进行备份或清理。 阅读全文
posted @ 2022-10-16 09:58 古道轻风 阅读(4393) 评论(0) 推荐(1) 编辑
摘要:工作中总是遇到数据存储相关的 Bug 工单,新需求开发设计中也多多少少会有数据模型设计和存储相关的问题。经过几次存储方案设计选型和讨论后发现需要有更全面的思考框架。 日常开发中常用的存储方案选型很多都是 “拿来主义” 的,凭借着经验、习惯选用,但对它们的细节特性或约束少有研究。 除了手边会用的存储方案,也应该关注市面上更合适的存储方案。 一定的技术预研和储备能够帮助未来更好的技术方案设计。 故写了这篇文章,抛出我的观察和思考,希望日后可以将一些更先进 (合适) 的技术引入公司业务,助力业务发展。 阅读全文
posted @ 2022-09-05 08:33 古道轻风 阅读(448) 评论(0) 推荐(0) 编辑
摘要:To continue our migration series, today’s post will focus on pgloader. Pgloader is another Open Source data migration utility for PostgreSQL from MySQL and SQL Server. Today’s demo will migrate a sample database (StackOverflow) from MS SQL Server 2019 to Postgresql v10. 阅读全文
posted @ 2022-08-21 22:59 古道轻风 阅读(535) 评论(0) 推荐(0) 编辑
摘要:本篇介绍SQL:2016(ISO/IEC 9075:2016)标准中定义的序列生成器(Sequence generator)和相关操作,以及六种主流数据库中的实现及差异:Oracle、MySQL、Microsoft SQL Server、PostgreSQL、Db2、SQLite。 阅读全文
posted @ 2022-08-15 12:47 古道轻风 阅读(952) 评论(0) 推荐(0) 编辑
摘要:携程酒店订单系统的存储设计从1999年收录第一单以来,已经完成了从单一SQLServer数据库到多IDC容灾、完成分库分表等多个阶段,在见证了大量业务奇迹的同时,也开始逐渐暴露出老骥伏枥的心有余而力不足之态。基于更高稳定性与高效成本控制而设计的订单存储系统,已经是携程在疫情后恢复业务的必然诉求。 目前携程酒店订单系统,在着在业务高增长的同时,也面临着信息读写管理能力受制于数据库自身性能与稳定性的窘境。综合分析,一则为携程服役了十多年的SQLServer服务器集群的磁盘容量设计,已经跟不上时下新增订单量的空间诉求;二则在系统能力提升上造成了各大业务系统巨大的底层瓶颈与风险,同时又相比业界主流已基于MySQL架构设计存储系统而言,我们的订单存储系统仍基于SQLServer构建也整体推高了运营成本。 为了支撑未来每日千万级订单的业务增长目标,同时满足高可用、高性能、高可扩展的高效成本控制期望,我们为酒店部门的订单DB所有访问开发并落地了一套稳定且可靠的统一中间件封装方案,对现状收敛并提供了全局统一的热点缓存系统,彻底解决了当下订单上层应用与数据库间直连的方案缺陷。 阅读全文
posted @ 2022-08-09 21:14 古道轻风 阅读(237) 评论(0) 推荐(1) 编辑
摘要:毫不夸张地说,咱们后端工程师,无论在哪家公司,呆在哪个团队,做哪个系统,遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论,能让大家快速、准确的去选择出合适的优化方案,我相信能够快速准备解决咱们日常遇到的80%-90%的性能问题。 从解决问题的角度出发,我们得先了解到问题的原因;其次我们得有一套思考、判断问题的流程方式,让我们合理的站在哪个层面选择方案;最后从众多的方案里面选择一个适合的方案进行解决问题,找到一个合适的方案的前提,是我们自己对各种方案之间的优缺点、场景有足够的了解,没有一个方案是完全可以通吃通用的,软件工程没有银弹。 下文的我工作多年以来,曾经使用过的八大方案,结合了平常自己学习收集的一些资料,以系统、全面的方式整理成了这篇博文,也希望能让一些有需要的同行在工作上、成长上提供一定的帮助。 阅读全文
posted @ 2022-05-03 16:26 古道轻风 阅读(3490) 评论(0) 推荐(1) 编辑
摘要:在开源技术使用日益广泛的今天,笔者也可能突然被要求用一个新工具同步数据到一个新数据库,时间还可能更紧迫。到时怎么办呢?再愤怒一次吗?不了不了,还是脚踏实地总结一下,记下这些坑,日后类似项目,哪怕被拿着枪指着头也好,下述问题都要在前期阶段予以考虑。 阅读全文
posted @ 2022-03-16 13:23 古道轻风 阅读(902) 评论(0) 推荐(0) 编辑
摘要:SQL Server没有完备的中间件产品,所以无论是逻辑Sharding还是只读分离,都需要用户配合做应用改造,而从用户角度看Sharding改动量很大,不是一时间能完成的,那么更多是寄希望于我们来提供读写分离的方案,满足业务需求。 那么读写分离,我们第一个想到的即是AlwaysOn技术。但由于当时AlwaysOn对域控和Windows群集都是强依赖,而这两者又对我们所依赖的基础设施有很大挑战,需要做很多突破产品限制的非标准化操作才有可能实现,并且还有安全风险。所以最后我们只能放弃AlwaysOn技术方案,重新设计方案帮助用户度过难关。 阅读全文
posted @ 2022-01-15 19:20 古道轻风 阅读(573) 评论(0) 推荐(0) 编辑
摘要:“AlwaysOn”一词至少在 SQL Server 2008 中已经出现,表示 SQL Server 可以持续地提供服务。但是当时“AlwaysOn”技术并没有提供管理界面(通过 Windows 管理工具进行管理),所以这个字样鲜为人知。 尽管 SQL Server 2012 在 SSMS 中出现了“AlwaysOn”专用管理工具,但是其只能管理 AlwaysOn 可用性组,导致常被误解为 AlwaysOn 只有(或者等同于)可用性组这一种技术。 SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用 AlwaysOn 技术,可以提高应用程序可用性,并且通过简化高可用性的部署和管理方面的工作,获得更好的硬件投资回报。 阅读全文
posted @ 2022-01-14 11:19 古道轻风 阅读(2190) 评论(0) 推荐(0) 编辑
摘要:从SQLServer 2012以后微软推出了新的SQLServer高可用技术 ,它的名字叫AlwaysOn。 AlwaysOn是一种集合了高可用性和灾难恢复两种功能于一体的技术,相比故障转移群集、数据库镜像和复制订阅拥有许多优势,所以现在这种高可用方案被企业广泛的应用于生产环境中。 AlwaysOn可用性组是SQLServer 2012中提供的全新功能,确保了应用程序数据的可用性,实现零数据丢失,AlwaysOn可用性组技术融合了数据库集群和数据库镜像的优点,此技术的一大好处是提供非共享存储,可以避免因为存储的单点故障而造成的整个可用性方案失效。 现在的 SQLServer 2014 AlwaysOn、SQLServer 2016 AlwaysOn最多可以支持9个副本,但只有一个可用性副本上运行的数据库是处于可读写状态。 AlwaysOn是一种整库同步的技术,所有的成员服务器都维护一套相同的数据库副本。当主副本上的数据发生变化时,数据会实时同步到辅助副本上。这点与数据库镜像非常类似。 阅读全文
posted @ 2022-01-13 17:26 古道轻风 阅读(603) 评论(0) 推荐(1) 编辑
摘要:The HPI Genealogy of Relational Database Management Systems v6 is now available free for download and use under the Creative Commons BY-SA license, incorporating much of the feedback I have received. Thanks! For space reasons not all systems could be included. 阅读全文
posted @ 2021-11-15 09:53 古道轻风 阅读(131) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示