深圳鼎诚网站建设,福建宁德建设局网站,网校平台搭建,西安网站建设seo竞价搭建类似joinquant、tushare类似的私有数据服务应用#xff0c;有以下一些点需要注意#xff1a; 需要说明的是#xff0c;这里讨论的是web api前后端#xff0c;当然还有其它方案#xff0c;thrift#xff0c;grpc等。因为要考虑到一鱼两吃#xff0c;本文只探讨web ap…搭建类似joinquant、tushare类似的私有数据服务应用有以下一些点需要注意 需要说明的是这里讨论的是web api前后端当然还有其它方案thriftgrpc等。因为要考虑到一鱼两吃本文只探讨web api。在web api的基础上可以提供封装sdk库供前端函数式调用服务或纯手动写restful api 的方式自己封装调用函数服务。 一、性能
性能主要取决于后端前端可以考虑性能更好的语言、多线程和异步。 后端开发上主要是序列化压缩。 1、序列化
需要考虑跨语言的问题。比如如果后端用python开发用pickle序列化前端用julia,用rust调用就会存在反序列化的问题。 如果用json序列化虽然会通用但效率会差一些。 阿里的Fury据说是一个跨语言的序列化的库没有试用过。
https://furyio.orgpython:
pip install pyfury比如python:
from typing import Dict
import pyfuryclass SomeClass:f1: SomeClassf2: Dict[str, str]f3: Dict[str, str]fury pyfury.Fury(ref_trackingTrue)
fury.register_class(SomeClass, example.SomeClass)
obj SomeClass()
obj.f2 {k1: v1, k2: v2}
obj.f1, obj.f3 obj, obj.f2
data fury.serialize(obj)
# bytes can be data serialized by other languages.
print(fury.deserialize(data))这个库正好缓解不少跨语言的痛点。但是并不一定可以解决所有语言的痛点比如对于R或C#呢就不知道是否可以。
当然还是有其它解决办法的。比如可以在这个基础上进行跨语言ffi封装不过技术上会复杂一些。
2、压缩 不仅需要考虑性能选择读写高效的库而且还要考虑跨语言的问题。 显然API是要跨网络的对压缩比以及压缩和解压来综合考量比较需要根据场景来选取。有人喜欢zstd,也有人喜欢别的。
3、数据库还是文件系统
这个具体还是要看场景并发、性能、硬件条件等看应用服务的要求各有优点。
1数据库
是选择TDengine还是Clickhouse,还是DolphinDB? 还是采用其它当然性能读/写还是读和写要求高一般的数据库就不需要考虑了如mysql之类。
2文件系统
是选择Hdf5?还是Feather,还是Parquet还有 JayCsv文件格式当源数可以考虑但是当文件服务的一线服务支持性能太差了。
Parquet压缩比好但速度略慢于Feather。hdf5对字符串性能要差需要进行特别处理。最好还是把最常用的数据格式做个比较还要看看空间占用情况。
hdf5文件我还碰到过硬盘空间澎胀空间占用异常暴涨的事情这些都需要自已摸索。
4、异步
后端如果采用异步的方式有利于提升并发的效率。这里异步的框架的深度和广度也需要进一步探讨。是在网络IO层还是包括数据库的访问
就异步而言异步支持最好的是rust特别适合做后端。
5、带宽资源
这个主要看你有多豪了。没什么说的上预算。
二、前端的灵活性
1、关于前端服务模式的适用性
可以考虑在前端提供不同的选择比如是python sdk模式提供安装包还是纯restful模式手写post,get等以及不同的语言选择来指定特定后端的序列化和压缩库的选择便于前端有更好的适用性和体验。
这个可以在前端的headers中或者post的params参数中可以带入让后端判断的参数即可以。
这个可以通过写比较详细的示例让大家更易于上手。
2、关于前端服务对后端的约束
前端如果python用户多后端用python开发有使用上有一定的优势。前后端数据格式容易对齐序列化和Dataframe等。rust也非常适合可以通过PYO3提供相应的前端适用服务封装。包括polars也是rust封装的pandas2.x上有很多还赶不上。
