腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

函数式编程语言及工具

专栏作者

283

文章

264441

阅读量

67

订阅数

SDP（1）：ScalikeJDBC-基本操作介绍

jdbc sql 数据库

简单来说：JDBC是一种开放标准的跨编程语言、跨数据库类型编程API。各类型数据库产品厂商都会按它的标准要求来提供针对自身产品的JDBC驱动程序。最主要的这是一套成熟的工具，在编程人员中使用很普及。既然我们的目标是开发一套标准的大数据系统集成API，那么采用JDBC系统数据接口可以沿用业内丰富的技术资源、覆盖更多类型用户的编程需要，以及降低使用门槛。对于scala编程语言来讲，ScalikeJDBC是一套最合适满足我们下面开发要求的工具库，因为它可以用最简单易用的方式来实现JDBC的基本功能。

2022-05-10

1.3K0

alpakka-kafka(7)-kafka应用案例，消费模式

kafka node.js 数据库数据处理 sql

上篇描述的kafka案例是个库存管理平台。是一个公共服务平台，为其它软件模块或第三方软件提供库存状态管理服务。当然，平台管理的目标必须是共享的，即库存是作为公共资源开放的。这个库存管理平台是一个Kafka消费端独立运行的软件。kafka的生产方即平台的服务对象通过kafka生产端producer从四面八方同时、集中将消息写入kafka。库存管理平台在kafka消费端不间断监控kafka里新的未读过的消息并及时读取，解析消息获取发布者对库存管理的指令，然后按指令更新库存状态。

2021-08-19

4020

alpakka-kafka(8)-kafka数据消费模式实现

node.js kafka mongodb 数据库 sql

上篇介绍了kafka at-least-once消费模式。kafka消费模式以commit-offset的时间节点代表不同的消费模式，分别是：at-least-once, at-most-once, exactly-once。上篇介绍的at-least-once消费模式是通过kafka自身的auto-commit实现的。事后想了想，这个应该算是at-most-once模式，因为消费过程不会影响auto-commit，kafka在每个设定的间隔都会自动进行offset-commit。如果这个间隔够短，比整个消费过程短，那么在完成消费过程前就已经保存了offset，所以是at-most-once模式。不过，如果确定这个间隔一定大于消费过程，那么又变成了at-least-once模式。具体能实现什么消费模式并不能明确，因为auto-commit是无法从外部进行控制的。看来实现正真意义上的at-least-once消费模式还必须取得offset-commit的控制权才行。

2021-08-19

4840

alpakka-kafka(5)-kafka集群配置与分布式应用部署

kafka zookeeper http 数据库 sql

在进入具体的kafka应用设计之前我们先把kafka集群环境配置介绍一下。多节点kafka-cluster的安装、配置非常简单，所以应该不用太多篇幅就可以完成一个完整可用的kafka-cluster环境了：

2021-06-21

3930

akka-typed(10) - event-sourcing, CQRS实战

数据库 sql scala

在前面的的讨论里已经介绍了CQRS读写分离模式的一些原理和在akka-typed应用中的实现方式。通过一段时间akka-typed的具体使用对一些经典akka应用的迁移升级，感觉最深的是EvenSourcedBehavior和akka-cluster-sharding了。前者是经典akka中persistenceActor的替换，后者是在原有组件基础上在使用方面的升级版。两者都在使用便捷性方面提供了大幅度的提升。在我看来，cluster-sharding是分布式应用的核心，如果能够比较容易掌握，对开发正确的分布式系统有着莫大的裨益。但这篇讨论的重点将会集中在EventSourcedBehavior上，因为它是实现CQRS的关键。而CQRS又是大数据应用数据采集（输入）管理最新的一个重要模式。

2020-08-17

4180

akka-typed(4) - EventSourcedBehavior in action

android 网络安全数据库 sql

前面提到过，akka-typed中较重要的改变是加入了EventSourcedBehavior。也就是说增加了一种专门负责EventSource模式的actor, 最终和其它种类的actor一道可以完美实现CQRS。新的actor，我还是把它称为persistentActor，还是一种能维护和维持运行状态的actor。即，actor内部状态可以存放在数据库里，然后通过一组功能函数来提供对状态的处理转变，即持续化处理persistence。当然作为一种具备EventSourcedBehavior的actor, 普遍应有的actor属性、方法、消息处理协议、监管什么的都还必须存在。在这篇讨论里我们就通过案例和源码来说明一下EventSourcedBehavior是如何维护内部状态及作为一种actor又应该怎么去使用它。

2020-06-09

4860

search（7）- elastic4s-search-filter模式

json es 数据库 sql

现在我们可以开始探讨ES的核心环节：搜索search了。search又分filter,query两种模式。filter模式即筛选模式：将符合筛选条件的记录作为结果找出来。query模式则分两个步骤：先筛选，然后对每条符合条件记录进行相似度计算。就是多了个评分过程。如果我们首先要实现传统数据库的查询功能的话，那么用filter模式就足够了。filter模式同样可以利用搜索引擎的分词功能产生高质量的查询结果，而且filter是可以进缓存的，执行起来效率更高。这些功能数据库管理系统是无法达到的。ES的filter模式是在bool查询框架下实现的，如下：

