2022年NoSQL数据库渐入佳境国内应用技术案例盘点.docx

NoSQL数据库渐入佳境 国内应用案例盘点2021 年 09 月 22 日 00:05it168网站原创 作者：红丸 编辑： 王玉圆 评论： 0 条【IT168 专稿】随着互联网的不断进展，各种类型的应用层出不穷，所以导致在这个云运算的时代，对技术提出了更多的需求；虽然关系型数据库已经在业界的数据储备方面占据不行动摇的位置， 但是由于其天生的几个限制，使其很难满意上面这几个需求：扩展困难、读写慢、成本高、有限的支撑容量；业界为明白决上面提到的几个需求，推出了新类型的“NoSQ”L 数据库；总的来说，在设计上，它们特别关注对数据高并发地读写和对海量数据的储备等，与关系型数据库相比，它们在架构和数据模型方量面做了”减法”，而在扩展和并发等方面做了”加法”；现今的运算机体系结构在数据储备方面要求具备巨大的水平扩展性，而NoSQL致力于转变这一 现状；目前 Google、Yahoo、Facebook、Twitter、Amazon都在大量应用 NoSQL型数据库；本文以 NoSQL 在国内知名的互联网公司应用为案例，为大家细数国内NoSQL数据库的应用情形；一、新浪微博大家都知道，在美国有一个特别出名的信息共享平台叫做Twitter，而在中国，我们也有同样的方式，就是现在特别流行的新浪微博，它仍有个特别温馨的名字，叫做围脖；新浪微博新浪微博从技术上来说，每天用户发表特殊简洁，这造成每天新增的数据量都是百万级的、上千万级的这样一个量；这样你常常要面对的一个问题就是增加服务器，由于一般一台MySQL服务器， 它可能支撑的规模也就是几千万，或者说复杂一点只有几百万，这样，你可能每天都要增加服务器，从而解决所你面对的这些问题；目前新浪微博是 Redis 全球最大的用户，在新浪有 200 多台物理机， 400 多个端口正在运行着Redis,有+4G的数据跑在 Redis 上来为微博用户供应服务；在新浪 NoSQL和 MySQL在大多数情形下是结合使用的，依据应用的特点挑选合适储备方式；譬如：关系型数据，例如：索引使用MySQL储备，非关系数据库，例如：一些K/V 需求的，对并发要求比较高的放入 Redis 储备；8 / 7Redis 通过修改源码满意自己的业务需求： 完善它的 replication机制，加入 position的概念， 让保护更简洁，同时 failover才能也大大增强；改善Hashset 在 rdb 里面的储备方式，提升复杂数据类型的加载速度；二、淘宝数据平台淘宝网拥有国内最具商业价值的海量数据； 截至当前， 每天有超过 30 亿的店铺、商品浏览记录，10 亿在线商品数，上千万的成交、保藏和评判数据；如何从这些数据中挖掘出真正的商业价值，进而帮忙淘宝、商家进行企业的数据化运营，帮忙消费者进行理性的购物决策，是淘宝数据平台与产品部的使命；淘宝数据平台数据产品的一个最大特点是数据的非实时写入，正由于如此，可以认为在肯定的时间段内，整个系统的数据是只读的；这为设计缓存奠定了特别重要的基础；一些对实效性要求很高的数据，例如针对搜寻词的统计数据，期望能尽快推送到数据产品前端，所以在内存中做实时运算，并把运算结果在尽可能短的时间内刷新到 NoSQL储备设备中，供前端产品调用；淘宝 Oceanbase的设计之初，是这样的；公司通过对淘宝的在线储备需求进行分析发觉：淘宝的数据总量比较大，将来一段时间，比如五年之内的数据规模为百TB级别，千亿条记录， 另外，数据膨胀很快，传统的分库分表对业务造成很大的压力，必需设计自动化的分布式系统；所以有了淘宝 Oceanbase，它以一种很简洁的方式满意了将来一段时间的在线储备需求，并且仍获得了一些其它特性，如高效支持跨行跨表事务，这对于淘宝的业务是特别重要的；淘宝 Tair是由淘宝自主开发的 Key/Value 结构数据储备系统，并且于 2021 年 6 月 30 号在淘宝开源平台上正式对外开源，在淘宝网有着大规模的应用；用户在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候，都在直接或间接地和Tair交互；淘宝将 Tair开源，期望有更多的用户能从我们开发的产品中受益，更期望依靠社区的力气，使Tair有更宽阔的进展空间；三、视觉中国网站在视觉中国成立之初，他们选用的数据库是MySQ，L的支撑数据库；09 年之后他们才选用了 MongoDB作为系统视觉中国采纳 MongoDB的最初阶段困难是确定有的，而且仍有许多；困难的来源一方面来源于MongoDB的年轻；虽说它的进展很快，但是究竟是年轻的产品，技术不是特殊的成熟，所以会显现许多许多 的问题；但是 MongoDB有一个好的技术团队，对产品的版本更新速度很快，对问题的响应速度很快， 这对解决问题是很大的支撑；一方面是技术，遇到困难，解决困难，在这个过程中，也得到了许多 体会，为后续的工作做了很好的预备；视觉中国的数据量是有限的，只能到千万级别，所以将数据进行分组，大致分为四组，每组的平均数据量大致是几百万到几千万；但是，依据国外的案例来看，数据量已经达到十亿、百亿的级别， MongoDB的使用基本没有显现过太大的问题；假如现在不通过auto-sharding，自己手动切片，也是很不错的；无论选用哪种数据库， 都要依据公司的情形来判定， 究竟这种转移是特别耗费成本的； SQL+NoSQL的方法，特别值得关注；另外优化是特别重要的，但是优化是有技巧的，万不行胡乱优化；四、优酷运营数据分析优酷作为一家大型视频网站，拥有海量播放流畅的视频；它秉承注意用户体验这一产品技术理念，将绝大部分储备用在视频资源上；通过建设专用的视频CDN，建立了可自由扩展、性能优异的架构，在供应更好用户体验的同时优化了储备资源；在除视频资源外的其他方面，优酷也累积了海量数据：仅运营数据，每天收集到的网站各类拜访日志总量已经达到TB级，经分析及压缩处理后留存下来的历史运营数据已达数百 TB，很快将会达到 PB 级， 5 年后数据量将会达到几十 PB级；优酷目前优酷的在线评论业务已部分迁移到MongoD，B 运营数据分析及挖掘处理目前在使用Hadoop/HBase；在 Key-Value 产品方面，它也在查找更优的 Memcached替代品，如 Redis ，相对于Memcache，d 除了对 Value 的储备支持三种不同的数据结构外，同一个Key的 Value 进行部分更新也会更适合一些对 Value 频繁修改的在线业务； 同时在搜寻产品中应用了 Tokyo Tyrant ；对于 Cassandra等产品也进行过讨论；对于优酷来说，仍处于飞速进展阶段，已经在考虑将来自建数据中心，提高数据处理才能，从网站的运营中挖掘出更多信息，为用户供应更好的视频服务；五、飞信空间飞信的 SNS平台数据量大，增长快，目前的状态如下：飞信空间日活跃用户 100W，平均主动行为 1.3 次平均好友 20 个平均每条动态储备数据量 1.5K数据容量 2600W*1.5KB=40GB以关系型数据库估量，占用储备这僮100GB左右SNS类型应用中， Feed的数据量最大， Feed数据的储备与读写操作往往是技术难度最高的部分， 由于 Feed 要求的高并发写入，弱一样性，使HandlerSocket成为 NoSQL技术的主要应用战场；HandlerSocket 仍帮飞信解决了缓存的问题，由于Innodb 已经有了成熟的解决方案，通过参数可以配置用于缓存数据的内存大小，这样只要分协作理的参数，就能在应用程序无需干涉的情形下实现热点数据的缓存，降低缓存保护的开发成本；HandlerSocket 是日本 DeNA公司的架构师 Yoshinori开发的一个 NoSQL产品，以 MySQL Plugin 的形式运行；其主要的思路是在 MySQL的体系架构中绕开 SQL解读这层，使得应用程序直接和 Innodb 储备引擎交互，通过合并写入、协议简洁等手段提高了数据拜访的性能，在CPU密集型的应用中这一优势特殊明显；由于 HandlerSocket是 MySQL的一个 Plugin ，集成在 mysqld 进程中， 对于 NoSQL无法实现的复杂查询等操作，仍旧可以使用 MySQL自身的关系型数据库功能来实现；在运维层面，原先广泛使用的 MySQL主从复制等体会可以连续发挥作用，相比其他或多或少存在一些bug 的 NoSQL产品，数据安全性更有保证；六、豆瓣社区BeansDB是一个由国内知名网站豆瓣网自主开发的主要针对大数据量、高可用性的分布式 KeyValue 储备系统， 采纳 HashTree 和简化的版本号来快速同步保证最终一样性 弱 ，一个简化版的Dynamo，它在伸缩性和高可用性方面有特别好的表现；豆瓣社区它采纳类似 memcached的去中心化结构，在客户端实现数据路由；目前只供应了Python 版本的客户端，其它语言的客户端可以由memcached的客户端稍加改造得到；它具有如下特性：高可用：通过多个可读写的用于备份实现高可用最终一样性：通过哈希树实现快速完整数据同步 短时间内数据可能不一样 简洁扩展：可以在不中断服务的情形下进行容量扩展；高性能：异步网络 IO,日志结构的储备方式 Bitcask.简洁协议： Memcache兼容协议，大量可用客户端目前， BeansDB在豆瓣主要部署了两个集群：一个集群用于储备数据库中的大文本数据，比如日记、帖子一类；另外一个豆瓣 FS集群，主要用于储备媒体文件，比如用户上传的图片、豆瓣电台上的音乐等；BeansDB采纳 Key-Value 储备架构，其最大的特点是具有高度的可伸缩性； 在 BeansDB的架构下， 在大数据量下，扩展数据节点将轻而易举，只需要添加硬件，安装软件，修改相应的配置文件即可；BeansDB在可用性方面也有很大的优势， 任何一个节点宕机都不会受到影响，数据是自动伸缩冗余的；在运维方面也很简洁，基本上没有什么用户数据的冗余残余，全部数据通过一个同步脚本可以快速同步；总结综合来看， NoSQL数据库正在逐步地成为数据库领域中不行或缺的一部分，它补偿了关系型数据库在某些应用场景的不足，但是它也并非万能，方法得当的话，能获得许多的好处；企业应当谨慎行事，要充分地熟悉到这些数据库的一些限制和问题；依据毛爷爷的话讲就是：前途是光明的，道路是曲折的；