海量数据的REDIS插入.docx

海量数据的REDIS插入近日由于工作需要，需要对海量数据（1亿条）放入到redis中，于是开启了幸运（磨难）之旅。一 旅途概述。旅途目的：携带海量数据，并将海量数据运送到redis内存服务器旅途意义：放入redis之后供其它系统模块查询旅途成员：硬货（硬件）：ThinkPadx260笔记本一台、优盘一个、鼠标一个、水杯等（其它用品）若干。软货（软件）： redis服务、Windows7系统8G内存、eclipse、JDK、mysql数据库、海量数据、浏览器、互联网等旅途过程：后面详述旅途总结：1、顺利的开始不代表顺利的过程； 2、过程再难不代表没有办法； 3、一些看似简单的服务操作，当遇到大数据量是就有可能不简单 4、山外青山楼外楼二 旅途沿途风景2.1 主角亮相本次的海量数据是全国基站信息数据库，数据包含的内容及说明如下。字段名称类型取值范围内容备注mcc整型460Mobile Country Code数据库中所有条目此字段均为460，如需压缩数据库存储空间可删除此字段mnc整型0,1,11,10000-20000Mobile Network Code0表示移动基站1表示联通基站11表示电信LTE基站10000-20000表示电信CDMA基站，此时此字段的取值并非MNC，实际为电信SIDlac整型0-65535Location Area Code对于电信CDMA基站，此字段的取值并非LAC，实际为电信NIDci整型0-268435455Cell ID对于WCDMA基站，此字段的取值为28位（二进制）的UTRAN Cell ID，对于TD-SCDMA基站，此字段的取值为16位（二进制）的Cell ID，对于LTE基站，此字段的取值为28位（二进制）的ECI（由高20位的EnodeB ID和低8位的Cell ID组成）对于电信CDMA基站，此字段的取值并非Cell ID，实际为电信BIDlat浮点型0.0-90.0纬度WGS84坐标lon浮点型0.0-180.0经度WGS84坐标acc整型0-10000精度以米为单位，表示基站覆盖半径date整型更新日期validity浮点型0.0-1.0有效性数值越大有效性越高addr字符串地址地址描述字符串province字符串省省/直辖市/自治区city字符串市地级市/地区/自治州/盟district字符串区县级市/县/市辖区/自治县/旗township字符串镇镇/乡/街道源数据为压缩文件，大小为4G左右，解压完为近20G，且数据为建表和插入的sql语句。鉴于sql文件格式不规范（相对于每条数据以特殊字符分割来说），所以计划先导入到数据库中再进行处理。导入数据：Cmd进入mysql安装目录的bin文件夹；执行命令：mysql -utest -ptest-Ddbname d:/sql/xxx.sql导入开始…… 若干秒之后，报错了（当时没截图）看错误的描述就是插入语句不合法，还有部分中文乱码。通过搜索得知，应该是字符集的问题（源数据中有中文），于是重新运行导入命令：mysql -utest -ptest --default-character-set=utf8 -Dname d:/sql/xxx.sql导入开始…… 若干秒之后，导入成功。至此，第一步算成功完成。==========~~~~~~~~~~~====妖娆分割线======~~~~~~~~~~~~~~======2.2 降妖除魔接下来就真正开始了犯二与苦逼的过程。使用本数据，是想通过基站的mnc，lac和ci三个值，查询对应的地理位置信息。通过对数据的分析，确定将mnc、lac和ci作为key，地理信息作为value放入redis。犯二1：数据库直接到redis编程开始。连接数据库程序、查询语句、插入redis程序等顺利完成，大功告成，开跑！！10万、20万、50万……200万…(哈哈，很快嘛，这速度一会不就搞定了！) 500万………………510万………………………………………………………………………520万 ……什么情况，怎么这么慢了！！！于是开始思考人生了，不对，是思考原因了！查询数据库采用的是分页查询的方式，即每次从数据库查询10万条插入到redis，然后再取后10万条，以此类推。mysql数据库的所谓分页，设置开始索引及步长，其实每次查询都会从头开始进行检索。所以即便你只要的是450万到460万之间的10万条数据，但数据库还是要将前面的450万条数据检索以便，所以会越来越慢，越来越慢。当即果断停止导入，另寻他法。犯二2：数据库到数据文件有了上面的情况，想到这种方法是不可行的，这种方式是没办法投产的。顺便说下我们类似这种数据的投产方式，我们有个专门的初始化模块，在其它功能模块投产前（或投产后，视是否对功能有影响决