2020-05-04

3930

search（6）- elastic4s-CRUD

es 数据库 sql http

如果我们把ES作为某种数据库来使用的话，必须熟练掌握ES的CRUD操作。在这之前先更正一下上篇中关于检查索引是否存在的方法：elastic4s的具体调用如下：

2020-04-23

4590

search（0）- 企业搜索，写在前面

大数据数据库 mongodb sql 云数据库 MongoDB

计划研究一下搜索search，然后写个学习过程系列博客。开动之前先说说学习搜索的目的：不是想开发个什么搜索引擎，而是想用现成的搜索引擎在传统信息系统中引进搜索的概念和方法。对我来说，传统的管理系统legacy i.t system已经走到了尽头。根本原因是信息在量上的爆发增长，传统数据管理方式已经无法兼顾了。在我看来，除了交易管理，传统的关系数据库方式在业务管理的其它方面，特别是业务相关的数据分析、决策支持等肯定是力不从心了，这些从持续多年我所经历的数据库红色锁标记就很有说服力了。无可否认，必须想办法在大数据、分布式计算方面寻找合适的解决方案。前两年已经完成了一系列分布式计算、分布式数据库，分布式流处理等博客，足够构建一个分布式大数据平台来实现对海量数据的存储、处理了。剩下最重要的问题是如何使用平台上的这些数据，即如何能轻松又高效的使用大数据，否则前面一切努力将化为乌有。现在最迫切的需求（我认为的）就是如何对这些大数据进行高效的分析、关联，组合然后产生全面、精准的业务决策或者系统使用的支持数据。也就是说可以通过搜索把大数据平台上的数据按照业务管理要求的信息内容、表现形式提供给前端系统。

2020-03-19

8810

restapi（7）- 谈谈函数式编程的思维模式和习惯

mongodb 数据库 sql 云数据库 MongoDB .net

国庆前，参与了一个c# .net 项目，真正重新体验了一把搬砖感觉：在一个多月时间好像不加任何思考，不断敲键盘加代码。我想，这也许是行业内大部分中小型公司程序猿的真实写照：都是坐在电脑前的搬砖工人。不过也不是没有任何收获，在搬砖的过程中我似乎发现了一些现象和造成这些现象背后的原因及OOP思维、习惯模式。和大部分IT公司一样，这间公司在行业里存在了一定时间（不是初创）所以在产品和技术方面有一定的积累，通俗点就是一堆现成的c# .net 代码。然后就是项目截止日期压力。为了按时完成任务的我只能在原有代码基础上不断加功能，根本没有机会去考虑用什么样的代码模式、结构去达到更好的效果。在这个过程中有个有趣的现象引起了我的注意：基本上我只需按照某种流程（多数是业务需求）一个个增加环节就可以实现一项完整功能，当然我是不会计较这些环节对软件其它部分是否产生影响，又或者以后代码维护会不会很麻烦，只要能及时交货就行。想想这种做法恰恰是面向对象编程或所谓行令式编程的特点，即：通过逐行执行命令引导程序的状态改变，最终状态就是运行程序的结果了，或者就是功能的实现了。通过一行行增加代码最终总会到达预期的状态，不是吗。这正是OO编程的思维模式：因为程序状态体现在每行代码上，随时可以检查，验证思路，所以OOP比较容易上手（相对函数式编程而言）。

2019-10-08

6020

restapi（6）- do it the functional way, 重温函数式编程

面向对象编程数据库 sql scala

再次看了看上篇博客的源代码，发现连自己都看不懂了。想是为了赶时间交货不知不觉又回到OOP行令模式了，看看下面这段代码：

2019-09-29

9250

restapi（4）- rest-mongo : MongoDB数据库前端的httpserver

云数据库 MongoDB mongodb scala 数据库 sql

完成了一套标准的rest风格数据库CRUD操作httpserver后发现有许多不足。主要是为了追求“通用”两个字，想把所有服务接口做的更“范generic”些，结果反而限制了目标数据库的特点，最终产生了一套功能弱小的玩具。比如说吧：标准rest风格getbyId需要所有的数据表都具备id这个字段，有点傻。然后get返回的结果集又没有什么灵活的控制方法如返回数量、字段、排序等。特别对MongoDB这样的在查询操作方面接近关系式数据库的分布式数据库：上篇提到过，它的query能力强大，条件组合灵活，如果不能在网络服务api中体现出来就太可惜了。所以，这篇博文会讨论一套专门针对MongoDB的rest-server。我想达到的目的是：后台数据库是MongoDB，通过httpserver提供对MongoDB的CRUD操作，客户端通过http调用CRUD服务。后台开发对每一个数据库表单使用统一的标准增添一套新的CRUD服务。希望如此能够提高开发效率，减少代码出错机会。

2019-08-13

1.8K0

restapi（3）- MongoDBEngine : MongoDB Scala编程工具库

