- 综合排序
- 最热优先
- 最新优先
- 来自专栏DBA随笔
MySQL之infobright介绍
MySQL之infobright介绍 今天在处理一个业务的时候，谈及利用infobright作为存储引擎，来支持业务对大量数据的查询操作，就特意看了一下这个infobright的特点，这里对它进行一个总结 这足以证明infobright的查询性能。 infobright支持MySQL中的所有数据类型，可以无缝对接MySQL中的数据。 ； 除此之外，infobright不支持高并发的查询。 今天下午试了试从0开始安装infobright，还是有些小问题，真个流程还没有整理出来，关于infobright的完整安装步骤，摸索完了之后会给出，希望对大家有帮助吧。 同时，由于infobright已经闭源，没有人维护了，所以最新一版的infobright安装包网上也比较少，回头发一个给大家。
1.8K10发布于 2019-11-06 - 来自专栏DBA随笔
MySQL之infobright安装步骤
MySQL之infobright安装步骤 整个安装过程过了一遍，感觉跟MySQL的安装差不太多。 You can start the MySQL daemon with: cd /usr/local/infobright-4.0.7-x86_64 ; /usr/local/infobright-4.0.7 ) Infobright server installed into folder /usr/local/infobright Installation log file /tmp/ib4.0.7-0- 、根据最后一行提示，激活infobright server，运行脚本. [y/n]:y Copying /usr/local/infobright-4.0.7-x86_64/data to /data/infobright_5029/data ...is done.
1.7K20发布于 2019-11-06 - 来自专栏架构师成长之路
Infobright高性能数据仓库
Infobright是开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)， infobright 是基于mysql的，但不装 3、服务形式与接口跟mysql一致，可以用类似mysql的方式启用infobright服务，然后原来连接mysql的应用程序都可以以类似的 方式连接与查询infobright。 架构 基于MySQL的内部架构 – Infobright采取与MySQL相似的内部架构 下面是Infobright的架构图： 灰色部分是mysql原有的模块，白色与蓝色部分则是 infobright 压缩层再向上就是infobright最重要的概念：Knowledge Grid（知识网格）这也是infobright放弃索引却能应用于大量数据查询的基础。 数据的压缩跟数据的类型有关，infobright会根据数据的类型选择压缩算法。infobright会自适应地调节算法的参数以达到最优的压缩比。 6.
86520编辑于 2022-04-14 - 来自专栏从ORACLE起航，领略精彩的IT技术。
IEE数据库安装向导
①上传infobright-4.0.6-x86_64.tar包和配置文件my-ib.cnf，mysqld-ib到服务器任意目录 ②解压tar包，移动到/usr/local/目录下，配置文件分别移动到/etc /目录，/etc/init.d/目录下 tar -xvf infobright-4.0.6-x86_64.tar mv infobright-4.0.6-x86_64 /usr/local/ mv my-ib.cnf /postconfig.sh（第一次运行postconfig.sh,更改IEE数据库的数据目录） Infobright post configuration -------------------- [y/n]:y Copying /usr/local/infobright-4.0.6-x86_64/data to /ieedata/data ...is done. You can now remove/backup your old /usr/local/infobright-4.0.6-x86_64/data ... Done! # .
1K40发布于 2019-05-24 - 来自专栏从ORACLE起航，领略精彩的IT技术。
使用普通用户替代root来管理IEE
# ps -ef|grep mysql|grep -v grep root 4833 1 0 16:23 pts/0 00:00:00 /bin/sh /usr/local/infobright pid-file=/oradata/app/iee/data/JingyuDB.pid root 4981 4833 0 16:23 pts/0 00:00:00 /usr/local/infobright -4.0.6-x86_64/bin/mysqld --defaults-file=/etc/my-ib.cnf --basedir=/usr/local/infobright-4.0.6-x86_64 drwxr-xr-x. 11 root root 4.0K Jan 27 16:09 infobright-4.0.6-x86_64 ``` 上面用到的命令列表： ``` --查询IEE进程，根据mysql -4.0.6-x86_64/bin/mysqld --defaults-file=/etc/my-ib.cnf --basedir=/usr/local/infobright-4.0.6-x86_64
67320编辑于 2022-05-06 - 来自专栏PostgreSQL研究与原理解析
国产数据库-内核特性-gbase8a智能索引
1、infobright Infobright是一款开源列式存储数据库，采用知识网格查询优化方式，对即席查询有很大提升。可惜已经没人维护了。而Gbase8a的列存就是基于infobright。 吸收了infobright列存带来的优势，我们看下infobright典型结构： Infobright通过知识网格进行数据筛选，从而降低数据IO。 Infobright对数据进行进一步划分，根据查询条件，通过知识网格对DP进行分类： 1）无关DP：DP中没有符合查询条件的数据 2）强相关DP：DP中所有数据都符合查询条件 3）待定DP：可能部分数据符合条件 3、参考 https://www.researchgate.net/publication/221213121_Data_warehouse_technology_by_infobright https ://www.researchgate.net/publication/252041317_Research_of_infobright_based_on_MySQL's_open_source_engine
89340编辑于 2023-08-09 - 来自专栏杨建荣的学习笔记
MySQL性能扩展的架构优化方案(二)
一类是infobright，除此之外还有其他大型的解决方案，比如Greenplum的MPP方案，columnstore的方案有点类似于这种MPP方案，需要的是分布式节点，所以在资源和架构上infobright from receipt_12149_420 limit 100 into outfile '/tmp/a.csv' FIELDS TERMINATED BY ' ' ENCLOSED BY '"'; infobright 社区版是不支持DDL和DML,后期Infobright官方宣布：不再发布ICE社区版，将专注于IEE的开发，所以后续的支持力度其实就很有限了。 来简单感受下Infobright的实力： >select count( id) from testxxx where id>2000; +------------+ | count( id) | +-- 我把3500万的数据导入到infobright里面，5条查询语句总共的执行时间维持在14秒，相比原来的2分钟多已经改进很大了。我跑了下批量的查询原本的18分钟，现在只需要不到3分钟。
69620发布于 2018-12-19 - 来自专栏杨建荣的学习笔记
MySQL性能扩展的架构优化方案(三)
在和业务同学讨论的过程中，其实使用Redis方向是一个相对合适的技术方向，对于统计的支持力度还是不错的，但是限于存储成本和程序改造的工作量，业务更倾向于暂时按照已有的方案，通过对比infobright的统计优势和 比如第一个头疼的问题就是全量的同步，第一次同步肯定是全量的，这么多的数据怎么同步到infobright里面。 考虑到每天落盘的数据量大概在10G左右，日志量在30G左右，所以考虑先使用客户端导入infobright的方式来操作。 从实践来看，涉及的表有600多个，我先导出了一个列表，按照数据量来排序，这样小表就可以快速导入，大表放在最后，整个数据量有150G左右，通过网络传输导入infobright，从导出到导入完成，这个过程大概需要 而导入数据到infobright之后的性能提升也是极为明显的。原来的一组查询持续时间在半个小时，现在在70秒钟即可完成。对于业务的体验来说大大提高。
75030发布于 2018-12-21 - 来自专栏纯洁的微笑
拯救MySQL架构
社区版是不支持DDL和DML的，后期Infobright官方宣布：不再发布ICE社区版，将专注于IEE的开发，所以后续的支持力度其实就很有限了。 三、引入动态调度，解决统计延迟问题 通过引入Infobright方案对已有的统计需求可以做到完美支持，但是随之而来的一个难点就是对于数据的流转如何平滑支持。 其一： 比如第一个头疼的问题就是全量的同步，第一次同步肯定是全量的，这么多的数据怎么同步到Infobright里面。 考虑到每天落盘的数据量大概在10G左右，日志量在30G左右，所以考虑先使用客户端导入Infobright的方式来操作。 而导入数据到Infobright之后的性能提升也是极为明显的。原来的一组查询持续时间在半个小时，现在在70秒钟即可完成。对于业务的体验来说大大提高。
69910发布于 2019-09-05 - 来自专栏从ORACLE起航，领略精彩的IT技术。
IEE重建表完全释放磁盘空间具体步骤参考
XZWRNOPMRA ~]# ps -ef|grep mysql root 22063 1 0 10:44 pts/6 00:00:00 /bin/sh /usr/local/infobright -pid-file=/usr2/iee/data/XZWRNOPMRA..pid mysql 22202 22063 1 10:44 pts/6 00:00:56 /usr/local/infobright -4.0.6-x86_64/bin/mysqld --defaults-file=/etc/my-ib.cnf --basedir=/usr/local/infobright-4.0.6-x86_64 XZWRNOPMRA ~]# 此时看到，IEE的进程已经没有了，说明成功关闭了IEE，如果进程还在，说明没有成功关闭，则需要检查采集是否都关了，再尝试关闭数据库，万不得已时，可以考虑kill -9杀掉infobright
62520发布于 2019-05-24 - 来自专栏若尘的技术专栏
Clickhouse 实践
BI存储库主要采用的是Infobright，在千万量级能很快的响应BI的查询请求，但随着时间推移和业务的发展，Infobright的并发量与查询瓶颈日益凸显，我们尝试将大数据量级的表导入TiDB、Hbase Clickhouse应用 BI查询引擎 核心诉求 在未接入Clickhouse之前，BI的存储库有Infobright、Hbase、ES、druid等，其中主要使用的是Infobright，在千万级别以下 Infobright性能出色，对于一些时间跨度较长、数据量级较大的表Infobright就有些无能为力，这种数据我们通常会存放在ES与Hbase中，这样虽然加快了查询速度但是也增大了系统适配不同数据源的复杂度 功能点 Infobright TiDB Doris Clickhouse BI适配成本 - 低 低 中 学习使用成本 - 低 低 低 百万级查询(100w) 84ms 24ms 25ms 41ms 集群构建 在评估了目前Infobright中的数据量级和Clickhouse的并发限制之后，我们决定使用单分片 多副本的方式来构建Clickhouse集群，理由如下： BI对接数仓应用层数据，总体来说量级较小
2K54发布于 2021-11-21 - 来自专栏Spark学习技巧
Clickhouse的实践之路
BI存储库主要采用的是Infobright，在千万量级能很快的响应BI的查询请求，但随着时间推移和业务的发展，Infobright的并发量与查询瓶颈日益凸显，我们尝试将大数据量级的表导入TiDB、Hbase BI查询引擎 核心诉求 在未接入Clickhouse之前，BI的存储库有Infobright、Hbase、ES、druid等，其中主要使用的是Infobright，在千万级别以下Infobright性能出色 选型对比 基于以上诉求我们拿现有的Infobright与TiDB、Doris、Clickhouse做了如下对比。 功能点 Infobright TiDB Doris Clickhouse BI适配成本 - 低 低 中 学习使用成本 - 低 低 低 百万级查询(100w) 84ms 24ms 25ms 41ms 千万级查询 功能点 ck日期分区(冷查询) ck 日期分区(热查询) ck 无分区(热查询) Infobright query 12000ms 220ms 16ms 8ms 由此可见Clickhouse对于多分区的
2K40发布于 2021-03-05 - 来自专栏从ORACLE起航，领略精彩的IT技术。
IEE修改最大连接数
-v grep|awk '{print $2}'|xargs kill -9 # vi /etc/my-ib.cnf 加入配置max_connections = 300 # Example Infobright # Here follows entries for some specific programs # The MySQL server [mysqld] basedir = /usr/local/infobright
2.2K20编辑于 2022-05-06 - 来自专栏db
clickhouse深入浅出-第一篇
常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB
47110编辑于 2022-08-31 - 来自专栏DBA随笔
MySQL线上日志库迁移优化案例
table game_log_bak.table\G #第三步 在game_log库中重新创建第二步的表结构 2、将rename过后的game_log_bak库中的数据流转到本地的离线数据库中，该数据库采用infobright 5、从本地的只读从库中，像本地的infobright数据库中同步数据，同步的方法可以选用dataX工具，像下面这样： ?
79730发布于 2019-11-06 - 来自专栏腾讯云数据库(TencentDB)
直播回顾 | 丁奇剖析数据库性能
infobright可能也是老玩家才知道的，就是一个列存引擎，可以做OLAP业务的一个引擎。 blackhole是一个黑洞引擎，是什么意思呢？ 而MySQL可以不走引擎，我可以表A创建出一个Innodb表，表B创建一个infobright表，然后数据在里面做同步，以后我如果要做oltp的查询，就找Innodb表查，AP的查询就找infobright 这种场景大家可能会说好像用的不太多，我们再看下面这个图，把Innodb跟infobright放到一起，虽然MySQL天然就支持，但是它有个问题，感觉看上去不是很专业，还有比如说你在infobright上面跑 slave实例用infobright引擎。 举个例子，比如说OLAP就不支持，像刚我们说的infobright还可以，但实际上infobright现在用的也不是那么多，真的做OLAP实际上是有专门的系统来做的，一会儿我们可以举一个例子。
90920发布于 2020-03-12 - 来自专栏杨建荣的学习笔记
引入TiDB方案的一些思考
依赖于分片层的高可用机制，会导致整个服务集群有明显的卡顿，不可用现象 5）对于DDL变更较为敏感的业务，在数据实时性和准确性可以作为一种缓冲方案 6）MySQL侧在部分业务即时查询需求支持方面存在性能瓶颈，目前暂有infobright
38710发布于 2020-07-02 - 来自专栏杨建荣的学习笔记
数据同步中的动态调度
%M:%S' ` echo $end_time sh /root/a.sh "$start_time_new_str" "${end_time}" >> /root/log/data_sync_to_infobright.log `date` >> /root/log/data_sync_to_infobright.log 脚本的思路是，数据同步需要两个参数，起始时间和截止时间，起始时间是通过上一次脚本执行生成的一个时间戳文件来得到的
1.2K10发布于 2018-12-21 - 来自专栏程序人生
在多维数据分析模型的路上越走越远
找来找去，发现InfoBright这一存储引擎最合适，它采用列式存储，在针对多维数据分析这种模型上，性能很好。 认识到性能问题后，我们又尝试将查询引擎从InfoBright替换到InfiniDB，只能说略好，但没有本质区别。 顺带交代两句这两个存储引擎的命运，InfoBright这家波兰公司的产品，在这两年转型做针对物联网的存储引擎了。而InfiniDB在去年的10月1日宣布了破产。 其实InfoBright也是这么一个实现思路。于是这样查询性能的问题也解决了。所有的核心报表，都通过数据立方体来实现，展现部分用了Oracle BIEE。
1.6K60发布于 2018-03-28 - 来自专栏鸿的学习笔记
两种主要列存储方式的区别
这使它们看起来与列存储（如Sybase IQ，C-Store，Vertica，VectorWise，MonetDB，ParAccel和Infobright）处于相同的类别，这些列存储也可以单独访问列。 •组B：Sybase IQ，C-Store，Vertica，VectorWise，MonetDB，ParAccel和Infobright。 同样，这不是一个完整的列表，但这些是我最熟悉的系统。
2.1K10发布于 2018-08-06
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号