C********g
发帖数: 1548 | 1 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
用文件系统？ |
g*****g
发帖数: 34805 | 2 什么查询，建索引了没有？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
|
l**********n
发帖数: 8443 | 3 文本查询还是es快吧。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
|
T*****9
发帖数: 2484 | 4 用elastic search吧
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
|
C********g
发帖数: 1548 | 5 有chapterid和bookid作为索引。下面是一个查询例子：
BBC_Chapter是保存chapter基本信息的表
BBC_Content是保存chapter内容的表
select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
1004';
【在 g*****g 的大作中提到】
: 什么查询，建索引了没有？
:
: EC2
|
n*****t
发帖数: 22014 | 6 chapterstatus 加个索引试试，不过应该是物理硬盘的问题，content 需要读出来，你
需要检查一下 output data size，或者 select 里去掉 content 比较一下。
另外，为什么是 LEFT JOIN？
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
|
g*****g
发帖数: 34805 | 7 where里把 id提到第一个，把 结果里的 content去掉，如果快就是 IO问题，得升
instance.
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
|
n*****t
发帖数: 22014 | 8 他这个 where clause order 根本没关系，只跟 index 有关，不懂别瞎说
【在 g*****g 的大作中提到】
: where里把 id提到第一个，把 结果里的 content去掉，如果快就是 IO问题，得升
: instance.
|
n*w
发帖数: 3393 | 9 execution plan?
这个query不瞬间拿到结果肯定有问题。index 或 vm。
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
|
e********2
发帖数: 495 | 10 用lucene，luke。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
|
|
|
g*******t
发帖数: 7704 | 11 chapterstatus加索引，where里的字段都加index，
google搜索快，是全文索引，网页里每个word都索引，狗狗的特长就是这些索引数据的
存储，读取，
就是今天大数据的起源， |
i**i
发帖数: 1500 | 12 只查 BBC_Chapter 需要多长时间？
select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
= '
1004'; |
k*****3
发帖数: 226 | |
C********g
发帖数: 1548 | 14 0.00 sec
bookid
【在 i**i 的大作中提到】
: 只查 BBC_Chapter 需要多长时间？
: select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
: = '
: 1004';
|
B*****g
发帖数: 34098 | 15 tuning SQL 不贴execution plan神仙也没辙呀 |
i**i
发帖数: 1500 | 16 select a.chapterid from BBC_Chapter as a, BBC_Content where BBC_Chapter.
chapterid =
BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
需要多长时间？ |
C********g
发帖数: 1548 | 17 15.88 sec.
【在 i**i 的大作中提到】
: select a.chapterid from BBC_Chapter as a, BBC_Content where BBC_Chapter.
: chapterid =
: BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
: 需要多长时间？
|
i**i
发帖数: 1500 | 18 你确定content的那个id有index?
【在 C********g 的大作中提到】
: 15.88 sec.
|
C********g
发帖数: 1548 | 19 是这个吗？
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_
len | ref | rows | filtered | Extra |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| 1 | SIMPLE | BBC_Content | ALL | NULL | NULL | NULL
| NULL | 70254 | 100.00 | |
| 1 | SIMPLE | a | eq_ref | PRIMARY,bookid | PRIMARY | 4
| BBC.BBC_Content.chapterid | 1 | 100.00 | Using where |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
2 rows in set, 1 warning (0.01 sec)
【在 B*****g 的大作中提到】
: tuning SQL 不贴execution plan神仙也没辙呀
|
C********g
发帖数: 1548 | 20 谢谢你的提醒。犯了个低级错误，把index搞混淆了。
【在 i**i 的大作中提到】
: 你确定content的那个id有index?
|
|
|
d****n
发帖数: 1637 | 21 瞎说一下啊，鄙人根本没经验。
除了content 以外的查询用rdbms,
content search 再另建一个nosql 用mapreduce 专门干这个。
这个非常适合read 多于write情况。
不好的地方就是额外的存储开销和save content 时候要建立 nosql delay
keyWords occur rdbms-indexId?
黄容 100 idx0
郭靖 85 idx17
避血剑 50 index 55
然后对 sentence 展开，我估计肯定有专门干这个的轮子，不用自己造 |
i**i
发帖数: 1500 | 22 说好的每人一个包子呢？
【在 C********g 的大作中提到】
: 谢谢你的提醒。犯了个低级错误，把index搞混淆了。
|
i**i
发帖数: 1500 | 23 谢谢包子
【在 i**i 的大作中提到】
: 说好的每人一个包子呢？
|
w***g
发帖数: 5958 | 24 我这里最大的表是259G，而且每条记录就几十个字节，ID都是64位的。几乎每秒钟都在
增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
mongodb和文件系统都救不了你。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
|
C********g
发帖数: 1548 | 25 就一个mysql server instance?
【在 w***g 的大作中提到】
: 我这里最大的表是259G，而且每条记录就几十个字节，ID都是64位的。几乎每秒钟都在
: 增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
: mongodb和文件系统都救不了你。
:
: EC2
|
d****n
发帖数: 1637 | 26 同问
【在 C********g 的大作中提到】
: 就一个mysql server instance?
|
w***g
发帖数: 5958 | 27 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
你那个索引文本的可能是用错轮子了。
【在 C********g 的大作中提到】
: 就一个mysql server instance?
|
d****n
发帖数: 1637 | 28 你这是vertical scale up 了？
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
|
w**z
发帖数: 8232 | 29 一秒几次操作？
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
|
w***g
发帖数: 5958 | 30 一两秒钟一次吧。有时候一秒一两次。不是很频繁。
【在 w**z 的大作中提到】
: 一秒几次操作？
|
|
|
g*****g
发帖数: 34805 | 31 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
【在 w***g 的大作中提到】
: 一两秒钟一次吧。有时候一秒一两次。不是很频繁。
|
N*****m
发帖数: 42603 | 32 试过aurora没？
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
|
w***g
发帖数: 5958 | 33 震撼你一下
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
我们那种行业应用比不得你们做consumer market的，每秒5k个。
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
|
g*****g
发帖数: 34805 | 34 我们有的应用处理的是每秒百万次写，只不过不往 RDBMS上放。
【在 w***g 的大作中提到】
: 震撼你一下
: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
: SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
: 我们那种行业应用比不得你们做consumer market的，每秒5k个。
|
w**z
发帖数: 8232 | 35 我们最忙的mysql 是4K/ seconds， cpu 还不到10%。 当然我们自己的DB server 比较
强劲, 24core, 128G memory.
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
|
g*****g
发帖数: 34805 | 36 我们在 AWS上没用最贵的 instance，还有空间。
【在 w**z 的大作中提到】
: 我们最忙的mysql 是4K/ seconds， cpu 还不到10%。 当然我们自己的DB server 比较
: 强劲, 24core, 128G memory.
|