mongodb 云数据库 MongoDB 数据库 sql scala

最近刚好有同事在学习MongoDB，我们讨论过MongoDB应该置于服务器端然后通过web-service为客户端提供数据的上传下载服务。我们可以用上节讨论的respapi框架来实现针对MongoDB的CRUD操作。在谈到restapi之前我在这篇讨论先介绍一下MongoDB数据库操作的scala编程，因为与传统的SQL数据库操作编程有比较大的差别。

2019-08-06

1.3K0

restapi（2）- generic restful CRUD：通用的restful风格数据库表维护工具

http 数据库 sql json scala

研究关于restapi的初衷是想搞一套通用的平台数据表维护http工具。前面谈过身份验证和使用权限、文件的上传下载，这次来到具体的数据库表维护。我们在这篇示范里设计一套通用的对平台每一个数据表的标准维护方式。http服务端数据表维护CRUD有几个标准的部分组成：Model,Repository,Route。我们先看看这几个类型的基类：

2019-07-25

6990

Akka-CQRS（7）- CQRS Reader Actor 示范

scala 数据库 sql nosql

我们在这篇通过一个具体CQRS-Reader-Actor的例子来示范akka-persistence的query端编程和应用。在前面的博客里我们设计了一个CQRS模式POS机程序的操作动作录入过程，并示范了如何实现CQRS的写端编程。现在我们可以根据这个例子来示范如何通过CQRS的读端reader-actor读取由writer-actor所写入的操作事件并将二进制格式的事件恢复成数据库表的行数据。

2019-05-25

8650

Akka-CQRS（6）- read-side

scala 数据库 sql nosql

前面我们全面介绍了在akka-cluster环境下实现的CQRS写端write-side。简单来说就是把发生事件描述作为对象严格按发生时间顺序写入数据库。这些事件对象一般是按照二进制binary方式如blob存入数据库的。cassandra-plugin的表结构如下：

2019-05-25

5960

Akka-CQRS（0）- 基于akka-cluster的读写分离框架，构建gRPC移动应用后端架构

数据库 sql scala rpc

上一篇我们讨论了akka-cluster的分片（sharding）技术。在提供的例子中感觉到akka这样的分布式系统工具特别适合支持大量的带有内置状态的，相对独立完整的程序在集群节点上分布运算。这里重点要关注这些程序的内部状态，它们会占用系统资源包括内存。把状态保存在内存里相对存放在数据库里能显著提高程序运算效率。在系统出现各种情况下对这些非持久化的程序状态的管理自然就成为了需要考虑的问题，此其一。在一个多用户、高并发的大型分布式系统里往往数据库数据使用会产生大量的冲突影响系统性能。如果能够把数据库的写入和读取分成互不关联的操作就可以避免很多资源占用的冲突。

2019-05-25

5940

Akka-Cluster（5）- load-balancing with backoff-supervised stateless computation - 无状态任务集群节点均衡分配

数据库 sql scala 编程算法

分布式程序运算是一种水平扩展（scale-out）运算模式，其核心思想是能够充分利用服务器集群中每个服务器节点的计算资源，包括：CPU、内存、硬盘、IO总线等。首先对计算任务进行分割，然后把细分的任务分派给各节点去运算。细分的任务相互之间可以有关联或者各自为独立运算，使用akka-cluster可以把任务按照各节点运算资源的负载情况进行均匀的分配，从而达到资源的合理充分利用以实现运算效率最大化的目的。如果一项工作可以被分割成多个独立的运算任务，那么我们只需要关注如何合理地对细分任务进行分配以实现集群节点的负载均衡，这实际上是一种对无需维护内部状态的运算任务的分配方式：fire and forget。由于承担运算任务的目标actor具体的部署位置是由算法决定的，所以我们一般不需要控制指定的actor或者读取它的内部状态。当然，如果需要的话我们还是可以通过嵌入消息的方式来实现这样的功能。

2019-01-07

1.4K0

PICE（5）：MongoDBStreaming - gRPC -MGO Service

mongodb rpc go sql scala

我在前面提到过MongoDB不支持像SQL般字符式的操作指令，所以我们必须对所有的MongoDB操作指令建立protobuf类型才能支持MongoDB指令的序列化。在对上一篇博文里我们把MongoDB的消息指令序列化单独挑出来讨论了一番，在这篇我们准备在一个MongoDB scala开发环境里通过streaming运算来示范这些protobuf消息的应用。

2018-09-28

7790

PICE（4）：MongoDBStreaming - gRPC Protobuf conversion

mongodb rpc jdbc sql

前两篇我们介绍了JDBC和Cassandra的gRPC streaming实现。相对MongoDB来说，JDBC和Cassandra支持字符类型的query语句SQL,CQL，所以把query指令转换成protobuf structures是简单直接的。而MongoDB没有提供字符类的query，所以我们必须进行MongoDB query涉及的所有类型与protobuf类型的相互转换，实现gRPC功能会复杂的多。我们在这篇讨论里先介绍MongoDB query的protobuf转换。

2018-07-31

8420

点击加载更多

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态