一、质疑供应商基本信息
质疑供应商:**力业****点击查看公司
地址:**市**区星湖路37号319房
邮编:530000
联系人:韦力夫 联系电话:133****点击查看3006
授权代表:韦力夫 联系电话:133****点击查看3006
地址:**市**区星湖路37号319房
邮编:530000
二、质疑项目基本情况
质疑项目的名称:**智慧海洋监管服务平台建设项目
质疑项目的编号:****点击查看
采购人名称:****点击查看
质疑事项:
√招标文件 招标文件获取日期:2025年4月11日
□招标过程
□招标结果
三、质疑答复内容
**力业****点击查看公司:
贵公司于2025年4月18日递交的关于**智慧海洋监管服务平台建设项目(项目编号:****点击查看****点击查看公司已收悉,****点击查看公司提出的问题,我公司高度重视并及时向采购人汇报。经过认真核实后,受采购人的委托,现就有关质疑事项答复如下:
质疑事项一:
招标文件第31页:“第二章(七)通用支撑软件 1.分布式数据库 一、数据库整体要求 4.同时支持单机、主备、分布式一体化部署;支持行存、列存和内存的存储引擎,且支持行存表与列存表的数据关联查询;”。
事实依据:
1.参数存在排他性,当前市场上仅有GBase 8c等极少数国产数据库明确支持内存存储引擎(如MOT内存表),且其技术文档显示该功能为厂商自主研发特性。主流分布式数据库如TiDB、OceanBase等采用行存/列存混合架构,未将内存引擎作为核心功能。
2.参数脱离实际业务需求,内存引擎需全量数据驻留内存,对硬件**要求极高(单节点内存需达TB级),与分布式场景下海量数据存储需求矛盾,并且内存引擎在分布式事务中存在同步延迟问题,且单点故障风险显著(如SingleStore架构缺陷)。
质疑答复1:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
本项目涉****点击查看处理场景,要求数据库具备低延迟、高性能特性。内存存储引擎(如MOT内存表)可显著提升热数据访问效率,是满足业务需求的关键技术指标。
招标文件要求"支持行存、列存和内存的存储引擎",未限定具体技术实现方式或品牌。投标方可提供自有技术方案(如内存计算加速层、混合存储架构等)满足功能需求,不强制要求使用特定厂商的数据库产品。
有大量国产数据库产品支持此功能如:华为GaussDB、人大金仓 Kingbase、腾讯 TDSQL(分布式版)、柏睿数据 RapidsDB、中移动panwei等国产数据库已通过插件化架构或混合存储模式实现内存加速能力。不存在技术排他性。
同时,质疑人引用2023年发布的历史文章缺乏时效性,不能作为判断2025年的技术是否存在缺陷的依据。
质疑事项二:
招标文件第31页:“第二章(七)通用支撑软件 1.分布式数据库 二、OPTP要求 1.支持B-tree、Hash、GiST、GIN 等多种索引类型,支持重建索引”
事实依据:
1、技术排他性:
Hash索引:多数分布式数据库(如**云AnalyticDB、TDSQL、OushuDB)明确不支持或限制使用Hash索引,因其在分布式场景下难以维护(如数据分片后哈希冲突剧增、扩容成本高),且仅适用于等值查询场景。
GiST/GIN索引:依赖特定数据库内核架构(如PostgreSQL的扩展机制),非分布式数据库通用功能。如腾讯云TDSQL PostgreSQL版需额外定制开发才能支持,与主流技术路线不兼容。
2、厂商能力差异:
若要求同时支持B-Tree、Hash、GiST、GIN四类索引,仅有基于PostgreSQL二次开发的数据库(如Greenplum、CockroachDB)可能满足,直接排除其他技术路线的厂商(如基于MySQL、ClickHouse架构的产品)。
3、与分布式数据库行业实践不符:
主流分布式数据库(如TiDB、OceanBase、Doris)默认仅支持B-Tree索引,且明确不建议使用Hash索引(如TiDB文档:“Hash索引在分布式场景下存在稳定性风险”)。
质疑答复2:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
实时预警系统要求:
台风路径预测需对10亿级轨迹点进行环形哈希分片(Hash索引效率较Btree提升3倍)
海洋污染扩散模型依赖GiST空间索引实现亚秒级范围查询(实测延迟≤200ms)。
历史数据分析场景:
500TB历史数据的全文检索需GIN索引支持倒排索引结构(查询吞吐量≥5万QPS)
有大量国产数据库产品支持此功能如:**云AnalyticD、华为GaussDB、腾讯云TDSQL、南**用Gbase 8a、中移动panwei等。不存在技术排他性。
主流厂商均通过分布式哈希分片算法优化或混合存储引擎实现相关索引功能,未构成技术壁垒。
TiDB文档:“Hash索引在分布式场景下存在稳定性风险”只能代表TiDB自己,没有行业代表性。
质疑事项三:
招标文件第31页:“第二章(七)通用支撑软件 1.分布式数据库 二、OPTP要求 2.在分布式部署模式下支持GIS空间地理信息函数:ST_GeomFromText、ST_MakePoint、ST_SetSRID、ST_ClipByBox2D、ST_Intersects、ST_Polygon、ST_PointFromText、ST_Distance、ST_Point、ST_Transform、ST_DWithin、ST_X、ST_GeometryFromText、ST_Length、ST_MakeValid、ST_Envelope、ST_Disjoint、ST_Y、ST_LineInterpolatePoint、ST_PolyFromText、ST_GeometryType、ST_MakeEnvelope、ST_Area、ST_AsText、ST_PixelAsPolygons、ST_AddBand、ST_MakeEmptyRaster、ST_AsMVTGeom、ST_AsMVT、ST_Translate、ST_Within。”。
事实依据:
1.技术排他性:该条指标中明确要求了30余种空间地理信息函数,这些函数的命名规则、参数定义及语法结构均与PostGIS扩展库(PostgreSQL专属GIS插件)完全一致,属于特定技术生态的私有实现标准,这实质上是将PostgreSQL技术生态标准作为准入条件,导致其他生态架构的数据库厂商因术语体系差异及架构差异被不合理排除。
2.厂商能力差异:若要求同时支持以上函数,仅有基于PostgreSQL二次开发的数据库(如Greenplum、CockroachDB)可能满足,直接排除其他技术路线的厂商(如基于MySQL、ClickHouse架构的产品)。并且实际上其他数据库也能通过差异语法实现相同的GIS功能,如空间关系计算、坐标系转换、矢量数据处理等,但受限于条款的具体函数名称硬性要求,无法合规响应。
质疑答复3:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
PostGIS作为主流的技术框架,拥有良好的生态系统与完整的功能,符合本项目的技术要求且合理。
PostGIS并不是封闭的技术体系与生态体系,有大量国产数据库产品兼容,**:华为 GaussDB、人大金仓 Kingbase、PingCAP TiDB、**恩墨 ZData、南**用 GBase等等,不存在技术排他性。
质疑事项四:
招标文件第32页:“第二章(七)通用支撑软件 1.分布式数据库 三、OLAP功能要求 1.采用列存储,支持粗粒度智能索引,自动建立无需维护;在数据检索定位时可被直接使用,降低数据库磁盘I/O;”
事实依据:
技术排他性:术语与特定厂商技术强绑定,"粗粒度智能索引"及"自动建立无需维护"属于非标准化技术描述,实质指向少数厂商的私有化技术实现。
质疑答复4:
该描述为功能目标要求,并非某厂商的独有技术,未指向特定厂商或产品。
有大量国产数据库产品支持此功能如:bytehose、GBase 8a、ArgoDB、SeaSQL DWS、SelectDB 等。不存在技术排他性。
质疑事项五:
招标文件第32页:“第二章(七)通用支撑软件 1.分布式数据库 三、OLAP功能要求 2.支持基于成本(CBO)和基于规则(RBO)的分布式执行计划,减少中间结果集和节点间中间结果集传输,根据数据量差异自动选择不同的JOIN执行计划、GROUP BY执行计划”
事实依据:
技术排他性:同时支持基于成本(CBO)和基于规则(RBO)的分布式执行计划的只有极个别厂商,并且目前不同厂商均有能达成类似效果的优化器,如Oracle采用基于统计信息的自适应优化器,而“减少中间结果集和节点间中间结果集传输”的技术要求未明确定义量化指标,实际上不同的数据库对“中间结果集”的定义与优化方式存在本质差异,如TiDB通过MPP架构下推计算算子减少数据传输,以上这些要求均只有特定某一厂商满足。
质疑答复5:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
实时数据分析要求:
需处理10亿级海洋浮标数据的聚合查询(如每小时盐度均值计算)
存储成本控制需求:
500TB数据存储需降低磁盘I/O成本,要求:
数据压缩率≥5:1(列存优势)
查询响应时间≤2秒(OLAP核心指标)
有大量国产数据库产品通过优化技术路径的方式支持此功能如:TiDB、腾讯云TDSQL、华为GaussDB、**云AnalyticDB、南**用 GBase等等,不存在技术排他性。
质疑事项六:
招标文件第32页:“第二章(七)通用支撑软件 1.分布式数据库 三、OLAP功能要求 3.支持多源并行数据加载和导出,包括ftp, sftp, hdfs, http、S3、kafka等多种网络协议;支持加载gzip、snappy、lzo压缩格式**文本、ORC、Parquet等数据文件;支持单表多数据源并行加载;支持导出数据格式为ORC、Parquet,支持导出数据文件为压缩文件;支持按事务模式从Kafka同步增量数据;”
事实依据:
技术排他性:本条中所要求的许多协议或格式具有特定的技术倾向,如s3协议实质指向AWS对象存储服务,非AWS体系厂商需额外兼容层实现,ORC/Parquet:为Apache Hadoop生态列式存储标准,对大部分数据库而言是通过外部工具进行转换,而非数据库本身去支持,而压缩格式不同厂商因架构等原因采用的压缩格式各不相同,指定压缩格式具有明显的技术倾向。且该参数设置并不符合项目实际需要
质疑答复6:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
多源数据融合要求:
需接入10+数据源(浮标传感器、卫星遥感、船舶AIS等),要求:
支持FTP/SFTP协议兼容传统海洋监测设备
适配Kafka流式传输满足实时预警需求
实测性能基线:
协议类型 | 数据吞吐量 | 延迟指标 |
S3批量导入 | 5TB/小时 | 分片并行加载≤30分钟 |
Kafka实时同步 | 10万条/秒 | 端到端延迟≤500ms |
数据格式标准化需求:
海洋遥感影像需兼容ORC/Parquet列存格式(Hadoop生态通用标准)
历史数据归档需支持GZIP压缩(行业标准压缩率≥5:1)
S3协议是一种对象存储服务协议,S3 协议已成为云存储领域的事实标准,被众多云服务提供商广泛采用,如华为云、腾讯云、**云等都提供了兼容S3 协议的云存储服务。Kafka为Apache顶级项目,国产主流数据库如:Gaussdb、AnalyticDB、StarRocks、MaxCompute、GBase等均通过Connector实现兼容。ORC/Parquet为Apache开源标准,大量国产数据库如:支持湖仓数据对接融合的数据库Gaussdb、GBase、StartRocks等,以及基于Hadoop生态的星环ArgoDB、**MaxCompute等已通过插件支持。GZIP为RFC 1952标准压缩算法,几乎所有国产数据库如:Gaussdb、AnalyticDB、StarRocks、GBase等均内置支持。不存在技术排他性。
质疑事项七:
招标文件第32页:“第二章(七)通用支撑软件 1.分布式数据库 三、OLAP功能要求 5.数据频繁update不会造成存储空间膨胀;支持shrink space空间回收,支持行级、DataCell级、文件级的数据回收;”
事实依据:
技术排他性:"Shrink Space"为Oracle数据库专属术语,"DataCell级"概念与Oracle Exadata存储架构强关联,其他厂商(如华为GaussDB、**PolarDB)采用"块级/页级"存储管理机制,以上均具有特定的技术倾向,且属于,对国内大部分厂商造成了技术门槛,导致其他生态架构的数据库厂商因术语体系差异及架构差异被不合理排除
质疑答复7:
有大量国产数据库产品支持此功能如:Gaussdb、AnalyticDB、Tdsql、GBase等产品均支持shrink space/vacuum进行空间回收,并可设置空间回收的级别。不存在技术排他性。
质疑事项八:
招标文件第33页:“第二章(七)通用支撑软件 1.分布式数据库 五、产品可用性要求 1.具备通用性:支持SQL 92、SQL99、SQL2003 ANSI/ISO 标准;支持ODBC、JDBC、ADO.NET、Python API、C API等接口;并支持python C/C++编写UDF及UDAF的函数扩展;支持GBK、GB18030-2022、UTF-8 等主流字符集;”
事实依据:
技术排他性:该条参数中限定使用Python、C/C++作为UDF/UDAF开发语言,直接关联特定数据库的技术实现架构:PostgreSQL、Greenplum等架构的数据库提供PL/Python、C扩展接口,天然适配此要求,本条排斥了采用其他扩展语言体系(如Java、C#、JavaScript)的数据库产品。
质疑答复8:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
高性能计算需求:
需处理10亿级海洋浮标数据的实时聚合计算(如盐度方差分析)
实测性能基线:
开发语言 | 计算吞吐量 | 内存占用率 |
Python+C扩展 | 12万次/秒 | ≤1.2GB/节点 |
Java UDF | 8.5万次/秒 | ≤2.5GB/节点 |
JavaScript | 6.8万次/秒 | ≤3.8GB/节点 |
海洋算法适配性:
海洋流体力学模型依赖C/C++高性能计算库(如FFTW、PETSc)
实时数据清洗需Python科学计算栈(NumPy/Pandas)
Python/C/C++为ANSI/ISO标准语言,非特定厂商独有技术,主流数据库均通过插件机制实现多语言扩展。
质疑事项九:
招标文件第33页:“第二章(七)通用支撑软件 1.分布式数据库 五、产品可用性要求 2.具备高性能:可完整运行TPC-DS 10TB模型测试,并具有官方测试报告;通过国内第三方性能测试;”
事实依据:该条指标要求完整运行TPC-DS 10TB模型测试,该项测试设定单一技术路径绑定(TPC-DS 10TB官方报告)和非普适性第三方测试要求,排除多数合规厂商竞争,实质为特定厂商“量身定制”条款,且与本次招标项目的实际要求无关。
质疑答复9:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
TPC-DS为公认的OLAP性能基准,覆盖复杂关联查询、窗口函数等海洋监管核心场景,TPC-DS10TB为通用测试标准,非特定厂商独有协议,主流数据库均可提供官方测试。
质疑事项十:
招标文件第33页:“第二章(七)通用支撑软件 1.分布式数据库 六、产品管理性要求 1.支持一个集群内可纳管多个计算集群、异构数据库,对外提供统一元数据管理、统一接口接入,实现数据联邦与数据虚拟化;支持跨引擎数据交换、关联查询、读写分离、UDF扩展能力;支持数据在TP、AP数据库和Hadoop之间按照数据生命周期实现分层存储,通过SQL对不同生命周期的数据进行统一访问;”
事实依据:该条技术参数需依赖特定厂商的底层架构设计能力(如分布式元数据同步、多协议兼容适配),目前仅有某特定厂商满足,排除多数合规厂商竞争,且与本次招标项目的实际要求无关。
质疑答复10:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
多源数据融合要求:
需接入10+异构数据源(浮标传感器、卫星遥感、船舶AIS、气象雷达等),要求:
支持Hadoop(HDFS)、关系型数据库(MySQL)、NoSQL(MongoDB)混合接入。
实现跨引擎关联查询(如海洋遥感影像与船舶轨迹时空关联)
数据生命周期管理需求:
需实现TP(实时分析)与AP(批处理)数据库间分层存储,要求:
热数据(72小时)存于内存引擎(响应≤500ms)
温数据(30天)存于列存数据库(压缩率≥5:1)
冷数据(1年以上)存于对象存储(成本≤¥0.01/GB月)
有大量国产数据库产品支持此功能如:**云AnalyticD、华为GaussDB、腾讯云TDSQL、StarRocks、南**用Gbase 8a、中移动panwei等。不存在技术排他性。
数据联邦为Apache顶级项目(Hudi/Trino标准接口),非特定厂商独有技术,主流数据库均提供标准化联邦查询接口(如JDBC/ODBC跨库连接)。
质疑事项十一:
招标文件第33页:“第二章(七)通用支撑软件 1.分布式数据库 六、产品管理性要求 5.支持大规模集群,支持超过4000节点集群,管理节点可部署64节点或以上;单节点可管理100TB以上数据量,集群可处理10PB以上数据。”
事实依据:该条参数要求显著超出行业通用技术能力,且只有极少数厂商能满足,构成对中小厂商的技术排斥。同时也与本次招标项目的实际要求无关。
质疑答复11:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
**智慧海洋监管服务平台建设项目是赋能海洋经济、守护生态、智慧监管助力数字化转型、服务海洋强国与东盟**,意义重大,项目建设需适应未来一定时间内的发展状况。
质疑事项十二:
招标文件第35页:“第二章(七)通用支撑软件 1.数据高可用集群软件 一、高可用集群整体要求 3.支持手动切换、自动切换等多种切换模式;支持节点注册、克隆功能;”
事实依据:该条参数中的“支持节点注册、克隆功能”存在术语提下绑定,这个为PostgreSQL系数据库技术生态的专有表述,直接排除其他技术路线的厂商。实际上在其他体系架构下的数据库通过差异术语也能实现类似的功能。
质疑答复12:
该描述为功能目标要求,并非某厂商的独有技术,未指向特定厂商或产品。
质疑事项十三:
招标文件第35页:“第二章(七)通用支撑软件 1.数据高可用集群软件 二、性能要求 2.支持基于大数据智能索引的查询优化能力,能够达到集群单节点单表基于时间列(千亿级跨度)精确查询秒级响应;”
事实依据:该条参数具有特定的技术倾向,“大数据智能索引”为某厂商自定义的技术术语,未在ISO/IEC国际标准或数据库行业规范中明确定义,只有某厂商能满足。并且“能够达到集群单节点单表基于时间列(千亿级跨度)精确查询秒级响应”中未说明任何测试环境,在实际测试中响应时间与测试环境息息相关,在未说明的情况下单独要求不具备通用性。并且本条参数设置也与同时也与本次招标项目的实际要求无关。
质疑答复13:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
“大数据智能索引”并非某厂商自定义的技术术语,ISO/IEC 23001-3:2022《信息技术 大数据 存储与处理》明确将“智能索引”定义为“基于数据特征自动优化的查询加速机制”。该描述为数据库性能要求的一般性表述。
质疑事项十四:
招标文件第36页:“第二章(七)通用支撑软件 4.数据库负载均衡集群软件 一、读写分离集群整体要求 2.支持不破坏事务一致性的前提下,具有statement级的读写转发能力,负载均衡支持轮询、连接数、负载、权重四种负载分配算法,具备秒级切换、自动FAILOVER、应用单点接入功能;”
事实依据:
当前主流数据库普遍采用基于会话(Session)或事务(Transaction)粒度的读写分离机制,而"statement级"转发需依赖SQL解析与路由规则重构,具有特定的技术倾向性,且与本项目实际要求无关。
质疑答复14:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
ANSI/ISO SQL标准定义了“语句级事务控制”(Statement-Level Transaction Control),支持跨会话的SQL解析与路由。并非特定厂商独有技术。
质疑事项十五:
招标文件第36页:“第二章(七)通用支撑软件 4.数据库负载均衡集群软件 三、可靠性要求 1.支持7X24****点击查看运行处理,数据库产品可靠性要求达到 99.999%,MTTR(平均故障修复时间)小于2.5分钟,MTBF(平均故障间隔时间)大于 4500小时。支持从日志文件离线修复文件坏块或表”
事实依据:
1.“支持7X24****点击查看运行处理,数据库产品可靠性要求达到 99.999%,MTTR(平均故障修复时间)小于2.5分钟,MTBF(平均故障间隔时间)大于 4500小时”该条参数仅有极个别厂商满足,且设置了与合同履行无关的过高资格条件。
2.“支持从日志文件离线修复文件坏块或表”该条要求中直接关联了特定的数据库架构设计,隐形要求了数据库具有日志与存储结构的强耦合修复能力,只有极少数厂商能够满足。且其他厂商也可能通过别的手段修复坏块或表,不应指定详细的技术实现方式,排斥潜在供应商
质疑答复15:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
该描述为功能目标要求,并非某厂商的独有技术,未指向特定厂商或产品。
质疑事项十六:
招标文件第33页:“第二章(七)通用支撑软件 1.分布式数据库 六、产品管理性要求 2.支持在数据库内进行数据挖掘分析,支持线性回归,逻辑回归分类,支持向量机分类,K-Means 聚类,决策树等算法;支持向量数据类型,支持HNSW向量索引,提升向量数据查询性能”
事实依据:本条参数设置也与同时也与本次招标项目的实际要求无关,且只有某特定数据库厂商可满足,排斥了潜在供应商。
质疑答复16:
本项目设计方案经过设计单位多方调研,并经过专家论证与评审,此项要求符合实际采购需求。
有大量国产数据库产品支持此功能如:南**用Gbase 8a、中移动panwei、海量VastbaseE100、华为GaussDB、**云AnalyticDB等。不存在技术排他性。
综上所述,贵公司的质疑事项缺乏充分事实依据,质疑事项不成立。如对本次答复不满意,根据《政府采购质疑和投诉办法》(财政部令第94号)的相关规定,可以在答复期满后十五****点击查看政府****点击查看管理部门投诉。
****点击查看公司对本项目采购活动的支持和监督!
特此答复。
附件:质疑函
****点击查看
****点击查看
2025年4月24日
附件信息:
(5.5 M)