500만 개가 넘는 일일 테이블 데이터를 계산하는 MySQL 솔루션이 있습니까?

<code>请教：
现在有每天的日表数据（一天生成一张）， 每张表数据大概在500w左右。
需要从每天的日表数据中统计：根据appid统计ip数，同时ip需要去重。 
大概的sql是：</code>

log0812_tb에서 appid, count(distinct(ip))를 선택합니다. 여기서 iptype = 4 appid별로 그룹화됩니다.

<code>然后将统计的appid 和 ip数，放入到另一张统计表中。 

1、直接执行sql的话，肯定超时了（系统仅配置了400ms读取时间）。
2、如果将数据都取出到内存中再做操作，内存又不足了，给的内存只有50M。。。（不为难程序员的需求不是好公司）
 
请问，还有优化的解决方案吗？
谢谢 </code>

답글 내용:

<code>请教：
现在有每天的日表数据（一天生成一张）， 每张表数据大概在500w左右。
需要从每天的日表数据中统计：根据appid统计ip数，同时ip需要去重。 
大概的sql是：</code>

log0812_tb에서 appid, count(distinct(ip))를 선택합니다. 여기서 iptype = 4 appid별로 그룹화됩니다.

<code>然后将统计的appid 和 ip数，放入到另一张统计表中。 

1、直接执行sql的话，肯定超时了（系统仅配置了400ms读取时间）。
2、如果将数据都取出到内存中再做操作，内存又不足了，给的内存只有50M。。。（不为难程序员的需求不是好公司）
 
请问，还有优化的解决方案吗？
谢谢 </code>

먼저 아래 표에서 가능한 최적화에 대해 이야기해 보겠습니다.

1. 결합인덱스 만들기(appid, ip)

2. IP는 문자열이 아닌 정수를 저장합니다

그래도 시간이 초과되면 데이터를 메모리로 읽어 보려고 시도하지만 메모리가 50M에 불과하다면 HyperLogLog를 사용해 볼 수 있습니다. 소비되는 메모리는 매우 작지만 통계 데이터는 약간 편향됩니다. 약 2%

마지막으로 이러한 종류의 로그 데이터는 SQL에 저장하지 않는 것이 가장 좋습니다. 필요에 따라 hbase, mongodb 등의 nosql을 선택할 수 있습니다.

@manong
감사합니다. 말씀하신 두 가지 최적화 솔루션 모두 좋습니다.

typeid, appid, ip의 공동 인덱스를 구축하여 이 명령문이 테이블을 반환하지 않고 인덱스 쿼리를 통해 실행되고, 시간이 1.5초 이하로 제어되는 것이 효과적입니다.

HyperLogLog 알고리즘은 대략적으로 확인만 하고 실천하지는 않았는데 추천해주셔서 감사합니다.

다른 처리 방법을 사용합니다. 500만 개가 넘는 데이터를 일괄 처리하도록 작업을 예약합니다. 두 번 가져온 데이터를 중복 제거한 후 array_diff를 수행하여 두 번째 다른 데이터를 비교한 다음 합계하여 총 개수를 얻습니다. 이런 방식으로 시간을 1초 이하로 제어할 수도 있습니다. 여기서의 비결은 첫 번째 비교의 배열을 문자열로 변환한 다음 이를 배열에 저장하는 것입니다. 두 번째 비교를 위해 문자열을 배열로 변환하면 중첩된 배열이 더 길어지기 때문에 많은 메모리가 절약됩니다. 문자열 값의 배열은 메모리를 소비합니다.