高性能数据库，数据量非常庞大，才有什么数据库比较好

postGetWeb 2016-05-09 02:53:46
数据量非常大，几十TB
表结构比较简单，五六个字段的样子
用什么技术做比较好，要求查询速度快
像http://www.cmd5.com/，他后台的数据量肯定也非常大，但查询速度很快，他是怎么实现的
...全文
6270 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
spdata 2018-03-18
  • 打赏
  • 举报
 回复
不清楚你要存的什么，假如是监控系统的采样数据，那么可以用tsdb来存储
tianfang 2016-10-10
  • 打赏
  • 举报
 回复
分区存储 去看看一致性hash就知道怎么玩了
qingshangwuheng 2016-10-09
  • 打赏
  • 举报
 回复
据说国内有分布式数据库，实际应用已经单表TB级别了，效率也不错
kernelkoder 2016-08-25
  • 打赏
  • 举报
 回复
推荐阿里巴巴自己的数据库引擎 oceanbase
java竹雨 2016-08-16
  • 打赏
  • 举报
 回复
MS SQL
UberCN 2016-08-07
  • 打赏
  • 举报
 回复
MS SQL无疑！ 性价比远超阿里的支付宝数据库系统。
FeelTouch Labs 2016-08-05
  • 打赏
  • 举报
 回复
hbase 把查询的where作为key,但是这些一定不能为空 not null
postGetWeb 2016-05-13
  • 打赏
  • 举报
 回复
引用 2 楼 wangjian0228 的回复:
十几个T在一张表？这得多大的列啊 只是查询用spark、ES
肯定要做成分布式的
致命的西瓜 2016-05-10
  • 打赏
  • 举报
 回复
十几个T在一张表？这得多大的列啊 只是查询用spark、ES
赵4老师 2016-05-09
  • 打赏
  • 举报
 回复
MapReduce ？
数据库表数据量大读写缓慢如何优化（1）【冷热分离】
今天讨论的内容是冷热分离，也许概念并不陌生，对其使用场景也比较熟悉，但涉及锁的内容时仍然需要认真思考，这部分内容在我们实际开发中的“坑”还是不少的。 业务场景一 曾经经历过供应链相关的架构优化，当时平台上有一个订单功能，里面的主表有几千万数据量，加上关联表，数据量达到上亿。 这么庞大的数据量，让平台的查询订单变得格外迟缓，查询一次都要二三十秒，而且多点击几次就会出现宕机。比如业务员多次查询时，数据库的 CPU 会立马狂飙，服务器线程也降不下来。 当时，我们尝试了优化表结构、业务代码、索引、SQL 语句等.
数据量转换及几种关系型数据库优缺点比较
计算机存储信息的大小，最基本的单位是字节，一个汉字由两个字节组成，字母和数字由一个字节组成。容量的单位从小到大依次是：字节（B）、KB、MB、GB、TB。它们之间的关系如下： 1TB=1024GB 1GB=1024MB 1MB=1024KB 1KB=1024字节 1GB=1百万KB常用数据库的处理数量级 Excel 2010 可处理行数据量104,8576，大概1百万 Access数据库：
【性能测试】MySQL数据库性能测试
文章目录一、数据库性能测试概述1.1 数据库性能测试的目的1.2 数据库的性能测试范围二、数据库架构2.1 数据库常用架构1. 一主多从2. 双机热备3. 主从同步工作原理2.2 数据库分库分表的设计方法拆分原因分库分表方案三、mysql专题性能测试3.1 概述3.2 mysql主流分支MariaDb3.3 Mysql数据库重点监控指标1. QPS2. TPS3. 线程连接数4. Query Cache5. 锁定状态6. 主从延时3.4 mysql慢查询1. 慢查询定义2. 慢查询开启3. 慢查询日志分析3
简述数据库和数据仓库的区别
数据库和数据仓库的区别 简单的来说，数据库偏向于管理和储存，数据仓库偏向于整合和分析 数据库：传统的关系型数据库的应用，主要是基本的、日常的事务处理，更关注业务交易处理（OLTP） 数据仓库：数据仓库支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询效果，更关注数据分析层面（OLAP） 随着业务指数级的增长，数据量陡增，从最初粗放的数据分析逐步演化为角色和场景都非常精细化的集群分析。这类非常具体，且能够对公司决策起到关键性作用的数据，很难从业务数据库中调取出来，主要原因是： 1、业务数据库中的数据结构
订单数据越来越多，如何优化数据库性能？
对于订单这类具有时间属性的数据，会随时间累积，数据量越来越多，为了提升查询性能需要对数据进行拆分，首选的拆分方法是把旧数据归档到历史表中去。这种拆分方法能起到很好的效果，更重要的是对系统的改动小，升级成本低。在迁移历史数据过程中，如果可以停服，最快的方式是重建一张新的订单表，然后把三个月内的订单数据复制到新订单表中，再通过修改表名让新的订单表生效。如果只能在线迁移，那需要分批迭代删除历史订单数据，删除的时候注意控制删除节奏，避免给线上数据库造成太大压力。线上数据操作非常危险，在操作之前一定要做好数据备份。
数据库开发

8,028

社区成员

1,361

社区内容

发帖
与我相关
我的任务
社区描述
高性能数据库开发
社区管理员
  • 高性能数据库开发社区
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章