相信大家对于数据库并不陌生，用的最多的就是诸如 MySQL 这种关系型数据库，再比如 Redis 这种键值对存储数据库，还有诸如地理信息数据库，图关系数据库等。应用的场景不同，存储策略也不同，根本上来说，这是由它们所服务的数据模型不同而决定的。
当需要决定数据库选型时，我们可以从数据量、增删改查的使用频率，以及对数据查询方式的需求去分析使用场景。传统的关系型数据库是一个各方面都比较平均的解决方案，但是对于时序数据，其具有大量的写入需求，而几乎没有删除和修改的情况。同时时序数据的数据量非常大，既有对数据的即时使用需求，也需要对历史数据做分析。
在我们首次开源的版本中，支持了查看表结构，同时支持基本的 SQL 语句查询，查询结果会以表格和图表的形式展示。考虑到数据类型不同，我们支持线段图，柱状图和散点图，同时也会显示请求的日志，展示包括请求时间等信息。
这只是第一步，接下来我们会支持 Python 脚本，提供更丰富的数据查询方式。同时也会加强使用体验，增加脚本收藏和快速添加功能。
持续保持对 GreptimeDB 新特性的支持
比如在接口支持多行 SQL 语句查询后，Dashboard 第一时间支持了这个特性。作为官方的项目，我们理应成为 GreptimeDB 的最佳应用案例。（当然，也希望社区能产出更好的应用）你可以持续通过 Dashboard 去体验 GreptimeDB 的最新能力，这是我们很确定的目标。
在设计师的支持下持续改进用户体验
作为开发者同时也是数据库的使用者，我们致力于做出有 Greptime 特点的 UI 和交互，不断增进用户体验。
对于前端来说，Dashboard 的技术挑战并不是很大。很多工作如组件库，图表，都有非常成熟的类库可以支持。但是它的业务复杂度上限很高，既要解决时序数据的通用问题，也要针对不同使用方式做出对应的解决方案。这是一件非常有趣的事情，相信随着各行各业对于时序数据更加重视，时序数据的应用也会成为一个热门的方向。
时序数据有着诸多使用场景，比如实时展示，监控报警，历史分析等，我们希望能够针对不同的场景给出一个易用的解决方案。通过和用户的沟通交流以及自身实践，希望我们的 Dashboard 可以成为使用 GreptimeDB，乃至使用时序数据库的首选。
作为一个持续开发的开源项目，除了目前正在研发的 Python 脚本功能，还有其他的 issues 比如 notebook 等待增强与支持。欢迎来自社区的任何意见与见解，不要犹豫，加入我们，如果可能的话，提一些 issue 与 PR，共同建设 Dashboard!
Dashboard GitHub 地址 👇
https://github.com/GreptimeTeam/dashboard
[1]: https://ottertune.com/blog/2022-databases-retrospective/
👇 点击阅读原文，前往 GitHub 下载体验最新 Dashboard for GreptimeDB
