Durid在美团的现状和挑战
现状:
2个集群,70多个数据节点(物理机)
0.12版本,数据摄入主要采用Tranquility
500多张表,100TB存储,最大的表日摄入消息量在百亿级别
日查询量1700万次,TP99响应低于1秒的表占到80%
支撑外卖、酒店、旅游、金融、广告等主要业务线
挑战:
易用性
新用户花多长时间能用Druid实现他的业务需求?
遇到问题后用户能不能自己定位和解决问题?
安全性
数据是业务最重要的资产之一,如何保障业务的数据安全?
稳定性
面对不熟悉的业务逻辑,如何在一个多租户环境中定位和解决问题?
能给业务提供什么样的SLA承诺?
Druid SQL的应用和改进
我们来看一段正常的Druid SQL怎么写:
现在我们可以这样写:0.10新增的核心模块
基于Calcite实现的SQL到JSON翻译层
支持 HTTP 和 JDBC 两种调用方式
几乎能表达所有JSON查询能实现的逻辑
DruidSchema性能优化
Druid Security需求
背景 - Druid(0.10)所有API都没有访问控制,业务数据安全得不到保障 需求&目标 - 所有API都要经过认证 - 实现DB粒度的权限控制 - 所有数据访问都有审计日志 - 业务能平滑升级到安全集群 - 对代码的改动侵入性小社区方案的不足之处包括:
Web控制台对BA认证的支持较差
未认证用户的权限不能修改 (0.13修复)
权限管理只提供了low-level API,使用不方便
缺少审计日志
改进措施:
基于DB的访问控制
自动管理权限DB
支持SSO认证和非认证访问
总结
关于SQL
关于Security文章不错?点个【在看】吧! ?